NFS4 mount shows all ownership as "nobody" or 4294967294

This document (7005060) is provided subject to the disclaimer at the end of this document.


SUSE Linux Enterprise Server 15
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".  However, when the same files are viewed directly at the NFS Server (not through an NFS client) they show different ownership.

NOTE:  The main discussion in this document only applies to cases where ownership at an NFS client is being reported DIFFERENTLY that the native file system reports when viewed directly at the NFS Server machine.  For cases where *both* the NFS client and NFS server show "nobody" unexpectedly, see the "Additional Information" section below.


Either the NFS v4 identity mapping daemon (idmapd) is not running, or it is misconfigured, or it 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, 12, and 15, 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 beyond the point where one is later created or available.  This is known as a "negative" cache.  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 and higher, 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)


When using NFS v4.x, for user names to be displayed correctly, the NFS v4 server must have knowledge of the same user and group accounts as the NFS v4 client is using, and must be in the same idmapd domain.
NFS v4 is designed to pass identities between servers and clients in the form 'username@domainname'.
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". 

Additional Information

The above concerns with idmapd CANNOT cause problems on NFS v3, because v3 does not use identity mapping.  Even so, when using NFS v3, sometimes users see ownership unexpectedly showing "nobody" and bring up similar questions.  Or even on NFS v4, "nobody" can be seen unexpectedly for a reason not linked to idmapd.

However, in these cases, the NFS client's view and the NFS server's view (directly within it's own native file system) typically agree that the file or directly is indeed owned by "nobody".

This is because of another common cause (not related to idmapd) for files on an NFS mount to be unexpectedly owned by "nobody":  The concept of "root_squash".  By default, an NFS Server which gets a request from a client machine's root user will "squash" the request and treat it as if it came from user "nobody".  So after a NFS client's root use creates something, both the NFS client view and the NFS server view would agree that the entity is owned by "nobody".

For root squash concerns, the most common solutions are:

(a)  Make sure NFS client processes run as a non-root user.
(b)  Set the NFS server to export with the option "no_root_squash", so the NFS client's root user can be treated as the NFS server's root user.  [Though this is less secure.]  See "man exports" for more information.
(c)  Set the NFS server to squash the root user to an ID other than nobody.  This is accomplished with "anonuid" and "anongid" export settings.  See "man exports" for more information.


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.

  • Document ID:7005060
  • Creation Date: 17-Dec-2009
  • Modified Date:11-Jun-2020
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact:

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center