What is the meaning of the manage-gids parameter in /etc/nfs.conf?

Question

I have run into an issue (on a system which I am not root) where there is a directory using an acl to manage access, I should be allowed access (and I am allowed access if I do a newgrp to one of the 17 groups I am a member of) but otherwise I can not "traverse" that directory (essentially r-x permissions).

I believe this is the "16 group limit" of Unix issue with nfs, and that setting essentially the rpc.mountd command to use --manage-gids will fix the issue, and that this would be fixed if the entries in both the [exportd] and [mountd] sections of the /etc/nfs.conf file:

# manage-gids=n

Were changed to:

manage-gids=32

To allow the 32 gid to be the new group id limit. Specifically, on the exporting machine, in the [exports] section, and on the client machines in the [mountd] section.

Do I have this "fix" correct? The system is running nfs4, and has a kernel more than recent enough to do this. This seems like it would be the fix, but I am having issues finding what exactly these parameters in the /etc/nfs.conf file mean.

The --manage-gids argument to rpc.mountd seems like an on or off affair, but the manage-gids=n seems like it might be the number of groups that would be allowed?

I've done google searches, found the 16 group limit on NFS, and this does seem like the place where it would be fixed, but I'm not seeing more information on what that parameter would be to get the effect of adding the -g argument to rpc.mountd. I've downloaded and perused RFC 7530 and 8881, but these are more the protocol spec (AFAICT) and not how this is implemented under Linux.

Answer 1

Do I have this "fix" correct?

Not quite. It really is just a yes/no parameter.

The 16-group limit cannot be just raised server-side as it's not a server-side limit to begin with (even though rpc.mountd is a server-side component); it's a protocol-level limit that causes the client to not send the additional groups in the first place. (This is a limitation of the AUTH_SYS authentication flavor at the SunRPC layer and not something that NFS defines specifically.)

Instead, the effect of enabling manage-gids is that the server would ignore all client-sent groups and would make an independent check of the user's group memberships, directly querying /etc/group or LDAP and storing that as part of the NFS "session". (This is something that rpc.mountd would have to support regardless for RPCSEC_GSS or AUTH_DH, which don't carry group information at all.)