NFSv4 with idmap

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.

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