My Favorites

Close

Please to see your favorites.

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

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.

Environment

SUSE Linux Enterprise Server 11 Service Pack 2
SUSE Linux Enterprise Server 11 Service Pack 3
SUSE Linux Enterprise Server 11 Service Pack 4

Situation

An NFS client with NFS4 (NFSv4) is having trouble with user identities, and logs errors such as:
 
rpc.idmapd[18466]: nss_getpwnam: name 'root@domain.com' does not map into domain 'localdomain'
 
Or when trying to do a "chown", is may show:
 
chown: changing ownership of `filename': Invalid argument

Resolution

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:
 
nfs.nfs4_disable_idmapping=1
 
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.)

Cause

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 TID 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:
 
NFS Clients:
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.
 
NFS Servers:
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.

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:7014266
  • Creation Date:10-DEC-13
  • Modified Date:09-AUG-18
    • SUSESUSE 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