Question

I have one user (only one, all the others are fine) trying to update their ClearCase view.
It has worked for them for the last 6 months up until today.

When they update, they get:

Unable to read directory "."  Permission denied

Errors were encountered in loading "\VOB"

I did a “gpresult” and it seems like they are in the correct groups and the stream is not locked for him.
CC Doctor isn’t coming up with any errors either.
Nothing has been known to change since he last used CC on Friday.

Are there any other places that I should look?
I’m out of ideas and I believe I have reached the end of my google search…

Answer 1

The usual elements to check are:

• the environment variable CLEARCASE_PRIMARY_GROUP
• the characteristics of the view:

cleartool lsview -l -full -pro viewTag 

Since the user hasn’t made any changes, it can be linked to a Windows profile issue. Make sure that the issue persists after a reboot.

Also make sure there isn’t a Windows group policy change or login privilege evolution (like an admin right revoked) which could explain why the user isn’t able to read the root directory of the ClearCase snapshot view. It could be a Windows ACL issue (ie not directly related to ClearCase.

---

The OP reports that the group referenced by CLEARCASE_PRIMARY_GROUP wasn’t taken into account anymore by ClearCase, because that group wasn’t in the first 32 Windows groups the user was registered to.

The technote “About the CLEARCASE_GROUPS variable” details the right workaround:

This variable is used to counteract a limitation in the SUNRPC protocol that is used by ClearCase whereby any user who is a member of more than 32 Microsoft Windows groups (domain or local) can run into access problems.

If the user environment variable CLEARCASE_GROUPS exists for any user, ClearCase will consider the semicolon-separated list of groups specified in the value of this variable first when determining (or displaying) which groups a user belongs.

In essence, when you log in to Windows, you receive an Access Token.
ClearCase will process these tokens in the order Windows provides them (which is completely random and cannot be configured in any way).
ClearCase will stop processing the tokens after 32 groups have been reached.

The CLEARCASE_GROUPS variable is the only way to work around this behavior.
When the variable is set, ClearCase will look at each group name in CLEARCASE_GROUPS list in the order the list was written and compare that to the Windows Access Tokens provided.
If the group name matches a group in the Windows Access Token, then ClearCase will create a ClearCase Access Token for that group to use.

When the CLEARCASE_GROUPS variable is exhausted, ClearCase will go back to the Windows Access Token list, and any group that has not already been added to the ClearCase token, will be added from the remaining list in the order provided, until all groups in the Windows token are used (if below 32) or the 32 group limit is reached.