How do I set up NFS to respect user and group permissions?
Everything looks as expected. Since /data
is rwx--x--x
, only the owner, u1
, can list it. Others can access files and subdirectories in it, subject to permissions on those files and subdirectories.
In addition, userid 0 on NFS clients is mapped to userid 65534 (on some systems, -2) on servers unless you have no_root_squash in the export line (or, if running NFSv4, do explicit userid mapping on the server). Here are some details from the exports(5) man page:
Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anonymous or nobody uid. This mode of operation (called `root squashing') is the default, and can be turned off with no_root_squash.
By default, exportfs chooses a uid and gid of 65534 for squashed access. These values can also be overridden by the anonuid and anongid options.
mrP
Updated on September 18, 2022Comments
-
mrP over 1 year
After creating an NFS share between two servers, lb1 (nfs-client) and data-server1 (nfs-kernel-server), users with permission on the NFS server do not have access on the NFS client.
data-server1 configuration:
$ cat /etc/exports /data 10.132.246.167(rw,no_subtree_check) $ ls -la / | grep data drwx--x--x 3 u1 users 4.0K Sep 6 03:55 data/ $ ls -la /data drwxr-xr-x 3 u1 users 4.0K Sep 6 02:31 prod/ drwxrwsr-x 2 www-data www-data 4.0K Sep 6 02:31 keys/ $ awk -F: '$0=$1 " uid="$3 " gid="$4' /etc/passwd | grep 'root\|u1\|ftp\|www-data' root uid=0 gid=0 www-data uid=33 gid=33 u1 uid=115 gid=100 ftp uid=999 gid=100
lb1 configuration:
$ mount 10.132.245.223:/data /data $ mount 10.132.245.223:/data on /data type nfs4 (rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.132.246.167,minorversion=0,local_lock=none,addr=10.132.245.223) $ sudo -u u1 ls -la / | grep data drwx--x--x 3 u1 users 4.0K Sep 6 03:55 data/ $ sudo -u u1 ls -la /data drwxr-xr-x 3 u1 users 4.0K Sep 6 02:31 prod/ drwxrwsr-x 2 www-data www-data 4.0K Sep 6 02:31 keys/ $ awk -F: '$0=$1 " uid="$3 " gid="$4' /etc/passwd | grep 'root\|u1\|ftp\|www-data' root uid=0 gid=0 www-data uid=33 gid=33 u1 uid=115 gid=100 ftp uid=999 gid=100
On the NFS server (ie, data-server1), root, u1, and ftp users have proper rwx permissions for the subdirectories of /data and can access the filesystem without any problems. However, on the NFS client (ie, lb1), root and ftp get
permission denied
errors when trying to simply list directory contents of/data
within the NFS share. User u1 on the other hand, works perfect.This is one of my first usages of NFS
-
Mark Plotnick over 9 yearsIf a directory is
rwx--x--x
, only the owner can list it. Others can access files and subdirectories in it, subject to permissions on those files and subdirectories. In addition, user 0 on nfs clients is mapped to user 65534 on servers unless you have no_root_squash in the export line or do explicit userid mapping on the server. What kind of access do you want the users to have? -
Mark Plotnick over 9 yearsI should add that the reason no_root_squash isn't there by default is that historically, nfs clients were less trustworthy than the nfs server, with many clients sharing one server, and it's not good when a root user on the client accidentally does
rm -r
and cleans out the filesystem on the server. -
mrP over 9 years@MarkPlotnick Thanks for the comments. I guess I was expecting the directory on the client to behave like it does on the server since all UID/GID match, but I can see now that the
root
differences were throwing me off and that it works as expected. Add your comments as an answer and I'll happily accept it.
-
-
sneaky about 5 yearsIs this a security issue on a productive system?
-
Mark Plotnick about 5 years@sneaky Can you please clarify? I'm not sure what you mean by "this".
-
sneaky about 5 yearsOK, sorry, to clarify: Is it a good idea to use "no_root_squash" on a productive system exposed to the internet?
-
Mark Plotnick about 5 years@sneaky I don't think it's a good idea to have no_root_squash unless you trust the root users on all of the server's NFS clients. And even with root_squash, the root users on NFSv2 and NFSv3 clients can still use
su
to become any other user and then have access to that user's files on the server. If it fits your use case, I'd suggest running NFSv4 with Kerberos, which supports per-user authentication and encryption of data as it passes through the network.