I have NFS4 setup with idmapd working correctly. ls -l from the client shows the correct user names, even though the user ids differ between the machines.

However, when the user ids do not match, I get 'permission denied' errors trying access files, even though ls -l shows the correct username. When the user ids do happen to match by coincidence, everything works fine.

sudo sysctl -w sunrpc.nfsd_debug=1023 gives the following output in the server syslog for the failed file access:

It's really incredible, but idmapd really doesn't do that! It took me 2 days to find that on the web (ie your link to gmane, or this one) and another 2 days to believe that someone could have created such a surprisingly confusing mess. no, talking about uid mapping, having ls -l print out mapped uids but letting it fail when accessing those files... jeee, tststs, headbang, no way!
–
TimSep 27 '12 at 23:51

1 Answer
1

NFSv4 uses utf8 string principals between client and server. As a result, it's sufficient to use the same user names and nfs4 domain on client and server. The uids can be differ. BUT.... If you use AUTH_SYS (mount with sec=sys, which is default) your RPC requests instead of kerberos principal will use uid and gids from the client host. In this case, if uids on client and server differ, you will get access deny. In case of RPCGSS_SEC, your kerberos principal is send and on the server will use the same idmapd to map it to local uid and gids. ls -l works as expected as it uses idmapd to map files owner and group ids to principals which later on send to the client.