My Favorites

Close

Please to see your favorites.

  • Bookmark
  • Email Document
  • Printer Friendly
  • Favorite
  • Rating:

NFS4 mount shows all ownership as "nobody" or 4294967294

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

Environment

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

Situation

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.

Resolution

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.
 
[General]
Verbosity=7
Pipefs-Directory=/var/lib/nfs/rpc_pipefs
Domain=localdomain
 
[Mapping]
Nobody-User=nobody
Nobody-Group=nobody
 
[Translation]
Method=nsswitch 
 
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)
 

Cause

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.
 
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". 

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/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-09
  • Modified Date:25-JUN-18
    • SUSESUSE Linux Enterprise Desktop
      SUSE Linux Enterprise Server

Did this document solve your problem? Provide Feedback

< Back to Support Search

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