NFSv4 mount incorrectly shows all files with ownership as nobody:nobody

 

• Red Hat Enterprise Linux 5
  

• Red Hat Enterprise Linux 6
  

• Red Hat Enterprise Linux 7
  

• NFSv4 share being exported from an NFSv4 capable NFS server
  

• From the client, 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 who created the new file and directory.
  

• Seeing nobody:nobody permissions on nfsv4 shares on the nfs client. Also seeing the following error in /var/log/messages:
  

• Modify the /etc/idmapd.conf with the proper domain (FQDN), on both the client and server. In this example, the proper domain is "example.com" so the "Domain =" directive within /etc/idmapd.conf should be modified to read:
  

• Note:
  

• If using a NetApp Filer, the NFS.V4.ID.DOMAIN parameter must be set to match the "Domain =" parameter on the client.
  

• If using a Solaris machine as the NFS server, the NFSMAPID_DOMAIN value in /etc/default/nfs must match the RHEL clients Domain.
  

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

• Ensure the client and server have matching UID's and GID's. It is a common misconception that the UID's and GID's can differ when using NFSv4. The sole purpose of id mapping is to map an id to a name and vice-versa. ID mapping is not intended as some sort of replacement for managing id's.
  

• 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 than a clearing of the idmapd cache may be required:
  

• Another check, see if the passwd:, shadow: and group: settings are set correctly in the /etc/nsswitch.conf file on both Server and Client.
  

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

 

• If using a NetApp filer, the options nfs.v4.id.allow_numerics on command can be used to disable idmapping. More information can be found

• With this boolean enabled, NFS clients will instead send numeric UID/GID numbers in outgoing attribute calls and NFS servers will send numeric UID/GID numbers in outgoing attribute replies.
  

• If NFS clients sending numeric UID/GID values in a SETATTR call receive an NFS4ERR_BADOWNER reply from the NFS server clients will re-enable idmapping and send user@domain strings for that specific mount from that point forward.
  

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

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

• The following output is shown in /var/log/messages when the mount has been completed and the system shows nobody:nobody as user and group permissions on directories and files:
  

• Collect a tcpdump of the mount attempt:
  

• If a TCP packet capture has been obtained, check for a nfs.nfsstat4 packet that has returned a non-zero response equivalent to 10039 (NFSV4ERR_BADOWNER).
  

• From the NFSv4 RFC:
  

 

• Product(s)
  

•  
  

• Component
  

•  
  

• Category
  

•  
  

• Tags
  

•  
  

•  
  

•  
  

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.