The Geek Diary

NFSv4 mountpoint shows incorrect ownerships as nobody:nobody in CentOS/RHEL

by

The Problem

NFSv4 mount incorrectly shows all files with ownership as “nobody:nobody“. From the client server, the mounted NFSv4 share has ownership for all files and directories listed as nobody:nobody instead of the actual user that owns them on the NFSv4 server, or even who created the new file and directory.

Also seeing the following error in /var/log/messages:

nss_getpwnam: name ‘root@example.com’ does not map into domain 'localdomain'

Root Cause

In NFSv3 the username and group_name is mapped from the UID/GID value, the UID/GID of the user creating the resource is saved on the server. When the client servers access it, the /etc/passwd and /etc/gpasswd file will be checked to see if the id exists and for which user it will be mapped to. If there is a user with the same uid and gid, then it will be mapped to that user, otherwise, the numeric value will be shown.

In NFSv4 the concept is user@domainname, if there is no centralized usermapping, then the user will be mapped to the default user nobody or whatever user has been configured in /etc/idmapd.conf.

First check for malformed configuration of the /etc/imapd.conf file. If you make changes to the idmapd.conf file, on CentOS/RHEL 6.5 and newer the command to clean out the old mappings is:

# nfsidmap -c

NFSv4 utilizes ID mapping to ensure permissions are set properly on exported shares. If the domains of the client server and parent server do not match then the permissions are mapped to nobody:nobody.

The Solution

1. Change the /etc/idmapd.conf with the proper fully qualified domain name (FQDN), on both the client and parent server. In this example, the proper domain is “example.com” so the “Domain =” directive within /etc/idmapd.conf should be modified to read:

# vi /etc/idmapd.conf
Domain = oracle.com

2. To put the changes into effect restart the rpcidmapd service and remount the NFSv4 filesystem:

# service rpcidmapd restart
# mount -o remount /nfs/mnt/point
Note: It is only necessary to restart rpc.idmapd service on systems where rpc.idmapd is actually performing the id mapping. On RHEL 6.3 and newer NFS CLIENTS, the maps are stored in the kernel keyring and the id mapping itself is performed by the /sbin/nfsidmap program. On older NFS CLIENTS (RHEL 6.2 and older) as well as on all NFS SERVERS running RHEL, the id mapping is performed by rpc.idmapd. Ensure the client and server have matching UID’s and GID’s. It is a common misconception that the UID’s and GID’s are allowed to be different when using NFSv4. The purpose of id mapping is to map id to a name and vice-versa. ID mapping is not intended as a replacement for id management.

On Red Hat Enterprise Linux 6, if the above settings have been applied and UID/GID’s are matched on server and client and users are still being mapped to nobody:nobody then a clearing of the idmapd cache may be required.

# nfsidmap -c
Note: The above command is only necessary on systems that use the keyring-based id mapper, e.g. NFS CLIENTS running RHEL 6.3 and higher. On RHEL 6.2 and older NFS CLIENTS as well as all NFS SERVERS running RHEL, the cache is cleared out when rpc.idmapd is restarted. Another check, see if the passwd:, shadow: and group: settings are set correctly in the /etc/nsswitch.conf file on both Parent and Client servers.

Disabling idmapping

By default, RHEL6.3 and newer NFS clients and servers disable idmapping when utilizing the AUTH_SYS/UNIX authentication flavor by enabling the following boolean statements:

NFS client server

# echo 'Y' > /sys/module/nfs/parameters/nfs4_disable_idmapping

NFS parent server

# echo 'Y' > /sys/module/nfsd/parameters/nfs4_disable_idmapping

Troubleshooting

If the above plan does not resolve your issue, please perform the following diagnostic steps:

1. Debugging/verbosity can be enabled by editing /etc/sysconfig/nfs:

# vi /etc/sysconfig/nfs
RPCIDMAPDARGS="-vvv"

2. The following output is shown in /var/log/messages when the mount has been finished mounting and the system shows nobody:nobody as user and group permissionson directories and files:

Jul 3 00:23:18 node1 rpc.idmapd[1874]: nss_getpwnam: name ‘root@oracle.com’ does not map into domain ‘localdomain’
Jun 3 00:26:54 node1 rpc.idmapd[1874]: nss_getpwnam: name ‘root@oracle.com’ does not map into domain ‘localdomain’

3. Collect a tcpdump of the mount attempt:

# tcpdump -s0 -i {INTERFACE} host {NFS.SERVER.IP} -w /tmp/{SR_number}-$(hostname)-$(date +”%Y-%m-%d-%H-%M-%S”).pcap &

You May Also Like