If I understood correctly, historically there have been two independently developed alternative user-space mechanisms that can perform uid <-> user name lookups for the Linux NFSv4 implementation in the kernel, one from the University of Michigan and one from NetApp:
A) /usr/sbin/rpc.idmapd runs as a daemon and listens to some pipe in /run/rpc_pipefs, and kernel sends requests via that pipe
B) kernel executes for each request the command /sbin/request-key, which according to /etc/request-key.* calls nfsidmap, which then answers to the kernel via the add_key() and keyctl() system calls
Which of these is meant to be used on Ubuntu 145.04 LTS, and how to I specify and verify that choice?
I'm asking, because I get syslog messages from rpc.idmapd such as
May 7 13:51:11 dirac nfsidmap[10738]: nss_getpwnam: name 'nobody' does not map into domain 'cl.cam.ac.uk'
and at the same time I also find nfsidmap-related keys in
If I understood correctly, historically there have been two independently developed alternative user-space mechanisms that can perform uid <-> user name lookups for the Linux NFSv4 implementation in the kernel, one from the University of Michigan and one from NetApp:
A) /usr/sbin/ rpc.idmapd runs as a daemon and listens to some pipe in /run/rpc_pipefs, and kernel sends requests via that pipe
B) kernel executes for each request the command /sbin/request-key, which according to /etc/request-key.* calls nfsidmap, which then answers to the kernel via the add_key() and keyctl() system calls
Which of these is meant to be used on Ubuntu 145.04 LTS, and how to I specify and verify that choice?
I'm asking, because I get syslog messages from rpc.idmapd such as
May 7 13:51:11 dirac nfsidmap[10738]: nss_getpwnam: name 'nobody' does not map into domain 'cl.cam.ac.uk'
and at the same time I also find nfsidmap-related keys in
$ sudo cat /proc/keys
[...]
2c6194e5 I--Q-N- 1 26s 3b010000 0 0 id_resolv uid:<email address hidden>
2d5a0c25 I--Q-N- 1 28s 3b010000 0 0 id_resolv uid:<email address hidden>
2e025d97 I--Q--- 1 9m 3b010000 0 0 id_legacy uid:<email address hidden>: 5
2e463b17 I--Q--- 1 9m 3b010000 0 0 id_legacy uid:<email address hidden>: 5
331c87da I--Q-N- 1 28s 3b010000 0 0 id_resolv gid:<email address hidden>
33955fd4 I--Q--- 1 9m 3b010000 0 0 id_legacy gid:<email address hidden>: 4
36702b00 I--Q-N- 1 28s 3b010000 0 0 id_resolv gid:<email address hidden>
376c94e9 I--Q-N- 1 28s 3b010000 0 0 id_resolv uid:<email address hidden>
37ef3e9a I--Q--- 1 9m 3b010000 0 0 id_legacy gid:<email address hidden>: 4
3c332878 I--Q--- 1 9m 3b010000 0 0 id_legacy gid:nobody: 6
3e585863 I------ 1 perm 1f030000 0 0 keyring .id_resolver: 36
3fbf548d I------ 1 perm 1f0b0000 0 0 keyring .system_keyring: 1
Are both these idmap systems really supposed to be active at the same time?
What is the difference between the id_resolv and id_legacy key types?
What does it mean to have negative id_resolv and non-negative id_legacy keys at the same time, as above?
Where is all this NFSv4 uid/gid translation mechanics documented?