Solving NFSv4 AUTH_SYS nobody ownership issue

For files/directories under NFSv4 AUTH_SYS mount, if the ownership is shown as nobody, then check NFSv4 ID Mapping settings. You need to ensure that NFsv4 ID Mapping Domain (e.g. Domain attribute in /etc/idmapd.conf on RHEL7.x) is same across NFS server and NFS client.

To illustrate it, examples are provided below for list operation (“ls” command) and file create operation (“echo xyz > file” command) with RHEL7.2 NFS client.

Example 1: details about nobody ownership issue shown under nfsv4 sys mount.
Example 2: shows how to solve the issue presented in Example 1.

(Examples talk about NFSv4 ID Map domain. This is not necessarily your host domain name but can be anything and you can set it explicitly by editing Domain attribute in /etc/idmapd.conf file on RHEL machine. The configuration file and the option would change as per the NFS client OS.)

NFS server and NFS client Setup for Example 1 and Example 2:

1. To explain nobody ownership issue, we need a user account that resolves on both NFS client and NFS server. You can do this by various ways e.g. create local users on NFS client and NFS server or configure NFS client and NFS server against common authentication source (e.g. Active Directory, LDAP).

For time being, I’ve configured NFS server and NFS client against common authentication source (Active directory here) and AD user GANESHA\aduser1 resolves successfully returning uid:gid (15001:10001) on NFS server and NFS client .

# server
# id GANESHA\aduser1
uid=15001(GANESHA\aduser1) gid=10001(GANESHA\ganeshagr1) groups=10001(GANESHA\ganeshagr1),20000(GANESHA\group20k)…

# client
$ id GANESHA\aduser1
uid=15001(GANESHA\aduser1) gid=10001(GANESHA\ganeshagr1) groups=10001(GANESHA\ganeshagr1),20000(GANESHA\group20k)…

2. Create a file on server owned by user GANESHA\aduser1.

# create file on server and set ownership to GANESHA\aduser1

# echo ganesha > /myfs/export1/file1
# chown 15001:10001 /myfs/export1/file1
# ls -ltr /myfs/export1
total 1
-rw-r--r-- 1 GANESHA\aduser1 GANESHA\ganeshagr1 8 Jul 28 20:49 file1

3. Client mounts nfs export (/myfs/export1) using nfsv4 mount option.

# client nfsv4 mount done

192.168.122.199:/myfs/export1 /mnt/4s nfs4 rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.246,local_lock=none,addr=192.168.122.199 0 0

Example 1: NFSv4 ID Map Domain mismatch

1. NFSv4 ID map Domain setting on server and client are different e.g. test.com on server whereas dummy.com on client.

# server
# grep ^Domain /etc/idmapd.conf
Domain = test.com

# client
$ grep ^Domain /etc/idmapd.conf
Domain = dummy.com

2. Verify on client the ownership of file file1 (created in Test Setup step 2 above).
NFS Client sees the file ownership as “nobody” – this is due to mismatched NFSv4 ID Map Domain on server and client.

# client sees nobody ownership

$ su GANESHA\aduser1 -c "ls -ltr /mnt/4s"
total 1
-rw-r--r-- 1 nobody nobody 8 Jul 28 20:49 file1

3. Another example where you encounter this issue is upon creating file/dir from client e.g. client creates a file “client.file1” using user GANESHA\aduser1 and tries to get the ownership of this file, it again gets “nobody”.

# client creates file with user GANESHA\aduser1 and still sees "nobody" ownership for that file

$ su GANESHA\aduser1 -c "echo ganesha > /mnt/4s/client.file1"

$ su GANESHA\aduser1 -c "ls -ltr /mnt/4s"
total 1
-rw-r--r-- 1 nobody nobody 8 Jul 28 20:49 file1
-rw-r--r-- 1 nobody nobody 8 Jul 28 20:50 client.file1

Example 2: NFSv4 ID Map Domain MATCH

1. To solve the issue observed in Example 1 above, we’ll set NFSv4 ID Mapping domain on NFS client to the same value as that of server. For this, we’ll edit /etc/idmapd.conf file and change Domain attribute to “test.com”.

# client: change NFSv4 ID Mapping domain and match it with NFS server

# client
$ vim /etc/idmapd.conf
$ grep ^Domain /etc/idmapd.conf
Domain = test.com

2. Restart nfs-idmap service on client.

$ nfsidmap -c; service nfs-idmap restart
Redirecting to /bin/systemctl restart nfs-idmap.service

3. On NFS Client, Check the file ownership again with new idmap settings.
We can see files show the correct ownership (GANESHA\aduser1).

# client shows proper ownership under NFSv4 AUTH_SYS mount
# after matching NFSv4 ID Mapping Domain on client and server

$ su GANESHA\aduser1 -c "ls -ltr /mnt/4s"
total 1
-rw-r--r-- 1 GANESHA\aduser1 GANESHA\ganeshagr1 8 Jul 28 20:49 file1
-rw-r--r-- 1 GANESHA\aduser1 GANESHA\ganeshagr1 8 Jul 28 20:50 client.file1

4. On NFS Client, Create a new file and then check it is reflected with proper ownership (i.e. owner should be set to GANESHA\aduser1 and not to nobody).

# client creates new file and gets proper ownership to that file

$ su GANESHA\aduser1 -c "echo ganesha > /mnt/4s/client.file2"
$ su GANESHA\aduser1 -c "ls -ltr /mnt/4s"
total 2
-rw-r--r-- 1 GANESHA\aduser1 GANESHA\ganeshagr1 8 Jul 28 20:49 file1
-rw-r--r-- 1 GANESHA\aduser1 GANESHA\ganeshagr1 8 Jul 28 20:50 client.file1
-rw-r--r-- 1 GANESHA\aduser1 GANESHA\ganeshagr1 8 Jul 28 20:52 client.file2