NFSv4 with idmap

nfs

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

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.

Related Topic