How do I set up NFS to respect user and group permissions?

7,530

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.

Share:
7,530
mrP
Author by

mrP

Updated on September 18, 2022

Comments

  • mrP
    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
      Mark Plotnick over 9 years
      If 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
      Mark Plotnick over 9 years
      I 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
      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
    sneaky about 5 years
    Is this a security issue on a productive system?
  • Mark Plotnick
    Mark Plotnick about 5 years
    @sneaky Can you please clarify? I'm not sure what you mean by "this".
  • sneaky
    sneaky about 5 years
    OK, sorry, to clarify: Is it a good idea to use "no_root_squash" on a productive system exposed to the internet?
  • Mark Plotnick
    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.