NFS Directory Group permissions not working

Question

For some reason the users that are part of a particular group (with that group have rwx on an NFS directory) cannot cd in to that directory. I am at a loss here, there has to be something I am missing. Both client and server are Debian 11 servers

On the NFS client here is the user/group info:

root@client:/# ls -lisa /media/
total 17
 4 drwxr-xr-x  5 root  root  4096 Apr 15 14:33 .
 4 drwxr-xr-x 17 root  root  4096 Aug 16 05:14 ..
 4 drwxrwx---  5 media media 4096 Sep  2 20:41 Download

root@client:/# ls -lisa /media/Download/
total 36
       2  4 drwxrwx--- 6 media media  4096 Sep  3 09:05 .
  783361  4 drwxr-xr-x 5 root  root   4096 Sep  3 09:04 ..
      11 16 drwxrwx--- 2 media media 16384 Apr 11 17:55 lost+found
11272193  4 drwxr-xr-x 2 media media  4096 Sep  3 09:05 testdir
      12  0 -rw-r--r-- 1 media media     0 Sep  3 09:04 test.txt

root@client:/# id media
uid=1090(media) gid=1090(media) groups=1090(media)

root@client:/# id user
uid=1000(user) gid=1000(user) groups=1000(user),1090(media)

root@client:/# cat /etc/passwd | egrep "user|media"
user:x:1000:1000:user,,,:/home/user:/bin/bash
media:x:1090:1090::/home/media:/usr/sbin/nologin

root@client:/# mount
192.168.24.10:/media/Download on /media/Download type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.24.5,local_lock=none,addr=192.168.24.100)

user@client:~$ whoami | id
uid=1000(user) gid=1000(user) groups=1000(user),1090(media)

user@client:~$ ls -lisa /media/Download/
ls: cannot open directory '/media/Download/': Permission denied

Why is user denied from accessing the Download folder? They are part of the group media and the folder has rwx for the group. What is the problem here?

On the NFS server:

root@server:/# ls -lisa /media/
total 16
128771 4 drwxr-xr-x  4 root  root  4096 Apr 15 04:32 .
     2 4 drwxr-xr-x 18 root  root  4096 Aug 16 08:12 ..
     2 4 drwxrwx---  6 media media 4096 Sep  3 08:05 Download

root@server:/# ls -lisa /media/Download/
total 36
       2  4 drwxrwx--- 6 media media  4096 Sep  3 08:05 .
  128771  4 drwxr-xr-x 4 root  root   4096 Apr 15 04:32 ..
      11 16 drwxrwx--- 2 media media 16384 Apr 11 16:55 lost+found
11272193  4 drwxr-xr-x 2 media media  4096 Sep  3 08:05 testdir
      12  0 -rw-r--r-- 1 media media     0 Sep  3 08:04 test.txt

root@server:/# id media
uid=1090(media) gid=1090(media) groups=1090(media)

root@server:/# cat /etc/exports
/media/Download 192.168.24.5/32(rw,anonuid=1090,anongid=1090,no_subtree_check,root_squash)

root@server:/# cat /etc/passwd | grep media
media:x:1090:1090::/home/media:/usr/sbin/nologin

If I change the NFS server directory permissions to 777 then I can read and write into Download from the client. But obviously I rather be more restrictive and only let the allowed user read/write in that directory.

I have rebooted both the client and server several times, but the same permission denied occurs.

Answer 1

The user on the server is not part of the media group though.

It really should be. (Ideally, both the client and server should automatically know all UIDs and groups from LDAP or NIS or similar system.)

While NFS supports sending the client user's auxiliary groups in RPC requests, this has a maximum of 16 groups (keep in mind that the credentials are included in every single RPC request so each additional GID is network overhead).

Because of this limit, the NFS server is often set up to ignore the client-supplied auxiliary GIDs completely and to do a fresh server-side lookup instead. On Linux this is enabled when the server's rpc.mountd is started with the -g/--manage-gids option (which you can find in /etc/default/nfs-kernel-server on Debian) or when manage-gids is enabled in /etc/nfs.conf (which exists on newer nfs-utils).

Making sure "manage-gids" is disabled on the server may help (needs a systemctl daemon-reload on Debian, but may need a full reboot to make the kernel stop performing lookups), but ideally the group membership should be consistent between the server and all clients – server-side group lookup becomes mandatory if you ever switch your NFS setup to Kerberos authentication.

Shouldn't the exports on the server for anonuid and anongid squash the use of local users on the server?

Not unless you use all_squash. These parameters are only used as the UID/GID of requests that already would've been mapped to the "nobody" user (e.g. root with "root_squash").