IBM Support

Problems that occur if the ClearCase Administrator group owns the VOB or VOB objects

Preventive Service Planning


This technote provides you with information about IBM® Rational® ClearCase® and discusses the problems that arise when the ClearCase Administrators group owns the VOB or VOB data (elements, metadata) on Microsoft® Windows®.



When a VOB or objects contained within a VOB (elements and metadata) are owned by the ClearCase Administrators group, this will most certainly result in permissions errors whenever an operation is performed against that object by a non-Admin user.

Since the administrators group by default has access to all ClearCase objects, it is not necessary to explicitly add that group and should be avoided.

If as an Administrator you need to ensure that you authenticate as a ClearCase administrator, you can set the CLEARCASE_GROUPS variable to include the ClearCase Administrators group and set the CLEARCASE_PRIMARY_GROUP to the ClearCase users group.

Do not add all users to the privileged group in an attempt to provide them access to the misprotected objects as this will pose a security risk since all those users would then be considered ClearCase admins. Instead you should reprotect the objects to the proper group (preferably a ClearCase users group) which the users are all a member of and which is a group that owns the VOB and all VOB objects.

Review the ClearCase Command Reference Guide on the topic of permissions (cleartool man permissions) for more information.


So, how does the administrators group get mistakenly assigned to a VOB or VOB object (or even a view)?

ClearCase objects subsequently created by the above users will by default be owned by that primary group.


From either of the command outputs below we can see that the users primary group is set to the ClearCase Administrators group "MYDOMAIN\CLEARCASE"

C:\Documents and Settings\joe>set

C:\Program Files\Rational\ClearCase\etc\utils>creds
Login name:    MYDOMAIN\joe
USID:          NT:S-1-5-21-141845252-1443263951-584457872-1606
Primary group: MYDOMAIN\
clearcase (NT:S-1-5-21-141845252-1443263951-584457872-1022)
Groups: (8)
   MYDOMAIN\user (NT:S-1-5-21-141845252-1443263951-584457872-1023)
   Everyone (NT:S-1-1-0)
   BUILTIN\Administrators (NT:S-1-5-32-544)
   BUILTIN\Users (NT:S-1-5-32-545)
   NT AUTHORITY\Authenticated Users (NT:S-1-5-11)
   LOCAL (NT:S-1-2-0)
   MYDOMAIN\Domain Users

You have ClearCase administrative privileges.


  • Elements & Metadata:

In the case of VOB objects such as elements and metadata which are owned by only one group, setting that group to the administrators group will block any normal user from performing certain ClearCase operations against that object. This will occur through a number of ClearCase operations that validate the group to determine access.


The following element is owned by the ClearCase administrators group:

M:\def\new-vob>cleartool describe -l ccgroup.txt
version "ccgroup.txt@@\main\1"
 created 2007-07-09T16:18:04-04 by Joe Mac (joe.clearcase@myhost)
 Element Protection:
   User : MYDOMAIN\joe : r--
   Group: MYDOMAIN\
clearcase : r--
   Other:          : r--
 element type: text_file
version: \main\0

The following error will be reported when trying to checkout the above element while logged in as a user who is not a ClearCase administrator and doesn't own the element:

cleartool checkout -nc ccgroup.txt
cleartool: Error: No permission to perform operation "checkout".
cleartool: Error: Must be one of: member of element group, element owner, VOB owner, member of ClearCase group
cleartool: Error: Unable to check out "ccgroup.txt".

Review the Restrictions information in the ClearCase Command Reference Guide under the topic of checkout (cleartool man checkout) for more information.

  • VOB object:

    The following is the output from a describe of a VOB created by the above referenced user where this VOB is now owned by the ClearCase Administrators group. Any user who is not a member of the ClearCase Administrators group will get permissions errors trying to add ClearCase data to this VOB.

    C:\Documents and Settings\joe>cleartool describe -l vob:\new-vob
versioned object base "\new-vob"
  created 2007-07-06T18:46:48-04 by Joe Mac (joe.clearcase@myhost)
  VOB family feature level: 5
  VOB storage host:pathname "myhost:D:\clearcase_storage\vobs\new-vob.vbs"
  VOB storage global pathname "D:\clearcase_storage\vobs\new-vob.vbs"
  database schema version: 54
  modification by remote privileged user: allowed
  VOB ownership:
    owner MYDOMAIN\joe
    group MYDOMAIN\clearcase
    FeatureLevel = 5

Trying to add the ClearCase administrators group to the VOB's group list is not allowed and will report the following error:

C:\Documents and Settings\joe>cleartool protectvob -add_group clearcase \\myhost\clearcase_storage\vobs\june2007.vbs

This command affects the protection on your versioned object base.
While this command is running, access to the VOB will be limited.
Pool "sdft" appears to be protected correctly.
Pool "ddft" appears to be protected correctly.
Pool "cdft" appears to be protected correctly.
Protect versioned object base "\\myhost\clearcase_storage\vobs\june2007.vbs"?  [no] y
Do you wish to protect the pools that appear not to need protection?  [no] y
cleartool: Error: Trouble protecting versioned object base "\\myhost\clearcase_storage\vobs\june2007.vbs".

  • View:

    The following is the output of a cleartool lsview command which displays the view properties. Since this view is owned by the administrators group, non-privileged users will be unable to perform a checkout operation in that view because they (defaulting to the "Other" credentials) don't have write permissions to the view.

    M:\def\new-vob>cleartool lsview -properties new-view
    * new-view             \\myhost\clearcase_storage\views\new-view.vws
    Created 2007-07-06T18:49:20-04 by MYDOMAIN\joe.MYDOMAIN\clearcase@myhost
    Last modified 2007-07-06T18:49:20-04 by
    Last accessed 2007-07-06T18:49:20-04 by MYDOMAIN\joe.MYDOMAIN\clearcase@myhost
    Owner: MYDOMAIN\joe  : rwx (all)
    Group: MYDOMAIN\
    clearcase : rwx (all)
    Other:                  : r-x (read)

  • Interop:

    The ClearCase administrators group maps over to UNIX as nobody (as of ClearCase 4.1) by design to avoid security issues, thus, setting a users primary group to the administrators group will always authenticate over to UNIX as group nobody causing permissions errors.

    Review the ClearCase Command Reference Guide on the topic of credmap (cleartool man credmap) for more information.

  • MultiSite:

    Objects that are owned by the ClearCase Administrators group may cause import or export errors like the following.

    multitool: Error: Unable to create a container in vob "\idunn", because group "SERVER2\clearcase" not in vob's group list.


Refer to technotes 1146535 and 1146517 for instructions for reprotecting the data.

Note: The vob_sidwalk cannot be used to change the group on VOB objects that are incorrectly set to the ClearCase Administrators group.
  • For a View:

    The group of a view on Windows cannot be changed. Views must be recreated.


Internal Use Only

A Japanese technote 1459547 Database 'DCF Technotes (Rational)', View 'Products', Document 'ClearCase 管理者グループが VOB や VOB オブジェクトを所有したときに発生する問題' exists, which is a translation of this English document.

IMPORTANT: If this technote is modified with significant changes, the changes need to also be applied to the Japanese through an update request. Spelling and grammatical changes are likely not significant
to the translated content. If multiple translated versions exist, this process must be repeated for them as well.

There may be situations where shared views that are owned by the admin group will prevent access. Once the non owner tries to access view they receive unable to access errors.

[{"Product":{"code":"SSSH27","label":"Rational ClearCase"},"Business Unit":{"code":"BU004","label":"Hybrid Cloud"},"Component":"VOB","Platform":[{"code":"PF033","label":"Windows"}],"Version":"7.0;7.0.1;7.1;7.1.1;7.1.2;8.0;8.0.1","Edition":""}]

Document Information

Modified date:
16 June 2018