我有一个用户（只有一个，其他都很好）试图更新他们的 ClearCase 视图。
直到今天，它在过去 6 个月里一直为他们工作。
当他们更新时，他们得到：
Unable to read directory "." Permission denied
Errors were encountered in loading "\VOB"
我做了一个“ gpresult”，似乎他们在正确的组中，并且没有为他锁定流。
CC Doctor 也没有出现任何错误。
自从他上周五使用 CC 以来，没有任何变化。
还有其他我应该看的地方吗？
我没有想法，我相信我已经到了谷歌搜索的尽头......
通常要检查的元素是：
CLEARCASE_PRIMARY_GROUPcleartool lsview -l -full -pro viewTag
由于用户没有进行任何更改，因此可以将其链接到 Windows 配置文件问题。确保重新启动后问题仍然存在。
还要确保没有 Windows 组策略更改或登录权限演变（如撤销管理员权限），这可以解释为什么用户无法读取 ClearCase 快照视图的根目录。这可能是 Windows ACL 问题（即与 ClearCase 没有直接关系。
CLEARCASE_PRIMARY_GROUPOP 报告说，ClearCase 不再考虑引用的组，因为该组不在用户注册的前 32 个 Windows 组中。
技术说明“关于 CLEARCASE_GROUPS 变量”详细说明了正确的解决方法：
此变量用于抵消 ClearCase 使用的SUNRPC 协议中的限制，即任何属于超过 32 个 Microsoft Windows 组（域或本地）的成员的用户都可能遇到访问问题。
如果存在任何用户的用户环境变量
CLEARCASE_GROUPS，ClearCase 将在确定（或显示）用户所属的组时首先考虑在该变量的值中指定的以分号分隔的组列表。实质上，当您登录 Windows 时，您会收到一个Access Token。
ClearCase 将按照 Windows 提供它们的顺序处理这些令牌（这是完全随机的，不能以任何方式配置）。
ClearCase 将在达到 32 个组后停止处理令牌。该
CLEARCASE_GROUPS变量是解决此问题的唯一方法。
设置变量后，ClearCase 将CLEARCASE_GROUPS按照列表的写入顺序查看列表中的每个组名，并将其与提供的 Windows 访问令牌进行比较。
如果组名与 Windows 访问令牌中的组匹配，那么 ClearCase 将创建一个 ClearCase 访问令牌供该组使用。当 CLEARCASE_GROUPS 变量用完后，ClearCase 将返回 Windows Access Token 列表，任何尚未添加到 ClearCase 令牌中的组将从剩余列表中按提供的顺序添加，直到 Windows 中的所有组使用令牌（如果低于 32）或达到 32 组限制。
