我遇到了一个问题（在我使用的系统上）不是如果我以 root 身份访问某个目录，并且该目录使用 acl 来管理访问，那么我应该被允许访问（如果我newgrp对我所属的 17 个组中的一个执行 a 操作，我就被允许访问），但除此之外，我无法“遍历”该目录（本质上是r-x权限）。
我相信这是 Unix nfs 问题的“16 组限制”，并且设置rpc.mountd要使用的命令基本上--manage-gids可以解决该问题，并且如果文件的 [exportd] 和 [mountd] 部分中的条目正确，则可以修复此问题/etc/nfs.conf：
# manage-gids=n
更改为：
manage-gids=32
允许 32 gid 作为新的组 ID 限制。具体来说，在导出机器上，在 [exports] 部分，在客户端机器上，在 [mountd] 部分。
我这个“修复”是否正确？系统正在运行 nfs4，并且内核足够新，可以执行此操作。这似乎是修复方法，但我无法找到文件中这些参数的确切含义/etc/nfs.conf。
争论--manage-gids似乎rpc.mountd是一个打开或关闭的事情，但manage-gids=n似乎可能是允许的团体数量？
我已经在谷歌上搜索过，发现 NFS 上的 16 组限制，这似乎是可以修复的地方，但我没有看到有关该参数将如何获得将参数添加到 的效果的更多信息-g。rpc.mountd我已经下载并仔细阅读了 RFC 7530 和 8881，但这些更多的是协议规范（AFAICT），而不是如何在 Linux 下实现。
答案1
我的这个“修复”正确吗？
不完全是。它真的只是一个是/否参数。
16 组限制不能仅在服务器端提高，因为它本来就不是服务器端限制（即使 rpc.mountd 是服务器端组件）；它是一个协议级别的限制，会导致客户端不发送首先添加组。（这是身份验证系统SunRPC 层的身份验证风格，而不是 NFS 专门定义的东西。
相反，启用的效果manage-gids是服务器将忽略所有客户端发送的组，并将对用户的组成员身份进行独立检查，直接查询 /etc/group 或 LDAP 并将其存储为 NFS“会话”的一部分。（这是 rpc.mountd 必须支持的功能，无论 RPCSEC_GSS 或 AUTH_DH 是否完全不包含组信息。）