NFS “nobody” file permission issue

Files in mounted folder owned by nobody:nobody – I’ve tried to change using chown with the existing username and group which also present on the NFS server but still nobody:nobody.

NFSv4 handles user identities differently than NFSv3.
In v3, an nfs client would simply pass a UID number in chown (and other requests) and the nfs server would accept that (even if the nfs server did not know of an account with that UID number).

However, v4 was designed to pass identities in the form of <username>@<id-map-domainname>.  To function correctly, that normally requires idmapd (id mapping daemon) to be active at client and server, and for each to consider themselves part of the same id mapping domain.

portmap — accepts port reservations from local RPC services. These ports are then made available (or advertised) so the corresponding remote RPC services access them. portmap responds to requests for RPC services and sets up connections to the requested RPC service. This is not used with NFSv4.

rpc.idmapd — This process provides NFSv4 client and server upcalls which map between on-the-wire NFSv4 names (which are strings in the form of user@domain) and local UIDs and GIDs. For idmapd to function with NFSv4, the /etc/idmapd.conf must be configured. This service is required for use with NFSv4.

For NFSv4 ID mapping to work properly, both client and server must be running the idmapd ID Mapper daemon and have the same Domain configured in /etc/idmapd.conf.

This way your NFS Client sends its ID credentials as in the NFS commands on the wire, and your NFS Server idmapper maps that to a user called roger on the NFS Server. The UID and GID don’t matter, they are mapped on each system by the idmapper.


Chown failures or idmapd errors like the ones documented above are typically a result of either:
1.  The username is known to the client but not known to the server, or
2.  The idmapd domain name is set differently on the client than it is on the server.
Therefore, this issue can be fixed by insuring that the nfs server and client are configured with the same idmapd domain name (/etc/idmapd.conf) and both have knowledge of the usernames / accounts in question.
However, it is often not convenient to insure that both sides have the same user account knowledge, especially if the nfs server is a filer.  The NFS community has recognized that this idmapd feature of NFSv4 is often more troublesome that it is worth, so there are steps and modifications coming into effect to allow the NFSv3 behavior to work even under NFSv4.

If you are not using NFSv4 check the user is recognized/present on client and servers. If it s a local user on the client system which server doesn’t know then it is still marked as nobody.

If you are using NFSv4 then it expects the server and client to be present in the same domain but our client system in different domain compared to the nfs server.
Check in /etc/idmapd.conf for domain configuration. We can also configure the default nobody user and nobody group to something that we want. After updating the entries restart the “rpcidmapd” process and clear the idmap cache using “nfsidmap -c”.

The “Domain =” directive within /etc/idmapd.conf should be modified to read:

Domain = localdomain

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

# service rpcidmapd restart
# mount -o remount /nfs/mnt/point

On Red Hat Enterprise Linux 6 a clearing of the idmapd cache may be required:

# nfsidmap -c


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s