NFS4: rpc.idmapd or nfs.idmap upcall?
https://www.kernel.org/doc/Documentation/filesystems/nfs/idmapper.txt states:
The file /etc/request-key.conf will need to be modified so /sbin/request-key can
direct the upcall. The following line should be added:
#OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ...
#====== ======= =============== =============== ===============================
create id_resolver * * /usr/sbin/nfs.idmap %k %d 600
This will direct all id_resolver requests to the program /usr/sbin/nfs.idmap.
This entry does not exist in request-key.conf as of Ubuntu 12.04. I have seen several different conflicting reports about this:
- nfs.idmap upcall is obsolete and rpc.idmapd should be used instead
- rpc.idmapd is obsolete and nfs.idmap should be used instead
- The kernel automatically juggles between the two (which does it prefer?)
Can anyone shed any light on this?
Thanks.
It's clear from debugging a bit that Ubuntu's using rpc.idmap as shipped (up to 12.04, at least).
The archaeology: You need a kernel with the nfsidmap mechanism compiled in (the option is 'new' idmap - so I assume it's the replacement of rpc.idmap, therefore) to get the nfsidmap calls to work. Also, http://www.mjmwired.net/kernel/Documentation/filesystems/nfs/idmapper.txt contains the kernel documentation (3.5 as of writing) that suggests that rpcidmap is called first, which I assume indicates the preference of methods (your documentation appears to be an old copy).
The practical information: nfsidmapp is part of a wider request-key security system that's a comparatively recent addition to the kernel ('comparatively' in that it's been in there over a year, but that's quite short by Ubuntu release cycles). It appears that Ubuntu doesn't support that entire mechanism as yet.
The nfs-utils package includes both rpc.idmap and nfsidmap binaries, and of course the documentation for nfsidmap is written to read like 'this thing you're using, it works like this'. So unfortunately the documentation for the commands doesn't give you any clues as to which is actually set up.
(Also as far as I can tell, rpc.idmap doesn't translate IDs on 'open' calls, only on 'stat' and similar, leading to bizarre cases where you can't write files that stat says you own, but can write files owned by nobody... I don't know if nfsidmap changes that behaviour.)