Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top 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:

#====== ======= =============== =============== ===============================
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:

  1. nfs.idmap upcall is obsolete and rpc.idmapd should be used instead
  2. rpc.idmapd is obsolete and nfs.idmap should be used instead
  3. The kernel automatically juggles between the two (which does it prefer?)

Can anyone shed any light on this?


share|improve this question
up vote 1 down vote accepted

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, 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.)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.