NFS4 mount shows all ownership as "nobody" or 4294967294
This document (7005060) is provided subject to the disclaimer at the end of this document.
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.
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.
NOTE, however, that correcting the idmapd configuration may not be the most desired solution. The need for ID mapping was mandatory when NFS4 first came about, but now it is considered optional. Adding ID mapping to an NFS configuration is generally considered complicated, unnecessary, and without real benefits. Therefore, if possible, it is usually desired to avoid the use of ID mapping.
1. Avoiding the idmapping method
1.1 Avoiding idmapping on Linux NFS Clients
A Linux NFS client will attempt (or not attempt) to use idmapd based on the nfs module option:
This can be set to 0 or 1, off or on. Note that this is a "disable" option, so having it ON (1) means that the use of idmapping will be disabled (or off). However, even with idmapping "disabled", if the NFS client is interacting with a NFS Server with a very old implementation, the NFS Server might insist that idmapping be used, and then the client will fall back to using idmapping anyway.
SLES 12 and 15 (or likely anything using kernel 3.3 or higher) default to having this option set to "1", so those systems acting as NFS clients will not attempt idmapping by default.
SLES 11 (using kernel 3.0.x) has this option set to 0 by default, so it will need to be set to 1 if desired.
SLES 10 (using kernel 2.x) probably did not have this option at all.
The current value can be checked with:
The option can be set a variety of ways:
A. It can be done via Yast --> System --> Boot loader, by adding the kernel command line option:
B. Alternatively, it can take effect slightly later during boot if the following has been done:
Edit or create /etc/modprobe.d/99-nfs.conf
and add (or modify) the line:
options nfs nfs4_disable_idmapping=1"
C. It can also be set on-the-fly (in case immediate reboot is not possible) with:
echo 1 > /sys/module/nfs/parameters/nfs4_disable_idmapping
Note, however, that setting it on the fly will only impact mounts performed after it is set. It will be necessary to umount and remount existing nfs4 mounts to put it into effect there. It is best to umount all mounts first, before remounting any, because multiple mounts pointing to one server can share an environment.
1.2 Avoiding ID mapping on Linux NFS Servers
A Linux NFS Server using kernel 3.4 or higher (including SLES 12 and 15) will allow clients to submit requests with either method: ID mapping, or passing plain UID/GIDs. So having NFS Servers "avoid" idmapping is simply a matter of being on a relatively modern kernel and then insure the clients avoid asking for it as well.
NFS Servers on older kernels (such as used on SLES 10 or 11) will insist on using idmapping. An NFS 4 client which attempts to use the UID/GID method will be told to use idmapping instead.
1.3 Avoiding ID Mapping on non-Linux NFS Servers or Clients.
Many non-Linux NFS Servers or client may not automatically avoid using idmapping. They may have configuration options which control whether NFS 4 will insist on using idmapping or will allow the old UID/GID method from v3 to be used on v4 as well. It can simplify NFS v4 usage greatly to configure such 3rd party devices to allow the v3 method (UID/GID) to be used with v4 also.
2. If or when ID Mapping is MANDATED
If ID mapping MUST be used, it is usually because either the NFS client or NFS server code (or both) is quite old. In some cases, it is mandated by administrative decision. In those cases, if the "nobody" ownership symptom (the original title and subject of this document) is present, it is typically caused when the NFS v4 identity mapping daemon (idmapd) is not running, or it is misconfigured, or it is holding old information in it's cache.
SLES NFS Servers (those which export or "share" their file systems via NFS) need to be running idmapd in case a client requests that method. On Linux, check for an idmapd process with:
2.1.2 SLES NFS Client machines
220.127.116.11 "Recent" SLES NFS client systems (SLES 12 SP4 and higher) typically do not require idmapd to be loaded at the client. They will use an upcall program called "nfsidmap" to accomplish the client functions of idmapping.
18.104.22.168 Earlier NFS 4 clients (older code found in SLES 10, 11, and early 12 support packs) required idmapd to be running at the client machine as well. On those and other older Linux distributions, check for an idmapd process with:
ps aux | grep idmapd
It can also be helpful for /etc/idmapd.conf to contain a [Translation] section which specifies the method of translating between names and IDs. Typically, it is best to point to nsswitch methodology.
[General] Verbosity=7 Pipefs-Directory=/var/lib/nfs/rpc_pipefs Domain=localdomain [Mapping] Nobody-User=nobody Nobody-Group=nobody [Translation] Method=nsswitch
fs.nfs.idmap_cache_timer = 60
If the ID mapping method is in use, the correct display of usernames depends upon the NFS v4 server having the same knowledge of user and group accounts (including their UIDs and GIDs) as the NFS v4 client is using, and both must be in the same idmapd domain.
One of the original intentions of ID mapping (when it was conceived theoretically) was that the NFS client and NFS server would not need to get information from the same identity stores, and (for example) "userBOB@domainORG" would not need to be known as the same UID at both ends. However, this theory did not keep in mind that the RPC layer (which all NFS depends upon) still focuses on UIDs and GIDs, so this goal is not currently obtainable.
However, in these non-idmapd variations of the symptom, "nobody" would appear simultaneously on both the client and the server. In other words, the client and server would agree on the "nobody" ownership.
This is because of a separate common cause: 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". Therefore, after a NFS client's root user 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:06-Nov-2023
- SUSE Linux Enterprise Server
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com