idmapd errors about "localdomain", or chown failing on nfs4 mount, with "invalid argument"
This document (7014266) is provided subject to the disclaimer at the end of this document.
Set the following parameter for the kernel nfs module:
That parameter 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 this 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. Umounting is not always possible (if the file systems are busy) so scheduling a reboot may be needed anyway.
See the "Cause" section for other options, though likely less preferred.
However, it is often not convenient to insure that both sides (client and server) have the same user account knowledge, especially if the NFS Server is a filer. Therefore, troubleshooting and fixing the idmapd configuration is often not the preferred or quickest solution. For that, refer back to the "Resolution" section. However, in some cases, an old device with an old OS is present, which cannot disable the use of idmapping with NFS v4.
The "Resolution" section above was written from the perspective of returning to traditional UID/GID identify methods (already used in NFS v3) even when using NFS v4. However, 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 use the UID/GID 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 is not needed (unless it has been manually set to 0, previously)
Some NFSv4 Servers may not be prepared to accept the UID/GID method. Both the NFS Client machine and the NFS Server machine need to be new enough to accept that method in v4. 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 identity settings related to ID mapping, UIDs, etc.
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:7014266
- Creation Date: 10-Dec-2013
- Modified Date:13-Sep-2022
- SUSE Linux Enterprise Server
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com