NFSv4 mountpoint shows incorrect

ownerships as nobody:nobody in
CentOS/RHEL
By admin

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
Jun 3 00:26:54 node1 rpc.idmapd[1874]: nss_getpwnam: name ‘root@oracle.com’ does not map into domain

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-%