ClearCase棘手错误解决方案

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.

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 If you just want to change permissions on an element, see

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

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.

Unable to access \\server\path\vob.vbs; Invalid argument.

The NFS Maestro package has a bug in it that prevents CC on NT 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 NT side. On the NT 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 the NT.

  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.

Unable to unmount: Resource device (Device busy)
umount: vob-tag busy

The first error occurs on NT 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.

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.

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

Unable to access \\server\path\vob.vbs; Error 26

This error is generated when attempting to mount a UNIX VOB from Windows NT. 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 NT attempting to mount it.

 

Could not connect [X:] to [\\server\path\vob.vbs] - error 5

This error shows up when trying to mount a VOB from a Windows NT 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.

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 NT 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 the NT. A good check for this is to access the server's drive via NT Explorer "map network drive" (independent of CC).

2) The VOB has group permissions other than your PRIMARY_CLEARCASE_GROUP. On NT, run atria-home/etc/utils/credmap.

3) The view has group permissions other than your PRIMARY_CLEARCASE_GROUP. On NT, run atria-home/etc/utils/credmap.

NOTE: Credmap will not pass if the usernames on the NT 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.

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 . 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 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 (or download it directly from ).

#!/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

Cannot run regedit

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

 

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".

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 NT 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 :-(.

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/".

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

This error shows up on an NT 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 NT password for clearcase_albd. The clearcase_albd password is registered in two places, on the NT 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.

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 ...

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 .

The path \DEVICE\...\...\.s\filename does not exist.

This error is associated with trying to remove or overwrite a view-private file via an NT 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 an NT. If the view is common to both UNIX and the NT 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 the NT, 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.

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 NT.

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.

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

Can't get primary GID

This error shows up when running creds or credmap on an NT 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 NT client. The only downside to local groups is that they are difficult to administer en masse in the future.

Attempt to get location information failed: Invalid argument.

This error can occur when attempting to do commands such as mktag from an NT 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

clearimport: Error: Permission denied. Not VOB owner.

This error showed up when attempting a clearimport as a regular user on an NT client connected to a UNIX server. All the permissions and connections were in place to allow the NT 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.

Type manager "..." failed construct_version operation.

This error showed up when doing an update view for snapshot view on an NT. For some reason the view_server.exe process had gotten confused and a reboot solved the problem. This was also coupled with permission denied errors where there were none previously.

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.

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.

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.

ClearCase Dynamic Views: The device is not currently connected, but is a remembered connection.

This error occurs when an NT 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 error message when doing a "ct ls" of that directory from the command-line.

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.

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.

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.

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?

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.

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

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 NT 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 "" for the fix_prot commands.

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 "" 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.

cleartool: Warning: Unable to move private data from "..." (No such file or directory). (NT 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 NT 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.