SUSE Linux Enterprise Desktop 12
SUSE Linux Enterprise Desktop 11
SUSE Linux Enterprise Desktop 10
SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Server 11
SUSE Linux Enterprise Server 10
An NFS client is successfully mounting an NFS v4 file system. However, upon executing "ls -al," all the files' user and group ownership are showing as "nobody" or as "4294967294", instead of the values that are shown when viewed directly on the remote NFS server.
Either the NFS v4 identity mapping daemon (idmapd) is not running, or is misconfigured, or is holding old information in it's cache. The identity mapping daemon is not used in NFS v3. See the "Cause" section for more details on the purpose of idmapd, or for discussion of NFS v3 versus v4 in this regard.
1. idmapd not running.
Both the NFS client and the NFS server machines must be running idmapd. On linux, check for an idmapd process with:
ps aux | grep idmapd
A process for "/usr/sbin/rpc.idmapd" should be found.
On SLES 10, you can restart idmapd with the command "rcidmapd restart".
On SLES 11 and 12, idmapd is not separately started, it is part of the initialization of nfs server or nfs client services. It should start anytime either "nfsserver" service or the "nfs" service (which is an initializer for nfs client dependencies) are started. So "rcnfs restart " or "rcnfsserver restart" could be attempted if idmapd is not running.
However, in some cases idmapd might not start. For example, if the /etc/fstab does not contain any NFS v4 mount, it is possible that idmapd will not be started when "nfs" (client) starts.
2. idmapd misconfigured
Both the NFS server and the NFS client must have good /etc/idmapd.conf settings. Even when the same user accounts are known to both the servers and clients, idmapd configuration problems can prevent proper ownership from being displayed.
Check the /etc/idmapd.conf file. The [General] section should have a Domain setting. The domain is an arbitrary string but it must be set identically on NFS clients and their NFS servers. This setting often reports "localdomain" by default, and that is usually adequate. Often, it will be set to match the company's DNS domain name, but that is not required (and would technically be a coincidence, rather than meaningful). It can also be helpful for there to be a [Translation] section which specifies the method of translating between names and IDs. Typically, it is best to point to nsswitch methodology.
So, for example, a typical idmapd.conf file might look like the following. If this file is changed, idmapd must be restarted.
3. idmapd is caching old information.
Old information can be held by idmapd, which may temporarily prevent it from learning new information. Even the fact that a user has no mapping can be cached (aka a "negative cache) beyond the point where one is later created or available. The cache defaults to keeping entries for 10 minutes. This is usually fine, because user identities do not change or get created very often. However, idmapd may learn early in system boot that certain users are not found. This may be due to a delay in access to information. For example, idmapd might start before sssd or other methods of obtaining user identities. In such a case, negative cache might exist for the first 10 minutes after server boot. To make the cache clear more quickly:
Stopping and starting idmapd will correct this, but that is not always desired.
On SLES 12, the command "nfsidmap -c" is available and should clear the cache and allow new information to be learned.
Another option is to lower the cache timer. This is set inside /etc/sysctl.conf with:
fs.nfs.idmap_cache_timer = 60
(this value represents seconds, the default is 600)
For user names to be displayed correctly, the NFS v4 server must have knowledge of the same user and group accounts as the NFS client is using, and must be in the same idmapd domain.
This is a major change from NFS v3's method of passing the UID number. With NFS v3, an NFS server would store and report these UID values in the file system, even if it had no knowledge of the user accounts they belonged to. So essentially, a UID that was not known to one side or the other could still be handled in a valid way.
If users and groups are centrally managed, and all systems have access to the same identity store, idmapd's methods work fairly easily. But it is crucial that NFS servers and NFS clients have access to identical account information and idmapd domain name settings, otherwise idmapd cannot properly do its job, and may display ownership as "nobody" or equivalent high values.
Put simply, in NFS v4 with idmapd, the same username@domainname
must be recognized by both sides, or it will be mapped to "nobody".
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.