SUSE Linux Enterprise Server 11 Service Pack 2
SUSE Linux Enterprise Server 11 Service Pack 3
SUSE Linux Enterprise Server 11 Service Pack 4
An NFS client with NFS4 (NFSv4) is having trouble with user identities, and logs errors such as:
rpc.idmapd: nss_getpwnam: name 'email@example.com' does not map into domain 'localdomain'
Or when trying to do a "chown", is may show:
chown: changing ownership of `filename': Invalid argument
The cause of this is somewhat complex, and there are two ways correct this. The simplest way will be listed here, but it may not be possible on older kernels, and it may not be an ideal solution for all environments. Therefore, it is recommended to review the "cause" section of this document before deciding on the best solution.
Set the following parameter for the kernel nfs module:
To take effect at boot, that can be set on the kernel command line. This can be done in Yast --> System --> Boot loader.
Alternatively, it can be set to take effect during slightly later during boot by executing the following command (after which, subsequent reboots should accomplish the setting):
echo "options nfs nfs4_disable_idmapping=1" > /etc/modprobe.d/99-nfs.conf
It can also be set on-the-fly with:
echo 1 > /sys/module/nfs/parameters/nfs4_disable_idmapping
(However, it will only impact mounts performed after it is set. It will be necessary to umount and remount existing nfs4 mounts.)
NFSv4 handles user identities differently than NFSv3. In v3, an nfs client giving a user's identify would simply pass a UID number in chown (and other requests) and the nfs server would accept it, 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.
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.
More information can be found about troubleshooting idmapd in KB 7005060:
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.
The "Resolution" section above was written from the perspective of returning to NFSv3 identify methods even when using NFS v4. But it may not be possible in all cases (especially with older kernels) so the following information may be helpful:
Machines running SLES 11 SP2 or higher, and acting as NFS clients, will have the ability to us the NFSv3 identity behavior under NFSv4, but it is not necessarily the default behavior. Setting the kernel module parameter as described in the "Resolution" section of this document is needed. In mainstream Linux, the default behavior changed in kernel 3.3, i.e. to already have nfs4_disable_idmapping set to 1. So, for example, on SLES 12 machines, setting this manually will not be needed, as SLES 12 uses a newer kernel which already defaults to 1.
Some NFSv4 Servers may not be prepared to accept this behavior, either. Both the NFS Client machine and the NFS Server machine need to have this ability. If using a Linux NFSv4 Server, it is necessary to use a distribution with kernel 3.4 or higher (for example, SLES 12). For 3rd party filers, check the NFS configuration for settings related to idmap, uids, etc.