Home / server / Questions / 535809
Accepted
HTF
Asked: 2013-09-03 23:40:29 +0800 CST

NFSv4 with idmap

  • 772

The following errors appear on the NFS server, could you please advise how I can fix this?

Details:

System: CentOS release 6.4, NFS: nfs-utils-1.2.3-36

# cat /etc/idmapd.conf

[General]
Domain = domain.com

[Mapping]
Nobody-User = nobody
Nobody-Group = nobody

[Translation]
Method = nsswitch

Sep  3 08:25:28 snode1 rpc.idmapd[1382]: nss_getpwnam: name '0' does not map into domain 'domain.com'
Sep  3 08:25:29 snode1 rpc.idmapd[1382]: nss_getpwnam: name '500' does not map into domain 'domain.com'

EDIT: 03 Sep 2013 10:41

Please note that I'm using NFSv4 and these errors appear on NFS server only (not NFS clients).

Server:

# cat /etc/sysconfig/nfs

MOUNTD_NFS_V2="no"
MOUNTD_NFS_V3="no"
...
RPCNFSDARGS="-N 2 -N 3"

Clients:

# cat /etc/fstab

server:/     /data  nfs4    defaults,hard,intr,timeo=15,_netdev,noatime,nodiratime,nosuid    0 0

Edit: Wed Jun 11 14:52:50 BST 2014

# getent passwd "0" | cut -d: -f1
root
# getent passwd "500" | cut -d: -f1
user1

-

# grep "^passwd" /etc/nsswitch.conf 
passwd:     files
nfs

3 Answers

  1. Best Answer

    I'm going to take a bit of a guess. If you resolve UID '0' or '500' on your NFS server, what do you get? Are they local accounts by any chance?

    The reason I suggest that, is that NFSv4 by design, references account names within a domain, and tries to avoid the 'local authentication' thing from previous versions of NFS. It therefore uses idmapd, which translates account names - passed around in the NFS packets - to translate username to UID/GID.

    As you've correctly determined, that looks to be what's broken here - so my question would be, what authentication domain are you using, and when you query it, do you get an answer for UID 0 and 500?

    I have seen similar when e.g. the server was looking at the wrong branch of the LDAP (well, active directory) directory compared to the client. Because it couldn't resolve the UID/username relationship, it broke, and translated these users into 'nobody' as a result.

    You've got resolution configured via nsswitch - what does nsswitch say for 'passwd'? (On server primarily, as that's where the problem seems to exist).

    Edit: OK, so according to your 'passwd' you've got 'files' as your local database - e.g. /etc/passwd. This means you're mapping UID/GID via local accounts. You shouldn't be ever using UIDs with NFSv4 - it should be usernames.

    However, a spot of googling gives me: http://www.spinics.net/lists/linux-nfs/msg38598.html

    Therefore the next questions is - are you using 'sys' authentication? I'm guessing based on your fstab that you are, at which point - this appears to be expected behaviour - your clients are using 'sys' and therefore passing UID/GID. idmapd is complaining because they're not valid users (they are UIDs).

    If on your client, you 'touch' a file as UID 500, or 0, what does it then look like on client and server (ls -l to get username, ls -ln to get uid)? If that's working correctly, this appears to be an artifact of backwards compatibility between NFSv3 Auth sys, and NFSv4, and the messages are harmless.

    You could consider upgrading to Kerberos authentication or similar, but from experience that's a non trivial exercise. (Albeit ones with some rather handy advantages). That message (trail) I linked implies this error message stops popping up in later kernel versions.

    • 8

  2. It seems you're using NFSv3 which sends only numerical user and group identifiers over the network.

    In order to make idmapd work you will need to use NFSv4 which sends user@domain identifiers understood by idmapper and mapped to local accounts (so you don't need same uid/gid on both server and client).

    Try mounting that share with -t option:

    mount -t nfs4 server:/path /mountpoint
    • 2

  3. please check if following solutions sourced from the gentoo forum help you:

     1. On the NFS server, /etc/hostname did not contain the FQDN, just the local hostname.
 2. This particular client had an unconfigured /etc/idmapd.conf. It had Domain = localdomain instead of Domain = FQDN-minus-hostname.

    For your setup this looks like the 2nd option.

    google for the exact error message "nss_getpwnam: name '0' does not map into domain" gives you plenty of results which might help you aswell (just pointed the most promising)

    • 1