rpc.idmapd not mapping

awalker · n00b Joined: 25 Jun 2012 Posts: 2

After a kernel upgrade from 2.6 to 3.4 on one of my machines, rpc.idmapd no longer correctly maps names to IDs. Instead, the uid/gid for everything is 4294967294. I figured maybe I messed up with idmapd.conf. Nope, md5 is the same on all of the servers. I set the verbosity to 10, with the following being generated in syslog:

alex.blackbit · Advocate Joined: 26 Jul 2005 Posts: 2397

2.6 -> 3.4 is a big step.
did you update the rest of your system too?
glibc with current kernel headers comes to mind.

awalker · n00b Joined: 25 Jun 2012 Posts: 2

Everything updated in one go. Will try recompiling glibc.

Edit: Considering everything else runs without any displayed error before recompiling glibc, what all should I recompile after? The only symptom shown is idmapd not properly mapping.

Extra edit: Before creating this thread, I verified revdep-rebuild -i, perl-cleaner, and python-updater showed nothing out of the ordinary.

kimmie · Guru Joined: 08 Sep 2004 Posts: 531 Location: Australia

The reason you are seeing no activity from rpc.idmapd is that in kernel 3.4 and above, the default is to disable the id mapper when you use nfs4 and sec=sys.

Reading the doco, it looks like sec=sys and the id mapper can be used to correctly map uid/gid to name where the client and server have different mappings in /etc/passwd and /etc/group. This simply isn't true.

That's because with sec=sys the id mapper doesn't come into play in the authentication part of the nfs protocol, only the file attributes part. With sec=sys authentication, nfs just passes the client uid/gid which is used directly by the server. So permissions checks will be screwed if client and server uid and gid don't align. To confuse things further, when the client creates a new file it is the authentication credentials that are used, so the file gets created at the server with the client's uid/gid. After that nfs uses idmap to get the file attributes, so the uid/gid (which originally came from the client) gets mapped at the server, and you end up seeing the server's name for a client uid/gid. Borkage! On the other hand, if the file was originally created at the server, you will see the correct name at the client, even if the uid/gid differs. But permissions checking will still be broken.

If you want to see this for yourself, you can re-enable id mapping; it is controlled by the nfs4_disable_idmapping module parameter on the client and server modules: