Eric J Ostrander's

ClearCase / ClearQuest / Git/Stash "how to" pages.


ClearCase Errors

F
Simple, case-insensitive, site-wide, search (your browser must allow scripts to run):

NOTE: There may be more causes for the errors than the ones listed. The listed cause is just the one that caused it when I made the record. In addition, the solutions may not be the only solution, but the one that was used at the time.

A good reference for VOB database troubleshooting can be found at: http://www.abs-consulting.com/ftp/PAPERS/vob_db_sg.pdf

Errors




cleartool: Error: Not an object in a vob: "filename".
This error occurs when you try to execute a cleartool command on something that is not inside a VOB. The file being worked on must reside below a vob-tag mount point. Even if it's not checked-in (versioned), it is still considered a view-private file and be dealt with using appropriate cleartool commands.
You can either copy the file to a vob-tag area, thus creating a view-private file or perhaps if not working on an explicit file, you need to just cd to a VOB.

Back to the INDEX.



No permission to perform operation
Must be one of: object owner, VOB owner, privileged user. To see who owns the VOB:
  # ct describe -long vob-tag
To change the permissions, see Change a VOB's permissions. If you just want to change permissions on an element, see Change an element's permissions.

Back to the INDEX.



Warning: VOB is unavailable
This error occurs when you try to get information on an object that was attached to a VOB that was deleted in a non-standard way or is simply not available at the moment. This usually happens to view-private files that have become "stranded". Below, the vob-tag belongs to the VOB that got deleted or is no longer reachable. Give the full path to the view where you want the file to be recovered to. This command will move all stranded view-private files to the view storage area .s/lost+found directory.
  # ct recoverview -force -vob vob-tag /path/view.vws
Back to the INDEX.


Cannot create ... permission denied.
cleartool: Error: Unable to update view "view-tag": Permission denied.
There are three basic levels to the permissions in a VOB.
1) VOB groups: do you belong to a group in the VOB's group list?
  # id
  # ct describe vob:.
2) directory permissions: it may be a simply matter of changing the permissions on the current VOB directory.
  # ls -l .
  # ct protect -chmod 775 .  (if necessary)
3) view permissions: Are you attempting to create a view-private file? If so, check the persmissions on the view's ".vws" directory. Are there sufficient write privileges for you? If not, you may need to change to a different view or create your own. I.E. View permissions cannot be changed by simply changing permissions on the .vws directory.

Back to the INDEX.



Unable to access \\server\path\vob.vbs; Invalid argument.
The NFS Maestro package has a bug in it that prevents CC on Windows from resolving a long UNC path properly. This error has come up when executing a checkin with a Snapshot View and when doing a CC/DDTS integration.
The work around for this is to shorten the apparent path to the VOB on the UNIX side and redo the vob-tag on the Windows side. On the Windows side, do a rmtag on the old one and point it to the new path. In this case, you must use the "-host -hpath -gpath" as a set trio of options. For instance, if the old path on the server was hypothetically /export/home/clearcase/myproject/vobstore/admin.vbs, you could create a directory called /vobs linked to the vobstore and export /vobs to Windows.
  C:\> ct rmtag -vob vob-tag
  C:\> ct mktag -vob -tag vob-tag -public -region nt-region -host vob-server
       -hpath server-path -gpath nt-path nt-path

ex: ct rmtag -vob \admin
    ct mktag -vob -tag \admin -public -region nt_region -host scm
    -hpath /vobs/admin.vbs -gpath \\scm\vobs\admin.vbs \\scm\vobs\admin.vbs
The key here is that the path to the VOB on the UNIX side appears to be only one directory deep.

Back to the INDEX.



Unable to unmount: Resource device (Device busy)
umount: vob-tag busy
The first error occurs on Windows and second on UNIX, but both have the same cause. These happen when trying to unmount a VOB that is currently being used. Ensure that anything related to that VOB is closed, cd out of the VOB directory and/or close up the directory. If you feel that everything is out of that VOB and you still get the error, it's possible that someone else is using it.

Back to the INDEX.



Unable to map drive [X]; Error 86
This error is caused by a permission problem with NFS and the exported drives on the server. Check the following:
1) Ensure the user can telnet into the UNIX server from the client. This verifies their username and password.
2) Run "nfs register unix-username" so that NFS Maestro has the permission/ability to mount the server's exported drives on the user's behalf. This registration of the user's password is unique to this user if the "Allow all users to see this installation." was used during the NFS Maestro install. That is, if another user logs into this machine and does an "nfs register", the first user's registration will not be overwritten.
3) Ensure the server's drive that contains the VOB is exported to the user's client machine.
All three of these need to be satisfied before CC has permission to mount a remote VOB.

Back to the INDEX.



Unable to map drive [X]; Error 85
This error can occur when you are unable to map to a drive due to permission constraints. If you have permission to view/modify the registry, ensure the ProtectionMode either does not exist (anyone can map a drive) or that it is set to "1" (also, anyone can map a drive). Double-click on "Session Manager" to see ProtectionMode.
Hive: HKEY_LOCAL_MACHINE
Key: SYSTEM\CurrentControlSet\Control\Session Manager
Name: ProtectionMode
Type: REG_DWORD
Value: 1

Back to the INDEX.



Unable to access \\server\path\vob.vbs; Error 26
This error is generated when attempting to mount a UNIX VOB from Windows. The "Error 26" is generated by NFS Maestro and means that it could not gain access to the drive/directory that the VOB is in. The VOB's drive on the UNIX server needs to be exported to the Windows attempting to mount it.

Back to the INDEX.



Could not connect [X:] to [\\server\path\vob.vbs] - error 5
This error shows up when trying to mount a VOB from a Windows machine. The "Error 5" is generated by NFS Maestro and means that there is a problem with permissions. The username and password that the user uses on the UNIX server must be registered with NFS Maestro. You can register them via Start -> Programs -> NFS Maestro -> NFS Network Access -> Register   or can register them on the command-line with "nfs register unix-login. The user's group must be in an environment variable called "CLEARCASE_PRIMARY_GROUP". This can be verified by going to Start -> Settings -> Control Panel -> System -> Environment or by typing "set | more" on the command-line. This group can either be a local user group created on the local machine or a domain group that is accessed when the user logs on. The user must be a member of a group of the same name on the UNIX server. This implies also that that primary group needs to be the group VOB directories and view to be used. This gives the user permission to write to it.

Back to the INDEX.



Access denied error

UNIX systems have to give permission to machines trying to "mount" or "map" the drives. The administrator of the server you are trying to access must make the following modifications for the connection to work.
   System V UNIX (Solaris, HP-UX, etc...): Add lines to /etc/dfs/dfstab. If you want to export "/export/home" to the machine called d520n "share -F nfs -o rw=d520n /export/home". To add additional machines to the export list, just place a colon between machine names "share -F nfs -o rw=rvance:d520n /export/home". Then type "shareall". You will now see a corresponding entry in /etc/dfs/sharetab.
BSD UNIX (SunOS, FreeBSD, etc...): Add lines to /etc/exports. If you want to export "/export/home" to the machine called d520n "/export/home -access=d520n". To add additional machines to the export list, just place a colon between machine names "/export/home -access=d520n:rvance". Then type "exportfs -a".
In both cases, if the machines will be in contact often, it's a good idea to add them to the /etc/hosts file.
137.93.120.117   rvance.geg.mot.com   rvance
137.162.179.217   d520n.geg.mot.com   d520n

This error will also occur on Windows if the view you've chosen is owned by a different group than the one that owns the VOB and there is no world r_x permissions on the VOB directory. Basically, check all of the following:
1) The UNIX drive is exported to Windows. A good check for this is to access the server's drive via Windows Explorer "map network drive" (independent of CC).
2) The VOB has group permissions other than your PRIMARY_CLEARCASE_GROUP. On Windows, run atria-home/etc/utils/credmap.
3) The view has group permissions other than your PRIMARY_CLEARCASE_GROUP. On Windows, run atria-home/etc/utils/credmap.
NOTE: Credmap will not pass if the usernames on Windows and UNIX server are different. If credmap doesn't give the required information, it will be necessary to log into the server and cd to the viewstore and check the permsissions manually.

Back to the INDEX.



HCLNFSD/PCNFSD Error

This error occurs when you try to map an exported UNIX drive to the your PC. Some UNIX flavors come bundled with a daemon called PCNFSD. This daemon returns information to the querying PC about exported drives, groups, and other such info.

If not already running (hclnfsd or pcnfsd will show up in the Rpcinfo tool of NFS Maestro), you need to start the daemon on the UNIX machine and ensure it will get restarted at reboot time. NFS Maestro comes with its own version of the daemon called HCLNFSD for those UNIX systems that don't have PCNFSD. You can compile and link the source code that Hummingbird supplies (C:\Program Files\Maestro.nt\utility) or you can download a pre-compiled version for your specific UNIX flavor from ftp.hummingbird.com . See the NFS Maestro User's Guide for a description of the daemon and its options. The actual install location is arbitrary.
If the VOB you are attempting to access is located on a network appliance (netapp), you will be unable to load third party software due to limitations in the netapp operating system. In this case, configure NFS Maestro to run in "compatibility" mode, which is less efficient but works. See http://www.netapp.com/technology/level3/atria.html for a more detailed discussion about CC on a netapp.
To ensure that hclnfsd gets restarted at reboot, create a script called /etc/init.d/hclnfsd.
#!/bin/sh

# PC NFS daemon; so that PCs can map exported UNIX drives via NFS Maestro.
hclnfsd_home=/usr/local/hclnfsd
case "$1" in
  'start') if [ -f $hclnfsd_home/hclnfsd ]; then
             echo "PC nfs daemon (hclnfsd) starting"
             $hclnfsd_home/hclnfsd -A -X
           else
             /usr/bin/echo "\n /etc/init.d/hclnfsd ERROR: cannot find PC nfs daemon $hclnfsd_home/hclnfsd \n"
           fi;;
   'stop') PID=`ps -efl | grep hclnfsd | grep -v grep | awk '{ print $2 }'`
           [ ! -z "$PID" ] && /usr/bin/kill ${PID} 1> /dev/null 2>&1;;
        *) echo "Usage: /etc/init.d/hclnfsd { start | stop }";;
esac
Change permissions on the new hclnfsd file to make it executable and setup the run control links to it.
  # cd /etc
  # chmod 744 init.d/hclnfsd
  # ln -s /etc/init.d/hclnfsd rc3.d/S99hclnfsd
  # ln -s /etc/init.d/hclnfsd rc2.d/K00hclnfsd
Start the hclnfsd daemon.
  # /etc/init.d/hclnfsd start
Back to the INDEX.


Cannot run regedit
This is an error you receive on Windows when a software package, such as clearhomebase.ccreg, is executed. This says that you don't have the proper permissions to edit the Windows registry. The simple solution for this is for an Adminstrator to give the "SYSTEM" permission to edit the registry.

Back to the INDEX.



rcmd: socket: permission denied
This error shows up when trying to checkout an element in a newly integrated VOB. This error is independent of CC. I.E. Independent of CC, you should be able to successfully run an rsh command on the command-line. The integrated CC system uses the rsh command to log into the DDTS server and run some commands.
The solution was that, somehow, the executable /usr/bin/rsh was not owned by "root" with a group of "bin". The permissions for it should be set 4555. That is, setuid "-r-sr-xr-x".

Back to the INDEX.



The VOB storage directory "X:\\server\path\vob.vbs" was not found.
This error occurs when you are trying to mount a VOB or start a view and CC complains that it can't find a VOB storage area on a drive letter that has nothing to do with the task at hand. That is, that particular drive letter is not mounted to anything, nor are you requesting a view or VOB be mounted there.
Somehow the system still thinks that the VOB/view is accessed through that drive letter, perhaps because it was there in the past. If there is no reference to it in the Windows Explorer, run regedit and see if there are any references to it and delete them: HKEY_USERS -> serial-number -> Network. If there is more then one serial-number, there will only be one with a "Network" subfolder. If there is no entry for the drive being mentioned, try a reboot. The extreme solution that is known to clear up this problem is to reinstall CC :-(.

Back to the INDEX.



Unable to open file "/tmp9999.pmt": permission denied
This error message shows up anytime CC tries to write a file to the directory pointed to by the environment variable TMP. This error is most likely to show up when trying to checkout an element in a newly integrated VOB. The problem is in the Perl script atria-home/sun5/lib/perl5/integ/clrcase.pl. The 2 lines below are trying to write to an output file based on the environment variable TMP. If TMP is set to "/tmp", there is no slash between the environment variable and the filename. So, after concatenating the two, you wind up with an erroneous name appearing in the "/" directory, which understandably gives you "persmission denied".
$outfile = $ENV{'TMP'} . "$$.pmt";
$cmd = fmtcmd("clearprompt","text -outfile $outfile $def -prompt \"${bugmsg}\"");
The solution, until Rational fixes that script, is to reset the TMP environment variable to TMP="/tmp/".

Back to the INDEX.



ClearCase albd service did not start.
Error 1069 - The service did not start due to logon failure

This error shows up on Windows when the albd service has not started for some reason. One reason this can occur is if the clearcase_albd user password has expired. A quick test to see if this is the cause is to try and login as clearcase_albd. If this is the problem, reset the Windows password for clearcase_albd. The clearcase_albd password is registered in two places, on the Windows system in Start -> Programs -> Administrative Tools -> (Domain) User Manager. Be sure to set the switch "Password Never Expires" to avoid problems in the future. In CC, Start -> Settings -> Control Panel -> Services and double-click on Atria Location Broker.

Back to the INDEX.



cleartool: Error: Pathname is not within a VOB: "."
Any ct commands that have to do with listing or manipulating elements must be done with a view set and inside a VOB directory. If the vob-tag for a VOB is "/clearcase/vobs/scripts", then you need to be cd'ed to that directory of one of its subdirectories to work with CC commands. This excludes some commands: lsvob, lsview, clearlicense, etc ...

Back to the INDEX.



element   [checkedout but removed]
This is due to an element that is checked out to a view, but the view-private file either could not be written to that directory or was subsequently deleted. Have the person that owns the checkout do an uncheckout on it. It could be that the view storage directory does not have permission for you to write to it. Also, check the permissions on the parent directory and ensure that the group has read-write privileges. If permissions on the parent directory and the view storage area seem ok, the view-private file may just have been inadvertently deleted. Have that user try another checkout and see.
This is analogous to a snapshot view's [loaded but missing].

Back to the INDEX.



The path \DEVICE\...\...\.s\filename does not exist.
This error is associated with trying to remove or overwrite a view-private file via a Windows client when the actual data container has been deleted for some reason. That is, if there is a view-private file called "junk" and it has a data container /admin/clearcase/views/admin_view.vws/.s/00032/bbbc8a3b.000f.junk and that storage area gets deleted for some reason without removing it via the view in the VOB, you will get the error message.
This message only occurs if trying to remove the view-private file via Windows. If the view is common to both UNIX and the Windows client, set the view on the UNIX side and just delete the view-private file from the VOB directory. If the view is local to Windows, there is no way to delete the view-private file from the VOB directory. Go to the view container directory pointed to by the error and create an empty file with the same name. You will now be able to remove it from the VOB directory normally.

Back to the INDEX.



mvfs: ERROR: ... view needs reformat
mvfs: ERROR: VIEW = view-tag VOB = vob-tag - ClearCase view error
A view usually only needs a reformat if the version of CC has been upgraded. However, a view can occasionally, inexplicably need reformatting after a system crash or similar mishap. The "reformatview" subcommand leaves a directory called db.dumped in the vws directory that can be deleted via normal OS commands. This command can lead to data loss; this can happen if the element's owner is not the same the view's owner. Consult the view_log to investigate possible data loss. If the reformat does not clear the "view needs reformat" error, you may have to consider deleting the view and creating a new one. Also, consider using the   -force   option if you get the warning message "Recovery not needed"; see the CC Reference Manual for details.
  # ct reformatview -tag view-tag
On rare occassions a view can become corrupt. If this happens, generally a recover of the view will solve the problem. If not, call tech support.
  # ct recoverview -tag view-tag

WARNING: Recoverview uses reformatview. Depending on the state of the database, certain information can be lost. Upon completion, check the view_log to investigate possible data loss; it's in /var/adm/atria/rgy/log on UNIX and ClearCase Home Base -> Administration -> Log Browser on Windows.

NOTE: Sometimes the "db" database directory cannot be renamed due to files in use. It will reattempt 2 more times at 60 second intervals waiting for the competing process to finish. If the reformat fails for this reason, ensure no processes are using the view and try again.

Back to the INDEX.



mvfs: ERROR: view=view-tag vob=vob-tag - ClearCase vob error
This error occurred on Solaris while attempting to cd to a VOB. There could be many problems that could give such a generic error message, but this time it was caused by the atria daemon not running. Simply attempt a stop and restart. As root:
  # cd atria-home/etc
  # ./atria_start stop
  # ./atria_start start
Back to the INDEX.


Can't get primary GID
This error shows up when running creds or credmap on Windows that you are trying to connect to a UNIX server. The problem is that CC doesn't know what your primary group name is. Need to set a user environment variable called CLEARCASE_PRIMARY_GROUP to the name of the user's primary group that is on the UNIX server. You will also need to create a Domain group of that name with the current user as a member. If unable to create Domain groups, a local group can be created with the same name locally on the Windows client. The only downside to local groups is that they are difficult to administer en masse in the future.

Back to the INDEX.



Attempt to get location information failed: Invalid argument.
This error can occur when attempting to do commands such as mktag from Windows client connected to a UNIX server. If the attempted command looked like
  # ct mktag -view -tag new-view-tag viewstore/new-view-tag.vws
it may be necessary to include the extended path information
  # ct mktag -view -tag new-view-tag
       -host server-name
       -gpath UNC-pathname
       -hpath path-on-server
       UNC-pathname

ex: ct mktag -view -tag admin_view
       -host scm
       -gpath \\scm\viewstore\admin_view.vws
       -hpath /viewstore/admin_view.vws
       \\scm\viewstore\admin_view.vws
Back to the INDEX.


clearimport: Error: Permission denied. Not VOB owner.
This error showed up when attempting a clearimport as a regular user on Windows client connected to a UNIX server. All the permissions and connections were in place to allow the Windows user to create and remove elements in the current directory. However, the clearimport command was giving a "Not VOB owner" error message. It is essential to be the VOB owner (or root) to do a clearimport.
The work around for this is to use the   -nsetevent   option during clearimport. This is because the original was apparently owned by somebody else and by doing the clearimport you are telling CC to create an element owned by the other person, which is not allowed unless you are the VOB owner or an Administrator. Using the -nsetevent option creates the newly transferred element as you with a new creation date. The downside of this is that the original creator and creation date history information are lost.

Back to the INDEX.



Type manager "text_file_delta" failed create_version operation.
Version: 7.1.2
Updated: 10/04/12
NOTE: This is the generic error message that a user sees. Also check the Windows Application Log (Source:ClearCase, Category:Debug).
This error occurred when attempting to checkin a .docx file for the first time.
The document was added to source control as an empty file. The file can be checked out and back in still empty without issue. However, if even a single character is added, the error occurs.
The problem is that when the file was added to source control as an empty file, CC incorrectly assigned the "text_file" element type to it instead of the more appropriate "ms_word" element type.
The element can be removed and then added to source control again, this time non-empty. Or, the element type can be changed:
	ct chtype -nc ms_word filename.docx
Back to the INDEX.


element   [eclipsed]
This shows up when you do a "ct ls". It means that there is a view-private file of the same name eclipsing the source-controlled version of the same file. This can happen when a user adds a file to a directory and leaves it view-private. Then, another user in a different view goes to that directory, seeing that the expected files are not there, copies them in and adds them to source control. Now, when the first user returns to that directory and does a regular "ls", they will see their own view-private version of the file. However, it they do a "ct ls", they will see two versions, one view-private and the other in CC but eclipsed.
There are two solutions to get out of this and depends on which version is to be kept. If the view-private version in the first user's view isn't needed, then simply delete it and the CC version will be visible in the normal way. If it is needed and needs to be added to source control, move the view-private file to a temporary name, checkout the now visible CC version, move the temporarily named view-private file back to the original name overwriting the CC version and then check it in. Of course, there is always the third option of removing or renaming the CC element.

Back to the INDEX.



Could not find ".\lost+found" in directory hash table.
This error showed up when attempting a clearimport using a cvt_data file generated by clearexport_ccase. The cvt_data was generated sitting on top of another VOB, which necessarily has a lost+found directory at that level. The error message is telling you that the lost+found directory in the original VOB has elements in it. There are two ways to get around this error. Rmelem on everything in the lost+found directory in the original VOB and rerun the clearexport_ccase the same way, or rerun the clearexport_ccase specifying everything in the original directory with the exception of the lost+found directory. Remember to delete the cvt_data file before running clearexport again.

Back to the INDEX.



The mount-over directory "..." was not found.
This error occurred when attempting to mount a newly created private VOB. Unlike public VOBs that automatically create the mount point for MVFS, private VOBs require that the mount point be a real directory. Create the mount point and try the mount again. For instance, if the vob-tag for the private VOB in question was created as /home/ejo/myvob, there needs to be an empty directory called myvob in ejo before you mount the VOB.
However, if you're sure the directory in question exists and you still get the error message, it may be that the directory "/home/ejo" is itself a mount. The error occurs in this case because MVFS is attempting to mount the VOB in an NFS mount, which isn't allowed. To get around this, rmvob on the private VOB and recreate it with a tag located in a directory local to the machine.

Back to the INDEX.



ClearCase Dynamic Views: The device is not currently connected, but is a remembered connection.
This error occurs when a Windows user with a view set simply logs out and back in vice rebooting the machine. This is a known bug with NFS Maestro and is not fixed in the latest version 6.1. The only recourse at this time is to either simply lock the screen when you leave or turn the machine off.
WARNING: Ignoring this error message will cause your Windows GUI to look like it's working. However, if you try to checkout a file, it will checkout the file but not populate the current view with it. The result will be the [checkedout but removed] error message when doing a "ct ls" of that directory from the command-line.

Back to the INDEX.



cleartool: Error: Cannot link directory "...".
This error showed up when running a "ct ln" command on a directory on the UNIX command-line. By default, links in CC are hardlinks so that the link has all the functionality of the original with respect to checkins and checkouts. However, you cannot create a hardlink to a directory in UNIX, hence not in CC either.
An alternative to this is to create a softlink using the   -slink   option with the caveat in mind that not all CC functions will be available to the linked element. Another alternative is to create the destination directory element with a "ct mkdir" command and then use a "ct ln *" command to link all the elements inside the directory en masse.

Back to the INDEX.



Cannot set the file time handling property: Permission denied.
This error shows up when a user other than the owner tries to update a snapshot view. The RPC view_setprop can only be executed by the owner. This doesn't NEED to be true and Rational is working on a fix: Defect #29605. As a work-around, you can update each VOB mounted under the view individually. This can be tedious if working with many VOBs, so an alternative is to add the user getting the error to the "clearcase" group; the one that only has clearcase_albd in it. Note that adding a user to the clearcase group gives that user unlimited abilities WRT ClearCase. That is, that user can rmelem even if the element is locked and other such undesirable side-affects.

Back to the INDEX.



element   [view-->vob hard link]
This shows up when a UNIX hard link is made to a CC object inside a VOB. This showed up when a user did a UNIX "ln" by mistake vice the "ct ln" and wanted to undo the command. Do not do rmelem or UNIX rm on it or the original will disappear as well. To get rid of it, use the UNIX unlink command, which should work. If it runs without error but fails to rm the link, try doing an unco on the parent directory and then run the UNIX unlink.

Back to the INDEX.



Unable to load "...": unknown error in VOB.
This error showed up when attempting to update a snapshot view. This is a generic error message though, and implies that a proper connection to the vob storage area could not be made. The error is most probably due to a permission problem in the view, the NFS mount or the VOB. Some things to look at:
1) Can you map a network drive to the vobstore independent of CC?
2) Re-register the user via "nfs register" on the command-line.
3) Is the snapshot view owned by you?
4) Does the VOB have the correct permissions for your group?
5) Can you create a dynamic view to the same VOB and checkout/in ok?
6) Does credmap pass?

Back to the INDEX.



clearviewtool/view: Error: Unable to create snapshot view "...".
This error occurred when attempting to create a snapshot view in a shared directory. Even though the share's permissions were wide open, clearviewtool was still giving permission denied. Unfortunately, all attempts to correct the problem failed short of simply creating another share and creating the snapshot view in the new share.

Back to the INDEX.



cleartool: Error: Operation "vobsvr_get_handle" failed.
This error showed up when attempting to lock a VOB on a UNIX system. The cause was that the permissions in vob-storage-area/.identity directory were not set properly; most likely due to a restore not preserving the permissions or somebody coming in afterward and changing the permissions manually independent of CC. The solution to restoring the permissions was to run the following in the .identity directory:
  # chmod 2400 gid group.*
  # chmod 4400 uid
Back to the INDEX.


Operation "view_ws_is_ws_view" failed: view storage directory or control files unavailable.
This error showed up when attempting to start a previously working local view on Windows. The reason for the corruption of permissions is unknown, but the following straightened them out.
A disconnect in the view's permissions can occur if the Atria Location Broker server logon user was changed after the view was created or if the view's storage area was moved using Windows commands.
If the error persists after running fix_prot, run it again and then reboot to reset any caching. One might also consider simply removing the view and creating a new one. You will need to have administrative privileges to do that. See "Fix VOB protections" for the fix_prot commands.

Back to the INDEX.



cleartool: Error: unknown style protection on "...". The data is invalid.
This error occurred when attempting to remove a group from the groups list of a VOB as the ClearCase administrator on Windows. The administrator should be able to remove and add groups at will. For unknown reasons, the protections on the VOB were not optimal. See "Fix VOB protections" for the commands. You'll probably need to stop and restart the albd daemon in ClearCase Home Base -> Administration -> Control Panel -> Services Startup for the changes to showup.

Back to the INDEX.



cleartool: Warning: Unable to move private data from "..." (No such file or directory). (Windows Explorer)
Unable to temporarily move file "..." for element creation. (Command Prompt)
This error occurred when simply attempting to transition a file from view-private to source control on Windows using a UNIX VOB server. Rational reports that this is due to a mismatch in the way CC 3.2 and NFS Maestro are making calls to the file. The solution was to upgrade CC to 3.2.1.

Back to the INDEX.



cleartool: Error: Trouble contacting registry on host "...": specified host is not a registry server.
This error occurred on a Windows server that was previously working fine. For inexplicable reasons, the server daemon got "out of sync". The resolution was to ensure the configuration in the ClearCase Home Base -> Administration -> Control Panel -> Registry tab was set properly and then restart the daemon in the Services Startup tab.

Back to the INDEX.



vob_scrubber: Error: Unable to get VOB tag registry information for replica uuid "...".
This error shows up in an email sent to root. This error can show up if a VOB was deleted in a non-ClearCase manner. There will usually be another email message sent at the same time telling which VOB failed the scrub. If not, the replica uuid can be correlated to a vob via the /var/adm/atria/log/scrubber_log or /var/adm/atria/rgy/vob_* files. Use the procedure at the end of Delete a VOB to ensure a proper cleanup VOB deletion.
If all the pieces of the VOB deletion are complete and you still get the email referencing that VOB, as root start and stop the atria daemon:
  # cd $ATRIAHOME/etc
  # ./atria_start stop
  # ./atria_start start
Back to the INDEX.


clearviewtool/server_id_nt: Error: unable to set access control list for ...vws: Access is denied.
clearviewtool/server_id_nt: Error: protection on ...vws is out-of-synch with identity.sd and groups.sd
clearviewtool/view: Error: Failed to set identity on view: Permission denied

These errors occurred when attempting to create a view in an Windows shared directory in which views had been created before. For inexplicable reasons, the share, not the directory itself but the share, had "Change" permissions only for the group of users that needed to create views there. Changing the permissions for that group to be "Full Control" solved the problem.

Back to the INDEX.



cleartool: Warning: The view cannot be started because the MVFS is not installed.
This error showed up after a disk crash and restore from backup. Unfortunately, we were unable to find the reason the MVFS refused to start. However, CC on the server needed to be upgraded from 3.2 to 3.2.1 anyway and all was fine after that.

Back to the INDEX.



scrubber/scrubber: Warning: skipping VOB "..." due to earlier errors
This error was written in the /var/adm/atria/log/scrubber_log on a Solaris 2.5.1 server running CC 3.2.1. The scrubber_log was pointed to by a cron job email stating that ccase_cron.day had failed. The exact reason for the error is unknown, but the application of patch clearcase_p3.2.1-9.sun5.tar.gz cleared the problem.

Back to the INDEX.



Version checkout "..." is different from version selected by view before checkout "..."
element\CHECKEDOUT from "..." [not loaded, checkedout but removed]
Failed to get stat for the mounted vob pathname.
These errors occur when attempting to checkout a version of an element other than the one selected by a rule in a snapshot view config_spec. Each of these errors occurred when running the checkout from the Version Tree Browser and showed up while using CC 3.2.1 on Windows. Because one of the rules in the config_spec covers looking at CHECKEDOUT versions, these operations should be allowed. If you attempt to checkout a version other than the one selected by the view from the command-line, CC will simply checkout the version that IS selected by its config_spec and not the one requested. Once the error has occurred, the element will be missing from the Windows GUI and will give the [checkedout but removed] error with a "ct ls" on the command-line. From the command-line, "ct unco element"; this will restore the element to normal. However, for snapshot views you will get an error about an update failure and other messages. For those, simply run "ct update element" and all should be back to normal. If you really want to checkout a different version, you'll have to modify your current config_spec or use a different view to get around these errors.
Unfortunately, it gets more complicated. If you are on a CC system where checkout of a non-selected version does not generate these errors, you can see differing behavior WRT linked elements. That is, if you checkout a non-selected version from one of the linked elements, you will get the version you expected. However, if you checkout a non-selected version from the the other half of the link, you will get command-line like behavior in which the it checks out the version previously selected by the view, and NOT the one you expected. :-(
NOTE: These errors do not always occur. That is, some installs of CC will behave in snapshot views just like you'd expect in all cases (except the linked element arrangement).
Moreover, in dynamic views, checkout of a version you are requesting will not default to the one selected by the view's config_spec as in snapshot views. A subsequent checkin will simply create a new version via a merge with whatever the LATEST version was and the view will go back to selecting the old version it was seeing before. This is true for the linked elements case as well. That is, all versions of all elements always point back to the original in the VOB and behavior is much more predictable.

Back to the INDEX.



cleartool: Error: checked out version, but could not copy data to "view" in view: Invalid argument
This error showed up on a Windows client connecting to a Windows server. Both the client and Windows server were running ClearCase 3.2.1. The user had previously been able to use this VOB and view successfully. Attempts to checkout any element with this view failed with the above error message. Other users of the same view and VOB had no trouble checking out elements. The reason for the error is unknown, but a reboot of the client machine solved the problem.

Back to the INDEX.



element@@   [no version selected]
element: No such file or directory
These can occur when your view's config_spec fails to select any version of a particular element. The first resulting from "ct ls" on UNIX or Windows and the second results from a regular "ls" on UNIX; a regular "dir" on Windows simply won't show the files. In UNIX, there is no way to not select a version and not get errors.

Back to the INDEX.



cleartool: Error: Trouble looking up element "element" in directory "directory".
mvfs: error in the configuration specification for view view-tag
./element: I/O error
These errors occur if the view's config_spec has a rule that selects more than one version; the first during "ct ls" and the other two during a simple "dir" or "ls". Examine the element via the describe and lsvtree commands and also the config_spec via "ct catcs" and determine which rule is selecting more than one version.

Back to the INDEX.



cleartool: Error: Trouble contacting registry on host "host: specified host is not a registry server.
This error shows up when attempting to lsview, lsvob or other such commands that need to query the registry server. On Windows, set host correctly in ClearCase Home Base -> Adminstration -> Control Panel -> Registry on either the client or on the registry server itself. On UNIX, ensure the host is correct in /var/adm/atria/rgy/rgy_hosts.conf on both the client and server.

Back to the INDEX.



A duplicate file name exists, or the file cannot be found.
mv: cannot rename element: Read-only file system
The first occurs on Windows when attempting to rename a CC versioned file with the standard "move" command. The second is an attempt to use the standard UNIX "mv" command. To rename an element, use the CC equivalent:
  # ct mv oldname newname
Back to the INDEX.


cleartool: Error: Invalid string value: string.
This occurs when attempting to make/modify a string type attribute. String attribute values must be enclosed in quotes inside CC. Both the Windows and UNIX command-lines strip the quotes, so they need to be escaped.
  # ct mkattr attribute \"string\" element
Back to the INDEX.


cleartool: Error: Branch "branch" of element is checked out reserved by view view-tag ("hostname:viewstore").
This error occurred when attempting to relocate an element to another VOB. The relocate command will automatically check out the destination directory for you, but cannot if it's already checked out to another view. Simply check the destination directory in using the view-tag view and rerun relocate.

Back to the INDEX.



sh: bugval: not found
CC 3.2, DDTS 4.1, Solaris 2.6
This error shows up when attempting a checkin/out in a VOB integrated with DDTS. Ensure that the BUGTRACK_PROXY_HOST environment variable is set to the hostname of the DDTS server, if not the local machine. Ensure the BUGTRACK_PROXY_USER environment variable is set to the name of a user on BUGTRACK_PROXY_HOST that you can rsh into and run the getpolicy command. That is, independent of CC the following command should be successful:
  # rsh $BUGTRACK_PROXY_HOST -l $BUGTRACK_PROXY_USER getpolicy
NOTE: I've noticed that even if this command doesn't run correctly from the command-line (command not found) that it will run correctly when called from CC if at the very least the following command IS successful:
  # rsh $BUGTRACK_PROXY_HOST -l $BUGTRACK_PROXY_USER ls
Back to the INDEX.


cleartool: Warning: Version checked out ("new-version") is different from version selected by view before checkout ("old-version").
This warning needs to be taken seriously. It means that the CHECKEDOUT rule is currently selecting the element, and when you check it back in, you will no longer be looking at the version you were just editing. Obviously this can lead to confusion and possible errors. Change the rules in your config_spec so that that particular version is selected whether it's checkedout or not.

Back to the INDEX.



clearviewtool/xdr/albd: Error Unable to contact albd_server on host 'hostname'
clearviewtool/cmd: Error: Unable to create view "viewstore-UNC-path".
Error 1067: The process terminated unexpectedly.

In one case, the first 2 errors occurred when attempting to create a Windows view. The problem was that the albd service was Stopped. An attempt to Shutdown and Startup the albd service via the ClearCase Properties failed. An attempt to Start the Atria Location Broker in Start -> Control Panel -> System -> Services generated the 3rd error.
This error is most likely caused by an albd user or permission problem or clearcase group problem. Check all of the following. In the Windows Services applet, go to the Properties of the Atria Location Broker. Under "Log on", ensure the clearcase_albd user is correct (DOMAIN\username) and that the password is correct. Also, start regedit and check the ClearCaseGroupName (DOMAIN\groupname) registry key value in HKEY_LOCAL_MACHINE\SOFTWARE\Atria\ClearCase\CurrentVersion.
In another case, the first two errors occurred on a Windows box connecting to a UNIX server via NFS Maestro. The problem was that the IP address as reported by ping (DNS) was not the same as that reported by ipconfig (DHCP).
If a network is running DHCP (dynamic IP addresses), the IP dynamically assigned must be propogated automatically to the DNS tables. This was not happening on the system in question. If the network admins are unwilling/unable to ensure automatic update of DNS based on the current DHCP IP assignements, then you either must set the DHCP lease to be a very long time (so that DNS has the correct info) or not use DHCP and assign a permanent IP to the Windows client.
Because of the inherent problems with ensuring IP addresses are propogated correctly throughout a network, Rational recommends static IP addresses for all servers. In the case above, Windows was attempting to create a local view, which in essence makes it a view server for that view.

Back to the INDEX.



cleartool: Error: No permission to perform operation "checkin".
While there could many reasons why a checkin operation fails, this one was caused by the username of the person checking it out consisting of/starting with a digit. The UNIX Sysadmin Manual states that a username can contain any combination of letters, digits, underscores or dashes. However, CC must have a bug in it WRT this error. Changing to any user other than one starting with a digit solved/circumvented the problem.

Back to the INDEX.



mount: Error: Operation "rgy_getinfo_by_uuid" failed ("uuid"): ClearCase object not found.
This error occurred on a Solaris 2.6 box running CC 3.2. The cause was that the particular VOB being mounted had a VOB tag, but was not registered. Simply registering it solved the problem.

Back to the INDEX.



derived-object   [no config record]
derived object   [removed with white out]

These errors show up on the command-line when doing a "ct ls" of a derived object (DO). This is the result of a "ct rmdo" on an unshared DO.
In the first case, the rmdo command removes the DO configuration record (CR), but leaves the data container alone. The data container is now a view-private file that must/can be deleted with a regular rm (or del). However, even though it can no longer be a candidate for winkin, it is still a useable view-private file.
In the second case, the rmdo command has removed the UNIX reference to the DO but left the CC view-private reference to it intact. In this case, "touch" the DO and remove it the normal way; UNIX rm or Windows del.
The specific reason why cases result in one or the other error is unknown to me.

Back to the INDEX.



cleartool: Error: view-storage isn't a view: No such file or directory
This occurs when issuing a command, such as catcs, that references a view who's view-storage is not available for some reason.

Back to the INDEX.



clearmake: Error: Problem starting promote_server for view hostname:view-storage
clearmake: Warning: Unable to promote derived object "DO"

During a build, clearmake knows, via the VOB database, that there is an already built DO in another view. However, an attempt to promote that DO to be shared in the VOB has failed. In this case the view-storage of the view owning the original DO was unavailable. If that view will never be available again, do an rmdo on the specific DO referenced by the accompanying Warning message.

Back to the INDEX.



Error renaming \\path\TBD(4): File exists.
The View Profile tree is currently in use by other users, and cannot be accessed at this time.

Both of these errors are the result of more than one user attempting to create a View Profile using the same View Profile Tree. The View Profile Tree is simply a path to where View Profiles are stored and can be anywhere the user chooses. The View Profile Tree can be reset via ClearCase Home Base -> Administration -> Control Panel -> Options. Or, you can simply wait until the View Profile Tree is idle.

Back to the INDEX.



cleartool: Error: Cannot get view info for current view: Invalid argument.
This error showed up on Windows when attempting a rmtag from the command-line. Do not have any windows that are in the MVFS drive (usually M:), even if they aren't actually inside the view whose tag is being removed.

Back to the INDEX.



cleartool: Error: Source "from" and destination "to" are in different versioned object bases.
This error occurs when attempting to create a CC hard symbolic link between VOBs. Only softlinks (-slink) can be used to link directories in any location or elements across VOBs.

Back to the INDEX.



cleartool: Error: Unable to select "view-private-file", not a selectable object "view private object".
This error shows up when attempting a "ct relocate". The relocate command does not work on view-private files and will error out if encountering one when it builds its list. Need to move view-private files somewhere else first. To find all view-private files at or below the path:
  # ct lsprivate -invob /path
If you want to simply get rid of all the view-private files, use something like:
  # rm -f `ct lsprivate -invob /path`
-or-
  # del `ct lsprivate -invob /path`
WARNING: The view-private files may be CHECKEDOUT items or derived objects. Use the -co, -do and/or -other options to isolate those cases to be handled specially.

Back to the INDEX.



element@@   [eclipsed by checkout]
This occurs when doing a "ct ls -vob_only" and is a normal message. That is, if a file is CHECKEDOUT and a simple "ls" is done, you will see the view-private version of the CHECKEDOUT file. If the "ct ls -vob_only" is done, CC will attempt to show you only files that are versioned elements. However, it can't in the case of the CHECKEDOUT file because the view-private version of that file is eclipsing it.

Back to the INDEX.



cleartool: Error: Can't create object with group (GID) that is not in the VOB's group list.
cleartool: Error: Unknown group name: group-name
cleartool: Error: Must be a member of new group.
The first error occurs when you attempt to create an object in a VOB in which you are not a member of one of its groups. In the second error, CC is telling you that the group to which the object is being changed is not even a recognized group-name on the system. The third error states that you are not a member of the group to which you are changing an object.
See the discussion in "CC group permissions".

Back to the INDEX.



Unable to get VOB tag registry information for replica uuid "UUID": ClearCase object not found.
This error occurred when attempting a checkout on Windows that was connected to a UNIX VOB via NFS Maestro. Investigation revealed that there was a checkout trigger running in the VOB in question whose script was located in another VOB that was not currently mounted on Windows. Importing the other VOB and mounting it on Windows alleviated the error.

Back to the INDEX.



cleartool: Warning: Operation "view_change_oid" failed ("element"): Read-only file system.
cleartool: Warning: Operation "view_get_fhandle" failed ("element"): not a ClearCase object.

These errors occur when attempting to check in a UNIX link that was made into an element. If one imports an entire directory tree into CC and that tree contains some UNIX softlinks, the links will be made into elements as a part of the clearimport process. However, as part of the clearimport process, the elements get automatically checked in. The first error occurs if the link is pointing to an existing element and the second if the link points to a file that is not a versioned object. In both cases, a copy of the other end of the link gets checked in. However, in the first case, a view-private file called element.keep is automatically created that is the original link. In the second case, the view-private link is left alone and the checkedin element is [eclipsed]. If links are needed, use "ct ln" once everything has been imported.

Back to the INDEX.



cleartool: Error: Unknown host 'hostname':ClearCase object not found
cleartool: Error: Operation "rgy_findbyuuid_entry" failed: ClearCase object not found.
cleartool: Error: View storage directory path not found: "error detected by ClearCase subsystem".

These errors occurred on a network whose registry server has had its name changed. Go to the registry server and change the old name to the new internal to each registry file.
Stop CC.

  # cd registry
Edit each file in turn, perhaps doing them all at once from a Perl script:
  # edit  file

Restart CC.
Back to the INDEX.


cleartool: Error: Unable to mount: Resource device
This error occurred when attempting to mount a VOB on Windows. This happened immediately following a region change. Because the old VOBs were not unmounted prior to changing the Windows's CC region, CC hung. Attempts at mounting new VOBs or unmounting the old VOB(s) resulted in the error. A stop and restart of CC did not help. A reboot of Windows fixed the problem.
When changing a region on Windows, stop all views and unmount all VOBs first. If this is done, no restart of CC or the system is necessary.

Back to the INDEX.



cleartool: Error: Can't pick element type from rules in "magic-PATH".
If the element being created doesn't already exist as a view-private file, create an empty view-private file first.
In Windows Explorer:
  File -> New -> file
In UNIX:
  # touch file
If the element being created already exists and you still get this error, add rule for the file to an appropriate magic file. See cc_magic in the CC Reference Manual.

Back to the INDEX.



text_file_delta: Error: "filename" is not a 'text file': it contains a '\000'.
cleartool: Error: Type manager "text_file_delta" failed create_version operation.

These errors occur when attempting to check in an ascii file that has a binary character emebedded in it somewhere. Simply remove the offending character. In Perl, use code similar to the following:
open(FILE,"filename");
while (<FILE>) {
  print if $_ =~ /\0/;
}
close(FILE);
exit;
Back to the INDEX.


cleartool: Error: More than one version with label of type "label-type".
This error occurs when the following command is run on an element that has the specified label attached to more than one of its versions.
  # ct mkbranch -ver label branch element
The mkbranch subcommand needs to create a branch from a unique version. In this case, the element had two instances of the label. Simply don't use "-ver label" and instead specify element@version.

Back to the INDEX.



cleartool: Error: The VOB storage directory "VOB-storage" was not found.
cleartool: Error: Could not register gpath in the prefix map.

These errors occur when attempting to mount a VOB (first msg) or start a view (second msg) from the CLI for a VOB and/or view whose server has either had its name changed or is not available. The GUI error message is null. That is, a CC error box pops up, but there is no error message.
If the server that owns the view/VOB has had its name changed, the view and VOB global paths will have to be reregistered and retagged.
  # ct unregister -view -uuid UUID
  # ct rmtag -view view-tag
  # ct register -view view-storage
  # ct mktag -view -tag view-tag view-storage
The steps are synonymous for VOBs.

Back to the INDEX.



cleartool: Error: Unable to find replica in registry for VOB with object ID:"UUID"
cleartool: Error: Unable to determine administrative VOBs of VOB "vob-tag".
cleartool: Error: Unable to locate versioned object base with object id: "UUID".
cleartool: Error: Unable to search for process guards
cleartool: Error: Unable to remove hyperlink "hyperlink-id".
? <- <object not available>

The above set of errors occurred when attempting to remove an AdminVOB hyperlink. In this case, the administrative VOB was no longer available. The first and third errors occurred when creating a stream in a PVOB. The component VOB was the AdminVOB and one end of a RelocationVOB for a VOB that was no longer available. The last error message appears if one does a "ct describe" on the offending object.
In general, these errors can occur any time a hyperlink is "broken". For example, if a MetaData type is defined in an admin VOB and is used/applied in a client VOB, a GlobalDefinition hyperlink is connected between the type definition in the admin VOB and the one in the client VOB. If the client VOB is subsequently removed, you won't be able to remove the offending, globally defined MetaData without running the checkvob command on it. Normally the GlobalDefinition hyperlink can be removed if the globally defined MetaData type definition is replaced with a local definition, but not in this case.
In these cases, the following types of commands will prompt for any dysfunctional hyperlinks and ask if you want them removed.
  # ct checkvob -hlinks vob:vob-tag
  # ct checkvob -hlinks brtype:branch-type
  # ct checkvob -hlinks lbtype:label-type
Back to the INDEX.


cleartool: Error: Operation "rgy_getstring_from_entry" failed: ClearCase object not found.
This error occurs when running "ct rmview -uuid view-uuid" in a VOB when the view's storage area has been removed without using CC commands. This error is to be expected. When you run "ct rmview -uuid", CC removes references to the VOB from the view's database and then removes references to the view from the VOB's database. However, in this case the view's database no longer exists. The error message is then followed by a message stating that the VOB was cleaned up successfully. The upshot is that this error is to be expected if the view storage is not available.

Back to the INDEX.



The network path was not found.
cleartool: Error: Could not register gpath in the prefix map.

On Windows, the above errors occur when attempting to mount a VOB or start a view whose storage area is unavailable for some reason. The second error occurred when attempting a startview from the CLI. The first occurred when attempting a simple "dir storage-area" from the CLI. One should be able to see the contents of the storage area via the registered path independent of CC.
If the server trying to be reached is available (ping) and the drive on which the storage areas live is properly shared, try going to Control Panel -> Network -> Protocols -> TCP/IP Protocol (Properties...) -> WINS Address and set "Enable DNS for Windows Resolution".
NOTE: In Windows, from the GUI, the above condition will result in a CC error box that has no error message in it.

Back to the INDEX.



mvfs: Error: view shtest - all licenses in use!
This occurs if your license expires while in a view and you aren't able aquire a new one. Use clearlicense to release a license or wait until one becomes available. Alternatively, have the CC Administrator purchase more licenses.

Back to the INDEX.



element   [loaded but missing]
This occurs in a snapshot view when the loaded file has been deleted. If the element is checkedout, simply do an uncheckout. If the element is checkedin, update the view.
This also occurred when running a snapshot view remotely. That is, Windows ClientA sets up a snapshot view and ClientB accesses that snapshot view via a Windows share. The checkout of an element from ClientB works ok, but a checkin or uncheckout leaves the file [loaded but missing]. Unknown cause or solution. According the CC 3.2.1 Using Snapshot Views manual(pg 80), this configuration should work fine.
This is analogous to a dynamic view's [checkedout but removed].

Back to the INDEX.



cleartool: Error: The feature level of at least one replica is unknown; the VOB family feature level can not be raised.
cleartool: Error: Unable to raise the VOB family feature level - error detected by ClearCase subsystem

These errors occur when attempting a "chflevel -family" and there is a member of the family that is not up to the level to which you are attempting to raise the family. See chflevel. If each self-mastering replica has successfully raised its own feature level and all those VOBs have sync'ed back with the VOB attempting the "chflevel -family" and you still get the error message, check "mt lsreplica". There may be a replica name known to the VOB family that is not really a replica. That is, there may be a replica name just hanging out there that can simply be deleted with "mt rmreplica".
However, you will always get this error message if the replica synchronization is unidirectional. That is, if the sync packets only go in one direction, the current VOB will never know about the feature level of the other replicas. In that case, you must use the -override option. Just be sure that the chflevel command to the new level has already been run manually on the remote site's replicas.

Back to the INDEX.



Error copying file "albd.z" Access is denied.
This error occurs when attempting to overwrite a Network Release Area. When the previous setup of the release area completed, it set files to read-only to protect them. Rational recommends using separate release areas for separate releases. However, if you must overwrite the existing release area, simply go there and change the files to be writeable.

Back to the INDEX.



element   [disputed checkout, checkedout but removed]
This happened as a result of the following events. 1) Created cleartool hardlink to another element. 2) Checkedout the new end of the hardlink. 3) Checked in the parent directory of the new end of the hardlink. 4) Checkedout the parent directory of the new end of the hardlink. 5) Did "ct rmname" on the checkedout new end of the hardlink. This left the other end with the error message. However, attempts to reproduce the error to better understand it failed. That is, I could only create the standard [checkedout but removed] error, which is corrected by simply doing an uncheckout on it. All attempts to get it say "disputed checkout" again failed.

Back to the INDEX.



Error: failed to load DLL ntadmin.dll: -1
This error occurred when attempting to apply patches to a release area that has just been upgraded to CC 3.2. The patch executables need a dll that doesn't currently exist on the system and won't until after the 3.2 install. So, to get around this error, do the install without any patches on the machine on which the release area resides. Once the install has completed, the patches can be applied to the release area without error. Then, simply rerun the install from the patched release area.

Back to the INDEX.



ERROR: Your CWD must be the install sub-directory within the patch sub-directory of a release area.
CC UNIX patches cannot be applied directly to the install, they must be applied to a release area from a sub-directory within the release area. For more notes on installing CC patches, see ./cc_howto.html#MISC31.

Back to the INDEX.



cqconfig: Can't create checkin trigger!
This error occurred when attempting to integrate CC with CQ on Windows connected to UNIX VOBs via NFS Maestro. Both machines were running CC 4.0, patched to the latest level, and the UNIX side had the "ClearQuest Integration with ClearCase" installed. When attempting to integrate the two tools from the Windows side via the "ClearQuest Integration Configuration" wizard in the ClearCase Administration menu, the error only occurred if the VOB was on the UNIX side. That is, Windows VOBs integrated with no problem. The interop connection was verified independent of the integration. That is, I was able to create and work on UNIX VOB elements via Windows.
The problem was that the usernames were not matched between Windows and UNIX. While normal operations work ok without a one-to-one match in usernames, to set up the integration from the Windows side, your interop connection needs to log you into the UNIX side as the VOB's owner. Once the ownership was straightened out, the integration worked as expected.

Back to the INDEX.



cleartool: Error: There are no generated data sources available for storage dir "vob-storage" on host "hostname".
cleartool: Error: Failed to get space info for vob "vob-tag".

This error occurs when attempting to use the space command in an empty VOB. It simply means that there is nothing to report. Ignore it.

Back to the INDEX.



cleartool: Error: Trouble protecting versioned object base "vob-tag".
This error occurs when attempting to modify protections on the VOB itself via the "protectvob" command. You must be VOB owner or root to change VOB protections.

Back to the INDEX.



cleartool: Warning: Moved private data from "file" to "file.keep" so it won't eclipse element.
A new element can be created if a view-private file of the same name does or does not exist. In the case where there is an existing view-private file of the same name as the new element, it depends on the mkelem options used as to whether that view-private file's contents will be copied to the new element. For instance, if the -ci option is used, CC creates a new empty element, checks-out the 0'th version, copies the view-private data into the checkedout version and then automatically checks it in. However, if the -nco option is used, CC will create the new empty element but does not check it out. So, if the element isn't checked out, there is no way for the view-private file's contents to be copied over. If CC simply left it at that, the view-private file would eclipse the source controlled version (which is normal), hence the warning message.

Back to the INDEX.



Unable to assign drive to view: error1202.
This error occurs when you attempt to map a view to a drive letter that is in use. Normally, drive letters that are in use are not even presented to you as options. However, on Windows, CC 4.0 UCM up to at least patch 9, defaults to drive letter Z even though it is in use when creating views via the Project Explorer. Simply choose a letter other than Z, as it appears that this bug only applies to Z and the other drive letters it presents you are ones not being used.

Back to the INDEX.



clearexport_ccase: Error: Unable resolve pathname "view-private-file".
The clearexport_ccase command only works on versioned objects. If there are any view-private files in the tree selected for copy, they will each generate the error message. Simply ignore the error.

Back to the INDEX.



cleartool: Error: Unable to unmount: error detected by ClearCase subsystem
This error occurred when attempting to unmount a VOB on Windows in CC 4.0. No windows were inside the VOB. A restart of CC failed to clear the error. Since this was a private VOB, it wasn't remounted upon reboot. Cause of the error unknown.

Back to the INDEX.



cleartool: Error: vob-tag is not a registered VOB tag.
After running "rgy_check -vobs" on Windows running CC 4.0 and seeing that a VOB tag had no storage associated with it, this error occurred when attempting a rmtag. Inspection of the ccase-home-dir\var\rgy\vob_tag file revealed that the tag was in a region other than the one to which the server was pointing. Use of the -region option to rmtag solved the problem.

Back to the INDEX.



Error checking in 'element'.
Trigger "cq_ci_trigger" has refused to let checkin proceed.

There can be many reasons why cq_ci_trigger refuses the checkin. This error only shows up when CC is integrated with CQ in a non-UCM manner via the ClearQuest Integration Configuration wizard in the ClearCase Administration menu.
1) Depending on the policy you've set up, CC will require a bug number when to complete the operation. If the window that pops up requesting a CQ record ID be associated with the CC checkin and you click OK without explicity clicking the Associated button first (or you hit the Cancel button), the error will result.
2) If you've run the ClearQuest Integration Configuration wizard in the ClearCase Administration menu, but the CQ database has not been configured to use the CC integration, the error will result. See integrating CC/CQ w/o UCM for details.

Back to the INDEX.



Error: albd_server must run in the clearcase group
This error can occur on Windows if your albd_server login (most likely clearcase_albd) is not attached to any group or the group that CC thinks the albd_server lives in is incorrect. This can happen if one has changed the name of the clearcase_albd user and its group. If, after changing the username and password in the Atria Location Broker service, you still get the error message, make sure the Windows registry has been properly updated. Start regedt32 and check the following key:
HKEY_LOCAL_MCHINE->SOFTWARE->Atria->ClearCase->CurrentVersion:ClearCaseGroupName
Be sure to reboot the machine after manually editing the registry.

Back to the INDEX.



clearimport: Error: Newer version in VOB blocks import of version "version".
This error occurred when attempting to update existing elements using the clearexport_*/clearimport commands. If the import is done by the VOB owner, the modification dates of the files are unchanged. If the import is done by the VOB owner or any other user and the -nsetevent option is used, the modifications date/time of each element is set to the time of import. If one tries to do a subsequent import of files with the same names that have modification dates earlier than those checked into the VOB, the error will occur. In short, clearimport will not update an existing element with a file with an older modification time.
The following scenario can cause that to happen. Somebody sends you a set of files in a directory structure for import into a VOB. Before you get around to importing them, they send you an updated version of that directory tree. Now, you could "merge" the two outside CC and attempt to determine which files are different, but it's much easier to simply import the first version and then simply update the changed files with new versions. So, you import the first set of files using the -nsetevent option, perhaps because you are not VOB owner, and the modification times of the those files are reset on import. Now, you go to import the second set of files to update the VOB, but the modification times of that set are older than the ones now in the VOB. Error.
To get out of this situation you can do one of the following. 1) Delete the elements in the VOB and redo both imports as the VOB owner without using the -nsetevent option. That way the modification times stay in the correct order. 2) Manually determine which files have changed and update those ones by hand in the VOB. On Windows, WinDiff.exe can diff two directory structures for you. On UNIX, do an "ls -lR" of each tree into separate files and use diff.

Back to the INDEX.



Runtime Error! Program:C:\PROGRA~1\RATIONAL\CLEARQ~1.0\CQINTS~2.EXE
R6025 - pure virtual function call

This error occurred with CC integrated with CQ using UCM while checking out an element and associating a ticket with that activity. However, further fiddling could not reproduce the error. After a second attempt, the ticket was updated correcty and there seemed to be no lasting affects. Reason for the original error unknown. What's curious is that the error mentions CLEARQ~1.0, but this system was running CQ 2.0.

Back to the INDEX.



rcptcp_create: RPC: Remote system error - [WINSOCK] Connection refused
clearlicense: Error: unable to contact albd_server on host 'hostname'
NPLogon /xdr/albd: Error: Unable to contact albd_server on host 'hostname'

The first two errors occurred when running clearlicense between a CC 4.0 client and CC 3.2.1 license server. The first attempt at reaching the license server used TCP/IP. There is a known bug (CMBU 44216) that prevents this from happening. However, if TCP fails, CC will immediately try UDP, which then succeeds. So, for the time being, Rational considers this bug to be cosmetic and has given it low priority. Simply ignore it.
However, these error messages, including the third, can also occur if the albd service on the specified license service is down for some reason.

Back to the INDEX.



can't unload the module: Device busy
This error occurred on a UNIX system that had crashed due to overheating. After the system was brought back up, there were problems with getting the VOBs remounted. All attempts failed. Attempts to shutdown and restart CC resulted in the error message when it gets to the point saying "Unloading mvfs...". Unfortunately, all attempts to recover the system short of a reinstall failed.
Due to the nature of this problem, a simple reinstall of CC over the old one, as if doing an upgrade, is not sufficient. Corrupt files may have the same modification date and not get properly replaced.
The deinstall won't go unless it can shutdown CC. However, CC won't shutdown properly due to the error message. So, you must mv the /etc/init.d/atria file to a different name and restart the computer. When it comes back up, CC won't be started. Once that is complete, you may procede with the deinstall. Even though the deinstall will make a copy of the registry, you should probably make a copy of /var/adm/atria yourself just to be safe. Note that a patch in CC 2002 and 2003 changed the name of the startup file to /etc/init.d/clearcase.
Once the reinstall is complete, all should be fine.

Back to the INDEX.



view_server(PID): Error: Unable to construct cleartext for object "element" in VOB "host-path": error detected by CLearCase subsystem.
view_server(PID): Error: Type manager "type-manager" failed construct_version operation
text_file_delta: Error: Unable to open file "UNC-path-to-data-container": Permission denied
text_file_delta: Error: Unable to open file "UNC-path-to-data-container": Invalid argument
mvfs: ERROR: view=view-tag vob=vob-tag - ClearCase vob error see view_log on host hostname for more info
cleartool: Warning: Version checked in is not selected by view.
The first three errors appeared in the Windows Event Viewer and view logs. The fourth was a warning in the Windows Event Viewer. The fifth error appeared as a pop-up dialog when the error occurred. The sixth appeared on the CLI at the time of the error.
These errors occurred in a Windows view accessing a UNIX VOB via Syntax TAS. One was able access the VOB normally for all operations except checkin. One could add files to source control as well.
The procedure for configuring TAS was followed exactly and rechecked. However, even though one maps the Windows clearcase_albd user to the UNIX vobadmin VOB owner, one still needs to add vobadmin as a recognized Totalnet User. That is, the procedure is inadequate in that it assumes the map is sufficient for TAS to recognize vobadmin. After adding vobadmin as a user, all was well. I am unable to explain why one could add files to source control without issue but had trouble checking them in.

Back to the INDEX.



view_server.exe (PID): Error: Can't determine if the file system on which "." lives supports acls.
The drive on which a VOB or view's storage lives must give Full Control to the SYSTEM.

Back to the INDEX.



msdostext_mode: Error: Operation "ver_unformat_cltxt" failed: ClearCase object not found
This error occurs when attempting to convert a VOB to interop with the msdostext_mode command. It is an indication that permissions are not sufficient. You need to be the VOB owner or Administrator/root to run the conversion. If the error persists and you are the VOB owner, it's possible that there are UIDs in the VOB that no longer map to an active user. In that case, attempt it as root. Also, try running "ct protect -chown vob-owner -r" on the VOB's files. Also, consider running "ct protectvob -chown vob-owner -chgrp vob-owner's-group" on the vob-storage-area. Once the permissions are sorted out, the command should complete ok.

Back to the INDEX.



The instruction at "reference_number" referenced memory at "memory_location". The memory could not be "read".
Reinstall and reboot had no affect. No solution at this time.

Back to the INDEX.



Unable to login: username or password is incorrect
This error occured when attempting to access CC via the web interface just after configuring it on RedHat LINUX 7.0. LINUX MD5 and shadow password defaults are selected on installation of RedHat LINUX and need to be deactivated. As root, from the CLI, run authconfig. Clear the check boxes that enable MD5 encryption and shadow passwords.
NOTE: Users that already have passwords on the system need to run "passwd" to reset them. That is, they need to be reencrypted, this time without MD5 encryption.

Back to the INDEX.



cleartool: Error: Unable to access database (format too old): "vobtag".
This error occurred after upgrading CC to a version that requires a reformat of the VOBs. This is true when upgrading to 4.x and accepting the new extended VOB format (schema 54). One should have backed up the VOBs just prior to the upgrade. However, if not, the next step would be to back them up just prior to the reformatvob. Unfortunately, if the upgrade is already done, the VOBs cannot be locked due to the above error. If you've gotten to that point, there is no recourse but to simply run the reformatvob without backing them up.

Back to the INDEX.



vob_snapshot_setup encountered an ERROR in modparam: Vob tag is invalid
This error occurred while setting up VOBs for nightly database snapshots. The VOB in question was tagged in the same region as the other VOBs, but its storage area was on a different server. The VOB storage area must be on the server you are sitting in front of when the vob_snapshot_setup is run.

Back to the INDEX.



Error copying file "albd_spec.rgy". Access is denied.
Error copying file "albd_spec.rgy". The process cannot access the file because it is being used by another process.

These errors occur when attempting to simply rerun the siteprep.exe on Windows to change a parameter, such as region name. These errors are new in CC 4.2. That is, one could simply rerun the site prep anytime without incident in CC versions prior to 4.2.
The first error occurs when making the first attempt at rerunning the site prep. The second error occurs if you remove the "Read Only" status of the mentioned file and attempt to run the site prep again.
The file is being read by siteprep.exe, which means it has the file open for read and therefore cannot write to it. If desired, run the siteprep.exe directly from the cdrom and set all the parameters. Or, if a simple change is needed, just open sitedefs.dat and edit the parameter manually.

Back to the INDEX.



cleartool: Error: Checked out version, but could not copy data to "filename" in view: unknown error in VOB.
This occurred in a UNIX view using CC 4.2. All attempts to clear the problem, such as restarting the view_server process, failed. However, for unknown reasons, after setting to a different view that had the same config_spec, checking out the file and immediately unchecking it out cleared the problem in the first view.

Back to the INDEX.



cleartool: Error: Unable to determine absolute pathname for "\vobtag" - Permission denied
cleartool: Error: Unable to access "\vobtag": Input/output error. cleartool: Error: Set activity operation failed in view. More information might be available in view_log on host

Updated: 02/12/16
Version: 7.1.2.14

These errors occurred when attempting access a VOB on Windows using CC 4.2. For unknown reasons, stopping and restarting CC cleared the errors. Note, the first access to the VOB after restarting CC took awhile.

This error was also encountered after removing test VOB tags from the production region. A restart of the CC services didn't help and restart of the workstation didn't help. Permissions on the VOB were verified to be the same as other VOBs. The "credmap " showed that credentials were mapped correctly. However, the creation of a new view resulted in the third error above. Also, existing views that were created on that view server produced the same error. However, the creation of a view local to the workstation succeeded. Moreover, that new view could access the test VOB without the permissino denied error. So, it wasn't a VOB "access denied" error, but rather a view issue.
The problem was that the views were UCM views associated with UCM streams. The view server was pointing to the production region. The views were created and were working in the test region. Previously, the test VOBs had tags in the production region with "_test" in the VOB tag. Those tags were removed because it was determined that we shouldn't have test VOBs tagged in that region. However, when creating or accessing a view stored on a view server that is only looking at the production region, it must be able to see the PVOB where the stream is defined that is associated with the view.
Do one of the following to solve this:
1) Restore the test VOB tags in the production region so the view server can see them.
2) Establish a view server specifically for the test environment that points to the test region.
3) Create views on the local workstation that only need to work when the workstation is pointing to the test region.

Back to the INDEX.



vobsvr_contact call failed: RPC: Unable to receive; errno = [WINSOCK] Connection reset by peer
This error occurred when attempting to get a description of a VOB on a Win2k system running CC 4.2. A reboot of the system cleared the problem. Unknown reason for the error :-(.

Back to the INDEX.



Could not decrypt the Server Process password in site defaults file "path\sitedefs.dat".
This error occurred when attempting to run a siteprep in an existing Windows CC release area. For unknown reasons, the sitedefs.dat file that saves the siteprep data was corrupt. Simply move the existing sitedefs.dat file to .bak and let the siteprep create a new one.

Back to the INDEX.



cleartool: Error: View tag "": ClearCase object not found
cleartool: Error: Operation "view_get_handle_by_tag" failed: error detected by ClearCase subsystem.
cleartool: Error: No view context available

This error occurs when attempting to get CC information that requires a view context and you are not currently in a view. For example, if you are sitting on "C:\" and run "ct lsactivity", since activities are UCM stream/view dependent, you will get an error that the view is unknown. Either change your directory into a drive letter associated with a view, or supply an appropriate argument, such as "ct lsactivity -view <view-tag>".

Back to the INDEX.



mount: Error: Unable to get hostinfo for hostname
Trouble mounting the viewroot "/view" (16:1)
Trouble setting MVFS kernel log file to /var/adm/atria/log/mvfs_log (2:1)
cleartool: Error: The MVFS file system is not installed or not loaded, or the 'viewroot' is not mounted or is inaccessible: not a ClearCase object.

These errors occurred at the end of a CC 5.0/2002 install on Solaris 8. The install seemed to complete properly, but CC was unable to start itself. The problem was a mismatch in what the server thought its name was. The commands "hostname" and "uname -a" and the /etc/hosts file all reported the same name, but the /etc/nodename file had a different name. Editing the nodename file directly and rebooting seemed to have no affect. A complete deletion of the nodename file caused the server to have an "unknown" name. Adding the nodename back with the correct name solved the problem.

Back to the INDEX.



Error Description: timed out trying to communicate with ClearCase remote server. Error Code: 1004
This error occurred when attempting to run a report from within the CC Report Builder on a stand-alone Windows box. The machine can ping itself by name. The albd service is up. The PVOB is and components are accessible via other utilities. Unknown reason for the error.

Back to the INDEX.



RCCO1.0: Error: Unable to lookup "vobs": No such file or directory.
This error occurred in the RCCO interface when attempting to Update a single element in a view. This was done in a view that had never been used before. When a checkbox for an element is selected and the Update button is clicked, a screen appears confirming the download. Because the files have never been loaded into the view, you must select Load instead of the default Update. This will create a directory in your view on your local box called "vobs" that has inside of it the component and any downloaded elements.

Back to the INDEX.



ClearCase daemons: Albd server startup error(4:1)
This error occurred when attempting to start CC on a Unix box. This happened after a rename of the server. An entry in error_log indicated that there was a problem with the view_tag file. The registry files had been edited by hand as part of the server rename to avoid the numerous rmtag, unregister, mktag, and register commands. However, an erroneous character was placed on a line by itself at the end of the file, as indicated by the error message in the error_log. A simple cleanup of that line fixed the problem.
I have since written a script to run all the CC commands properly when a view or VOB server has been renamed.

Back to the INDEX.



cleartool: Error: Checked out version, but could not copy data to "element" in view: Operation not permitted.
This is a permission issue. The group on the element itself was not in the VOB's group. A "ct protect" to change the group of the element solved the problem.

Back to the INDEX.



/lib/modules/fs/mvfs.o: unresolved symbol ...
The "unresolved symbol" errors occured after installing CC on a Linux box. These errors caused MVFS to fail. You need to recompile mvfs.o in a configuration that works for your system.
The particular config file chosen in step (2) will deterime whether or not mvfs will compile and work when atria is restarted. That is, the actual .config file shown in step (2) is the one that solved my problem, but may not be the one you need to get mvfs to recompile and restart without errors. The following steps must be performed as root. No kernel rebuild or reboot necessary.
1) cd /usr/src/linux/configs
2) cp kernel-2.4.7-i686-smp.config ../.config
3) cd /var/adm/atria/mvfs/linux*
4) make
5) /etc/rc.d/init.d/atria stop
6) /etc/rc.d/init.d/atria start

Back to the INDEX.



db_obj_resolve_name_V3: RPC: Unable to receive; errno = Connection reset by peer
db_abort_trans_V3: RPC: Unable to receive; errno = Connection reset by peer

These errors occurred while running clearfsimport using "-preview" and "-mklabel" at the same time. This is a known defect that is supposedly fixed in CC 2003.06.00. If you want to run with -preview, leave off the -mklabel option. When you want to run it for real, leave off the -preview option and insert the -mklabel option.

Back to the INDEX.



Segmentation fault
This error occurred when starting xclearcase (2002.05.00, patch 26) and some other GUIs on RedHat 9 Linux. The out-of-the-box LANG environment variable setting is "en_US.UTF-8". This needs to be reset to "en_US" or "en_US.iso885915". Each user can "setenv LANG en_US". Unsure how set the LANG for the whole system.

Back to the INDEX.



Couldn't mount VOB: vobtag
This error occured on a Windows box running CC 2002. The VOB was one that was removed. It's name is stuck in the registry as one that is to be remounted after reboot. See Enable/disable VOB auto-remounting after reboot.

Back to the INDEX.



text_file_delta: Error: Can't create temporary file: Permission denied Type manager "text_file_delta" failed create_version operation.
Updated: 03/28/07
A possible cause of this error is an undefined temp directory.
Create a system environment variable called "TMP" and point it to a temp directory, such as C:\temp or /tmp.

Back to the INDEX.



cleartool: Error: Attempt to get location information on "\\machine\share\view.vws" failed: Input/output error
Updated: 04/25/11
This error occured when attempting to mktag for a view on Windows.
The reason for the error is unknown. However, the tag can still be created by:
- Open the cchostadmin.msc executable (CC storage admin console)
- Expand the view storage under Views and right-click on Tags.
- Select New -> Tag.
- Fill in the Tagname and Path to Storage. If the path is really long, exit the Create New View Tag dialog, right-click on the view storage, choose Properties, and grab the global path from under the Advanced tab.
- You'll get the same error in a pop-up. However, it will give you the additional option to create the view without verification. Click Yes.

Back to the INDEX.



java.lang.NullPointException
Updated: 04/17/14
Version: 7.1.2
This error occured when left-clicking on a view in CCRC.
The view in the ClearCase Navigator pane was dragged to the Desktop. After that, left-clicking on the view tag in CCRC causes the error. There were other errors too.
The view's contents are viewable from the Desktop folder, but you can't perform any CC operations. You have to move the folder back to its original location.

This error also occured when attempting to Refresh -> Repair Discordance. This error was associated with the ability to see VOBs and UCM components, but no subfolders/files get loaded into the CCRC view.
The cause was that the user had created a base CC view instead of a UCM view associated with an existing stream.

Back to the INDEX.



clearfsimport: Error: Unable to determine VOB for pathname
Updated: 06/16/11
This error occured when attempting clearfsimport into a CCRC view.
Though not documented for clearfsimport, according to Rational Support it's not possible to use that command (or clearimport) with CCRC (web) views.

Back to the INDEX.



RegOpenKeyEX failed:
Updated: 07/08/11
Version: 7.0.1.12
This error occured when attempting to run clearbugnt.exe after a bad install.
The install asked for a reboot before it completed all of its registrations. The reason for that is under investigation. However, I was unable to run clearbugnt to gather data for Rational Support. That error message is a generic one saying that it can't find the registry entry it was looking for. When the reason for the bad installs is discovered, this error will probably go away too.
While clearbugnt is currently bundled with CC, Rational Support can provide a newer version called clearbug2. The clearbug2 executable ran even where clearbugnt did not.

Back to the INDEX.



The server cannot be contacted. Please contact your system administrator.
CRVSV0072E server error occurred while processing request

Updated: 04/03/14
Version: 7.1.1
This error occured when attempting to connect to a web server using CCRC.
The user could make a connection to the web server by typing the CCRC connection URL into a web browser. Other users could connect using CCRC.
See the following technote for other potential solutions:
https://www-304.ibm.com/support/docview.wss?uid=swg21373322
The solution that worked in this case was to add "C:\Program Files\IBM\RationalSDLC\common" to the Path environment variable. The Path variable may not get updated if the install was not Run As Administrator.

Back to the INDEX.



ClearCase asks for a reboot prior to Setup Complete
Updated: 08/02/11 Version: 7.0.1.12
The reboot request popped up before the installation completed. After the reboot, the installation attempted to continue, but was corrupted.
Inspection of the clearbug2 output logs revealed the following. Note that AlrtAgnt is a third-party executable installed as part of the computer image applied to the computer. Doing a manual "End Process" on that executable allowed CC to install properly.
If CC doesn't install properly, look inside the installation logs for clues.
---
Info 1603.The file C:\WINDOWS\system32\mswinsck.ocx is being held in use.  Close that application and retry.
MSI (s) (2C:80) [08:36:53:021]: Product: IBM Rational ClearCase. The file C:\WINDOWS\system32\mswinsck.ocx is being held in use by the following process Name: AlrtAgnt , Id 2196.

Info 1903.Scheduling reboot operation: Deleting file C:\WINDOWS\system32\mswinsck.ocx. Must reboot to complete operation.
Info 1902.Scheduling reboot operation: Renaming file C:\WINDOWS\system32\TBM4B.tmp to C:\WINDOWS\system32\mswinsck.ocx. Must reboot to complete
---
Back to the INDEX.


internal error: cannot add shortcut because it is not unique
Updated: 10/03/11
Version: 7.0.1.8
This error occurred after joining a UCM project and creating a new view in the CC Explorer. The system asks you if you want to add the view shortcut to the project folder. If you say yes, you get the error message.
The problem is that the view has already been automatically added to the project folder and cannot be re-added.
The solution is to close and reopen the CC Explorer.

Back to the INDEX.



cleartool: Error: unable to create directory \\machine\share\vws: You were not connected because a duplicate name exists on the network.
Updated: 01/13/12
Version: 7.0.1.8
This error occurred when attempting to create a view on a remote machine for the first time.
The problem is as stated. There is more than one DNS entry with the machine name.
This can't be solved by a CC admin. You need to contact your IT department and have them fix the DNS entries.

Back to the INDEX.



OLE exception from "ClearCase.Application.1": Unable to access "extended version path": Invalid argument.
Updated: 01/19/12
Version: 7.0.1.8
This error occurred inside a Perl script calling the CAL $CC->Version("version_path").
The return from the "find" command has a newline at the end that needs to be stripped first.
	# Example:
	$version_path	= `cleartool find \"$file\" -version lbtype("Approved") -print 2>&1`;
	chomp($version_path);
	$version_o	= $CC->Version($version_path);
Back to the INDEX.


cleartool: Error: Unable to lookup task "id": Invalid argument.
Updated: 01/24/12
Version: 7.0.1.8
This error occurred when saving the schedule file after running "ct schedule -edit -schedule".
The "task_registry" file needs to be updated first with a task definition before the task can be scheduled as a job. That is, the "Job.Task: task-id" line needs to correspond to an entry in the task_registry file. In Windows, that file is in ccase-home/var/scheduler/tasks. It can be edited with any editor.

Back to the INDEX.



cleartool: Error: Unable to lookup job "id": ClearCase object not found.
Updated: 01/24/12
Version: 7.0.1.8
This error occurred when saving the schedule file after running "ct schedule -edit -schedule".
When creating a new entry in the schedule database, don't give it a "Job.Id". The system will provide one automatically and store it in the binary version. You can run "ct schedule -get -schedule" to see what ID it assigned. After that, you can use "ct schedule -get -job id" to get that specific job.

Back to the INDEX.



Unable to load input file: C:\Program Files\IBM\Rational\ClearCase\_jvm\jvm
Updated: 01/24/12
Version: 7.0.1.0
This error occurred when attempting to install CCRC.
The top level directory of the install area has a .jar file that is a self-extracting executable. Executing the jar file will result in the error. You need to execute the setup.exe file in the setup subdirectory. See https://www-304.ibm.com/support/docview.wss?uid=swg21250891

Back to the INDEX.



Could not load wizard specified in /wizard.inf (104)
Updated: 01/24/12
Version: 7.0.1.0
This error occurred when attempting to install CCRC.
Executing the setup.exe from a share using a UNC path will result in the error. See https://www-304.ibm.com/support/docview.wss?uid=swg21220732 The solution is to copy the install directory to your local box and run setup.exe there.

Back to the INDEX.



ccweb: Error: Element "", branch "\main" is mastered by replica "".
Updated: 03/02/12
Version: 7.0.1.0
This error occurred when attempting a checkout in CCRC.
In the CC Explorer, it's possible to create a view for an existing UCM stream without "joining" the project again. However, in CCRC, you must Environment->Join a UCM Project to get a new view. If you use "Create a View", it will create a base CC view that will work on the main branch. As it happened in this case, the main branch was mastered elsewhere.

Back to the INDEX.



Unable to get contents of directory ccweb-view-vob-path: permission denied
Updated: 03/03/12
Version: 7.0.1.0
This error occurred when attempting to access a VOB in CCRC using a view and VOB that had been accessed sucessfully before.
It's unknown if the following is true at all sites. In this case the server was running Windows XP. The login is the user's standard domain login and password. However, you may need to provide a domain before the login, as in "NAMERICA4\E559055". If so, always prepend the login with the domain. If you do, the directory created for your view will be "E559055.NAMERICA4" in the cc-home\Rational\ClearCase\var\ccweb directory. If not, it will be created as "E559055.server-name". The problem then is if you originally logged in as "NAMERICA4\E559055" and created a view, then later logged in just as "E559055", you'll be unable to use the view created earlier. Views can be created by logging in either way, but then you must be consistent when logging in subsequent times.

Back to the INDEX.



Set activity operation failed in view. More information might be ...
Updated: 04/18/12
Version: 7.0.1.8
This error occurred when attempting to join a UCM project in the CC Explorer.
This error occurs on Windows 7 if the CC executables are not "Run as Administrator". In Windows 7, all CC executables must be run that way.

Back to the INDEX.



Error: "Unable to connect to server at "http://server/TeamWeb/services/Team""
Updated: 04/25/12
Version: 7.0.1
This error occurred when attempting to connect to a new CCRC 7.1.2 server.
7.0.1 CCRC clients cannot connect to 7.1.2 servers.
Warning: before upgrading to the 7.1.2 CCRC client, remove all views associated with the old server. The 7.1.2 client cannot connect to the old 7.0.1 server, so there will be no way to access those views after the client upgrade.

Back to the INDEX.



WSWS3035E: Error: com.ibm.rational.stp.ws.teamservice.VersionHandler.handleFault threw RuntimeException
Updated: 04/25/12
Version: 7.1.2
This error occurred when attempting to connect to a new CCRC web server after upgrading to 7.1.2 client.
Ensure the primary group is set. Go to Windows -> Preferences and under ClearCase Remote Client -> Groups, set the ClearCase Primary Group.
Wow. What an utterly useless error message!

Back to the INDEX.



CRVAP0239E Error: CRVSV0078E Error from RPC server: CRVSV0841E 'error detected by ClearCase subsystem Request failed in method UcmStreamProps::fetch_prop with status 1001(file=\nucor\server\stp\ccrpc\ucmstreamprops.cxx, line=309)'
Updated: 08/16/12
Version: 7.1.2
This error occurred when attempting to get My Activities in CCRC.
There is a second CQ database on your CCRC server, in a different registered schema repo, which has the same name as the CQ user database to which the current UCM project is connected. This is not a supported configuration.
For an unknown reason, each schema repo definition was duplicated on the server. Removing the duplicate entries solved the problem.
See http://www-01.ibm.com/support/docview.wss?uid=swg21395849.

Back to the INDEX.



server name: Clearcase not running on host (maybe Attache' client)
Updated: 09/07/12
Version: 7.0.1.8
This error occurred when attempting to get hostinfo on a Windows XP machine that did have CC running properly.
Ensure the albd_server.exe service is running. If ALBD is up and running, ensure port 371 is opened up on the server as UDP. CC requests information over that port. See http://support.microsoft.com/kb/308127 for information about opening ports on Windows XP.

Back to the INDEX.



ks_clienttxp_create: RPC: Remote system error - [WINSOCK] Connection timed out
cleartool: Error: Cannot bind an admin_server handle on "hostname".

Updated: 09/07/12
Version: 7.0.1.8
This error occurred when attempting to get "hostinfo -properties" on a Windows XP machine that did have CC running properly.
If you are able to get a hostinfo answer without the -properties option, on the remote server add "albd_server.exe" as an exception in the firewall of the local area connection.

Back to the INDEX.



Operation "mount_pname_to_vobh" failed: ClearCase object not found.
Updated: 09/10/12
Version: 7.0.1.8
This error occurred when attempting to check in a file version on the CLI using the -from option. This also applies to the CAL call $checkedout_o->Checkin("",1,"$source_file",1).
The -from argument cannot be a UNC path; it must be a local path.

Back to the INDEX.



System error: -2146697210
Updated: 09/24/12
Version: 7.1.2
This error occurred when attempting to import an xml file containing CC Explorer shortcut definitions.
The file was previously exported for definitions created inside the ClearCase Context Menu Editor. However, the file was manually edited in a text editor. Doing so changed the line terminations. To make changes to custom tool defintions, make the changes in the Menu Editor and then re-export the changes to save the file.
If you create an export .xml file and then make manual changes to the file, be careful what editor you use. Text editors, such as Notepad and Wordpad, will replace the line terminations and make the file unreadable by CC when it attempts to load the file at startup. You can use a program like Word, but it's difficult to manipulate custom XML tags outside of a template. The best option I've found is to use Notepad++, which is freeware.

Back to the INDEX.



cleartool: Error: Trouble removing versioned object base VOB-storage
Updated: 11/13/12
Version: 7.1.2
This error occurred when attempting to rmvob a VOB on Windows.
This can error can occur if you don't have permission to delete it. It can also occur if you have another program is open that is currently referencing it, such as ClearCase Explorer, Project Explorer, CLI, etc...

Back to the INDEX.



Win32::OLE(0.172) error 0x80020005: "Type mismatch" in METHOD/PROPERTYGET "ChangeSet" argument 1
Updated: 11/27/12
Version: 7.1.2
This error occurred when attempting to get the changeset of an activity using CAL.
The ChangeSet method requires a single argument that is the view that is needed to perform the version selection. Unfortunately, the documentation states "Name of a view to use to resolve ...", which implies the view tag name. However, what it really is looking for is the view object, as in $view_o = $CC->View(view-tag);

Back to the INDEX.



Word cannot start the converter mswrd632.wpc
Updated: 01/03/13
Version: 7.1.2
This error occurred when attempting compare a Word docx with its previous version on Windows XP with MS Office 2007.
When a document is newly opened using the new extended doc format (docx), Word attempts to run a conversion from the old format to the new. This isn't necessary every time a document is opened and is somehow colliding with the diff tool.
Delete the following registry key and try the diff again:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Text Converters\Import\MSWord6.wpc
However, if you then attempt to open a Word 6 or older document, that entry will need to be there.

Back to the INDEX.



ClearCase CM Server: Error: Unable to load "filename": Permission denied.
ClearCase CM Server: Error: Additional information may be available in the view log on host "CCRC-server".

Updated: 03/19/13
Version: 7.1.2
This error occurred when attempting to refresh a CCRC view that had previously been working.
The cause and solution are not known yet.

Back to the INDEX.



Unable to transfer a file: Permission denied.
Updated: 04/15/13
Version: 7.1.2
This error occurred when attempting to checkout a file.
The view being used is owned by a different user without sufficient permissions to for the current user to write to the view's storage area.
Either open up the permissions on the shared view, or create your own view.

It can also be caused by the needed domain group missing from CLEARCASE_PRIMARY_GROUP and CLEARCASE_GROUPS.

Back to the INDEX.



CRVAP0239E Error: CRVSV0078E Error from RPC server: CRVSV0841E 'Permission denied'
Updated: 06/07/13
Version: 7.1.2.4
This error occurred when attempting to access a VOB while editing a view's load rules in CCRC.
Ensure the domain group protecting the VOB is correctly specified in Window -> Preferences -> ClearCase Remote Client -> Groups. The domain group can be listed as the ClearCase Primary Group, or in Additional ClearCase Groups. In this case the domain group wasn't spelled correctly. Note also that under certain circumstances, instead of just specifying the group name itself, you may have to also specify the domain as well, as in "Global\mydomaingroup".

Back to the INDEX.



cleartool: Error: Failed to record hostname "hostname" in storage directory "local-path-to-storage-directory".
Check that root or the ClearCase administrators group has permission to write to this directory.
The host specified for your view storage directory (hostname) is not repsonding.

Updated: 05/05/16
Version: 7.1.2

These errors occurred when attempting to create a view.
Other users had previously been able to create views in the designated storage share.
The user was a visitor from a different site who brought their own laptop. The user's laptop CC was running using a different ALBD user as the view server. The "Atria Location Broker" service on the laptop must be running as the same user as any view or VOB servers that need to be accessed.
On Windows, the registry entry for ClearCaseGroupName must be updated too. See Change the "clearcase" group on Windows.

This error occurred when running "ct register" after copying a VOB storage area from a saved location back to it's original location.
Even though the permissions appeared to be correct on the storage area and .hostname file, the error still occurred.
The solution was to move .hostname to .hostname.bak and rerunning the register command again.

Another issue can be that the .identity sticky bits got reset during a VOB copy.
	chmod 4400 vob-storage/.identity/uid
	chmod 2410 vob-storage/.identity/gid
	chmod 2410 vob-storage/.identity/group.*
Also, even though it shouldn't be necessary, another solution might be to set the VOB storage parent folder "other" permissions to allow execute.
	chmod 755 vob-storage
In another case the storage location was on a NAS. When CC starts jobs on Unix, they are started as root. Therefore, root needs ro write to the NAS storage device on your behalf. Root write access can be granted on a server-by-server basis by the NAS admin.

Back to the INDEX.



cleartool: Error: There are no credentials registered for database db.
Updated: 07/09/13
Version: 7.1.2.4
This error occurred when attempting setactivity inside a scheduled job while the job's owner was logged out. This error was accompanied by a request for the user to run the crmregister command.
The crmregister command was known to be correct, as the scheduled job would run without errors while the user was logged in.
To ensure a scheduled job gets run with the correct privs while logged out, perform the following steps.

1) Open the Control Panel -> Administrative Tools -> Component Services.
2) Navigate to Component Services -> Computers -> My Computer.
3) Right-click to get the Properties and go to the "COM Security" tab.
4) Perform the following steps for both the "Access Permissions" and "Launch and Activation Permissions".
   a) Click on Edit Default.
   b) Click Add.
   c) Add the user that needs to run the scheduled job while logged out.
   d) Ensure Local Access and Remote Access are checked.
5) Close Component Services.

Back to the INDEX.



Unable to find replica in registry for VOB with object ID: "UUID".
Updated: 07/23/13
Version: 7.1.2.4
This error occurred when attempting create a view for a UCM stream.
The stream is created in the PVOB, the PVOB is synced with a remote site, but an associated component/VOB has not been replicated to that remote site yet.

Back to the INDEX.



Error 1058 - The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.
Updated: 08/29/13
Version: 7.1.2.4
This error occurred when attempting restart CC after a blue screen of death.
The IT admin determined that the ALBD service was the one causing the blue screen and disabled it.
A reinstall of CC fixed it.

Back to the INDEX.



Can't checkin a namespace directory from another source
Updated: 09/03/13
Version: 7.1.2.4
This error occurred when attempting create a new version of an element using a script.
The element was a folder and the script was attempting to use the -from option, which copies data from a source location and adds it to the destination version, which isn't applicable when working with folders.

Back to the INDEX.



cleartool: Error: IDispatch error #13530
Updated: 09/18/13
Version: 7.1.2.4
This error occurred when attempting to run a setactivity in a CQ multisited environment.
This is a CQ multisite error. See CRMMD1529E The AUX_SERIES of ids allocated to this database has been exhausted.
See also http://www-01.ibm.com/support/docview.wss?uid=swg21131174.

Back to the INDEX.



"element" is already checked out to view "viewtag" but that checkout was not specified as the "to" version.
Updated: 10/15/13
Version: 7.1.2.4
This error occurred when attempting a rebase of a development stream.
The element was checked out successfully by the rebase, but then complained that it couldn't check it out. Huh?

1) Stream "A" had added a derived object to source control and then delivered it to the integration stream.
2) A new recommended baseline was applied to the integration stream.
3) Stream "B" checked out the file and edited it. Editing a derived object turns the file into a regular element in that stream.
4) Stream "B" delivered the changed file to the integration stream and a new recommended baseline was applied.
5) When stream "A" tried to rebase against the new recommended baseline, the above error occurred.

It's not clear what the connection is between the system not recognizing its own checkout and the derived object status, but the result was a conflict of object type. In stream "A", the element was still recognized as a derived object, whereas the version being merged in was not, which caused a conflict.
The solution was to check out the element again in stream "A", check it back in as identical, which removed the "derived object" property from it.
The rebase was able to proceed normally after that.

Back to the INDEX.



CRVAP0087E CCRC command 'checkin' failed: Unable to copy "C:/temp/ccrctemp/cgi5" to ... Permission denied
Updated: 04/15/14
Version: 7.1.2.10
This error occurred when attempting a checkin in CCRC.
The element was checked out successfully, modified over a few days, but then gave a permission denied when attempting to check in.
The Connect to the CCRC was done using a different user than the checkout. Connecting with the "checkout" user solved the problem.

Back to the INDEX.



text_file_delta: Error: "file-path" is not a 'text file': it contains a line exceeding 8000 bytes.
Updated: 04/17/14
Version: 7.1.2.10

This error occurred when attempting a checkin.
The .js file was successfully added to source control empty, but then subsequent checkins failed because the file contained a single line with 40,000+ characters.
Unfortunately, the 8000 character per line limit is hard coded into the "text_file_delta" type manager. That limit was reportedly relaxed in VOB feature level 4 for the xml, html, and rose element types, but apparently not for the text_file type. You'll need to change the element type to something like "file" or "compressed_file".
See http://www-01.ibm.com/support/docview.wss?uid=swg21146197

WARNING: Unfortunately, you will then be unable to diff or merge the file, which implies not doing parallel development on the file.

	ct chtype -c "Changed to compressed_file due to rows containing more than 8000 chars." compressed_file filename
Back to the INDEX.


Error: "java.io.IOException: Unable to acquire lock to copy area registry. (Lock file is "path\.ccase_wvreg_lockfile".
Updated: 05/05/14
Version: 7.1.2.10

This error occurred when attempting to create a view in CCRC.
The system is indicating that it can't create a temporary lockfile. See http://www-01.ibm.com/support/docview.wss?uid=swg21381594.
However, there was no lockfile blocking the creation of a new lockfile. In this case, the user was attempting to create the view in a virtual desktop using VMWare. Other users were able create views using the same VMWare image. Updating the VMWare to the latest client version solved the problem. After the update, a lockfile was visible. Removing the offending lockfile solved the issue.

When the same error occurred again for another user, we were able to determine that the lock file does indeed exist. It could be seen by an administrator. The current user had absolutely no rights on the file, so could not see it. After the administrator changed the permissions, the user could see/remove the file. The user then manually removed the offending lock file and was able to continue.

Back to the INDEX.



An internal error occurred during: "Retrieve properties from server".
Multiple physical copy areas for the same logical copy area are not supported

Updated: 05/07/14
Version: 7.1.2.10

This error occurred when attempting to access a view in CCRC.
The error implies that the user has two view root folders (local download folders) that are using the same view tag. The view may have been deleted and recreated with the same tag, but the removal didn't delete the view root folder, perhaps because it had hijacked files in it. The one being accessed is not actually linked to the real one known by the server. "Logical" refers to information on the server (CC registry and/or session.dat) and "physical" refers to the view root folder(s) on the local computer. A given logical definition for a view can only have a single physical location.

In another instance of this error, the user had only the one view and the error only occurred on a single folder. Each folder in a snapshot view root directory tree has a file called ".copyarea.db" that contains the information CC needs to update the folder. That file had become corrupt for an unknown reason. That file doesn't contain any view-specific information, so copying the file for the same folder from a good view solved the problem.

Back to the INDEX.



Ccrc. An error has occurred. See the log file ccrc-home\digits.log.
java.lang.IllegalStateException: The platform metadata area could not be written: user-home\.Rational\CCRC71\workspace\.metadata.

Updated: 05/14/14
Version: 7.1.2

The first error occurred as a pop up when attempting to start CCRC. The second error was inside the log file.
Technote http://www-01.ibm.com/support/docview.wss?uid=swg21285232 indicates a problem with the .Rational folder. Delete that folder from your user-home and restart CCRC.
In this particular case, the user did not see a .Rational folder there. But, an administrator could. For an unknown reason, the permissions on that folder were corrupted such that the user could not even see the folder, even after selecting to view hidden files and folders. For the same reason, CCRC could not write to it, hence the error. The issue was resolved after the system administrator reset the permissions on the .Rational folder.

Back to the INDEX.



The operation cannot proceed because the copy area is locked by another processs.
Updated: 06/24/14
Version: 7.1.2

This error occurred when attempting to access a CCRC view after connecting to the server.
The error message will tell you where the view root folder is. Remove the "copyarea.lck" file there and restart CCRC.
The error is often accompanied by the question "Would you like to break the lock ...?" Answering "Yes" will remove that lock file for you.

Back to the INDEX.



Cannot-create-at-this-location.
Updated: 08/04/14
Version: 7.1.2

This error occurred when attempting to create a CCRC view.
The reason for the error is unknown. Several users experienced it one morning. However, without modifying anything the error went away. Must have been some temporary glitch.

Back to the INDEX.



vob_scrubber: Error: db_VISTA error -925 (errno == "Too many open files")
Updated: 03/30/15
Version: 8.0.1

This error appeared in the output of the CC schedule "Weekly VOB Database Scrubbing" job.
The cause and solution are not yet known.

Back to the INDEX.



multitool: Error: Must specify VOB storage directory pathname or Server Storage Location name.
Updated: 09/29/15
Version: 8.0.1

This error occurred when attempting to import a replica.
This is a misleading error. The real reason was the import replica name was not the last argument on the CLI.

Back to the INDEX.



rm: Unable to remove directory storage-area: File exists
Updated: 12/01/15
Version: 7.1.2.14

This error occurred when attempting to completely remove a Unix VOB storage area across NFS.
See Remove a Unix VOB/view storage area across NFS.

Back to the INDEX.



Invalid filename
Updated: 03/31/16
Version: 7.1.2.14

This error occurred when attempting to Send To -> Documents from within a Windows Version Tree Browser.
The problem was that the path was too long. Unfortunately, as of 7.1.2, ClearCase still can't handle long path names in Windows in all interfaces.
In this case, it was possible to open the file in the Windows Explorer and ClearCase Explorer. But, what if the user wants to view a previous version of the same file? If so, see: View the contents of an older version of a file.

Back to the INDEX.



Not all of the ClearCase services started.
Error 1068: The dependency service or group failed to start.

Updated: 05/05/16
Version: 7.1.2.14

These errors occurred after a new install of CC on a new Windows Server 2008 computer.
There were two problems:
1) The ALBD service account had not been given local login rights on the server.
2) The ALBD and Credentials Manager services depend on a service called "Computer Browser". At our company, that dependent service was specifically disabled by a network policy. A special request had to be made to get an exception to have that service's startup type be set to "Automatic".

See also: http://www-01.ibm.com/support/docview.wss?uid=swg21177467

Back to the INDEX.


ejostrander@cox.net
Return to the home page .

This page last modified: 05/05/2016