# NFSv4 with idmap

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

• try to enforce numeric ID's on the server: echo "options nfs nfs4_disable_idmapping=1" > /etc/modprobe.d/nfs.conf and reboot NFS server. – kofemann Sep 4 '13 at 5:59
• did you ever find a solution? I seem to have the same problem with some linux distros, but not others. – Cyclone Apr 25 '14 at 3:12
• No, there is also a RedHat bug related to this issue, unfortunately not resolved - bugzilla.redhat.com/show_bug.cgi?id=997164 – HTF Apr 29 '14 at 15:25

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.

• Please see my edit: Wed Jun 11 14:52:50 BST 2014 – HTF Jun 11 '14 at 13:54
• Edited my answer in response, because it's easier to read. – Sobrique Jun 11 '14 at 14:47

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


 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)