NFS Permission Denied when over 16 groups are assigned

When trying to edit/copy/move a file on a mounted NFS share, that has proper group permissions, an error is displayed with "permission denied". Example below:

# cp /nfs/testfile /new/location/
cp: cannot open 'testfile' for reading: Permission denied

# whoami
testuser

# ls -alh /nfs/testfile
-rw-r--r-- 1 root test18 0 Jun  5 08:02 /nfs/testfile

# ls -alh /new/
…
drwxr-xr-x 1 root test18  0 Jun  5 08:04 location

# id -Gn testuser
users test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 test11 test12 test13 test14 test15 test16 test17 test18

On the NFS Server machine, use a MOUNTD_OPTIONS value that ignores the gids passed within the NFS packets from the client and instead does looks up the users' gids directly.  Setting this option is done in the /etc/sysconfig/nfs file on the NFS server, the setting below is added and a restart of the nfsserver service on the server is needed as well.

MOUNTD_OPTIONS="--manage-gids"

The RPC layer and the auth-sys method (which most NFS setups rely on, unless kerberos is being used) can only include up to 16 GIDs in requests sent from the NFS client to the NFS server.  If more than that exist, they are left out of the requests, and therefore the NFS Server might deny access which is otherwise expected.

The MOUNTD_OPTIONS="--manage-gids" setting tells the NFS Server not to use the list of GIDs that came within the client's request.  Instead, the NFS Server should do its own identity lookups for groups the UID belongs so.  The list found by the NFS Server doesn't have to be processed within RPC / auth-sys limitations, so it can have more than 16 GIDs and proper permissions can be granted.

The only caveat is if the client hosts believes that (for example) UID 1234 has a certain list of GID memberships, but the NFS server host doesn't know who UID 1234 is, or doesn't have the same list of GID memberships that the client does.  Then the expected permissions may still not be granted. It is best if both sides are using a common centralized identity repository, so both sides will always know the same UIDs and same lists of GIDs.