{"id":6400,"date":"2016-10-25T23:38:52","date_gmt":"2016-10-25T15:38:52","guid":{"rendered":"http:\/\/rmohan.com\/?p=6400"},"modified":"2016-11-16T15:08:53","modified_gmt":"2016-11-16T07:08:53","slug":"nfsv4-mounts-show-nobody-as-owner-and-group-on-a-rhel-6-client","status":"publish","type":"post","link":"https:\/\/mohan.sg\/?p=6400","title":{"rendered":"NFSv4 mounts show “nobody” as owner and group on a RHEL 6 client"},"content":{"rendered":"

Issue<\/p>\n

\n
\n
\n
\n
\n
\n
\n
\n
\n
    \n
  • On Red Hat Enterprise Linux a NFS mounted share shows “nobody” as the owner and groupowner of all the files and directory.<\/li>\n<\/ul>\n<\/section>\n
    \n

    Resolution<\/h2>\n
      \n
    1. Create the same user on the Server and Client<\/li>\n
    2. Use a centralized namespace like LDAP domain, NIS, Active Directory etc<\/li>\n<\/ol>\n<\/section>\n
      \n

      Root Cause<\/h2>\n

      The observed behavior is an expected and intended behavior and is not related to RHEL5 or RHEL6 but instead it is related to NFSv3 and NFSv4.<\/p>\n

      In NFSv3 the username and groupname is mapped from the UID\/GID value, the UID\/GID of the user creating the resource is saved on the server, When the clients access it , the \/etc\/passwd<\/code> and \/etc\/gpasswd<\/code> file will be checked to see if the id<\/code> 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 , else the numeric value will be shown.<\/p>\n

      In NFSv4 the concept is user@domainname<\/code>, 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<\/code>.<\/p>\n

      Check for mis-configuration of the \/etc\/imapd.conf file. If you make changes to the idmapd.conf file, on RHEL 6.5 and newer the command to clear out the old mappings is:<\/p>\n

      \n
      # nfsidmap -c<\/code><\/div>\n<\/div>\n<\/section>\n
      \n
      \n
      \n
      \n
      \n
      \n
      \n
      \n
      \n

      <\/h1>\n

      NFSv4 mount incorrectly shows all files with ownership as nobody:nobody<\/h1>\n
      \u00a0From 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.
      \nSeeing nobody:nobody permissions on nfsv4 shares on the nfs client. Also seeing the following error in \/var\/log\/messages:nss_getpwnam: name ‘root@example.com’ does not map into domain ‘localdomain’
      \nResolution
      \nModify 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:<\/p>\n

      Domain = example.com
      \nNote:
      \nIf using a NetApp Filer, the NFS.V4.ID.DOMAIN parameter must be set to match the “Domain =” parameter on the client.
      \nIf using a Solaris machine as the NFS server, the NFSMAPID_DOMAIN value in \/etc\/default\/nfs must match the RHEL clients Domain.
      \nTo put the changes into effect restart the rpcidmapd service and remount the NFSv4 filesystem:<\/p>\n

      # service rpcidmapd restart
      \n# mount -o remount \/nfs\/mnt\/point
      \nNote: 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.
      \nEnsure 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.
      \nOn 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:<\/p>\n

      # nfsidmap -c
      \nNote: The above command is only necessary on systems that use the keyring-based id mapper, i.e. 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 should be cleared out when rpc.idmapd is restarted.
      \nAnother check, see if the passwd:, shadow: and group: settings are set correctly in the \/etc\/nsswitch.conf file on both Server and Client.
      \nDisabling idmapping
      \nBy default, RHEL6.3 and newer NFS clients and servers disable idmapping when utilizing the AUTH_SYS\/UNIX authentication flavor by enabling the following booleans:<\/p>\n

      NFS client
      \n# echo ‘Y’ > \/sys\/module\/nfs\/parameters\/nfs4_disable_idmapping<\/p>\n

      NFS server
      \n# echo ‘Y’ > \/sys\/module\/nfsd\/parameters\/nfs4_disable_idmapping
      \nIf using a NetApp filer, the options nfs.v4.id.allow_numerics on command can be used to disable idmapping. More information can be found here.
      \nWith 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.
      \nIf 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.
      \nNote: This option can only be used with AUTH_SYS\/UNIX authentication flavors, if you wish to use something like Kerberos, idmapping must be used.
      \nRoot Cause
      \nNFSv4 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.
      \nDiagnostic Steps
      \nDebugging\/verbosity can be enabled by editing \/etc\/sysconfig\/nfs:<\/p>\n

      RPCIDMAPDARGS=”-vvv”
      \nThe 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:<\/p>\n

      Jun 3 20:22:08 node1 rpc.idmapd[1874]: nss_getpwnam: name ‘root@example.com’ does not map into domain ‘localdomain’
      \nJun 3 20:25:44 node1 rpc.idmapd[1874]: nss_getpwnam: name ‘root@example.com’ does not map into domain ‘localdomain’
      \nCollect a tcpdump of the mount attempt:<\/p>\n

      # tcpdump -s0 -i {INTERFACE} host {NFS.SERVER.IP} -w \/tmp\/{casenumber}-$(hostname)-$(date +”%Y-%m-%d-%H-%M-%S”).pcap &
      \nIf 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).
      \nFrom the NFSv4 RFC:<\/p>\n

      NFS4ERR_BADOWNER = 10039,\/* owner translation bad *\/<\/p>\n

      NFS4ERR_BADOWNER An owner, owner_group, or ACL attribute value
      \ncan not be translated to local representation.<\/p>\n<\/div>\n<\/header>\n<\/div>\n\n\n\n
      \n
      \n

      These commands are what I did on CentOS Linux release 7.2.1511 (Core)<\/h2>\n

      Install nfs-utils<\/h3>\n
      yum install -y nfs-utils\r\n<\/code><\/pre>\n
      Append text to \/etc\/fstab<\/code><\/h3>\n
      192.168.1.100:\/mnt\/nfs-server \/mnt\/nfs-client nfs defaults,nofail,x-systemd.automount 0 0\r\n<\/code><\/pre>\n
      Some articles said noauto,x-systemd.automount<\/code> is better, but it worked without noauto<\/code> for me.<\/p>\n
      Check whether mount works<\/h3>\n
      systemctl start rpcbind\r\nsystemctl enable rpcbind\r\nmount -a\r\n<\/code><\/pre>\n
      Fix the problem CentOS 7 won’t auto-mount NFS on boot<\/h3>\n
      Append text to the end of \/usr\/lib\/systemd\/system\/nfs-idmap.service<\/p>\n
      [Install]\r\nWantedBy=multi-user.target\r\n<\/code><\/pre>\n
      Append text to the end of \/usr\/lib\/systemd\/system\/nfs-lock.service<\/p>\n
      [Install]\r\nWantedBy=nfs.target\r\n<\/code><\/pre>\n
      Enable related services<\/h3>\n
      systemctl enable nfs-idmapd.service \r\nsystemctl enable rpc-statd.service \r\n\r\nsystemctl enable rpcbind.socket\r\n\r\nsystemctl status nfs-idmapd.service -l\r\nsystemctl status rpc-statd.service \u2013l\r\n<\/code><\/pre>\n
      Then restarted the OS, I got it.<\/h3>\n
      shutdown -r now<\/code><\/pre>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n<\/div>\n<\/article>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/article>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
      Issue<\/p>\n
       On Red Hat Enterprise Linux a NFS mounted share shows “nobody” as the owner and groupowner of all the files and directory. Resolution Create the same user on the Server and Client Use a centralized namespace like LDAP domain, NIS, Active Directory etc Root Cause <\/p>\n
      The observed behavior is an expected and intended behavior […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[73],"tags":[],"_links":{"self":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/6400"}],"collection":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6400"}],"version-history":[{"count":2,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/6400\/revisions"}],"predecessor-version":[{"id":6408,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/6400\/revisions\/6408"}],"wp:attachment":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6400"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6400"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6400"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}