When "Use the new idmapper upcall routine" (CONFIG_NFS_USE_NEW_IDMAPPER) is selected in the kernel configuration the NFS routines use key subsystem to resolve and cache name <-> ID mappings.
This requires the /sbin/request-key to dispatch the request to nfsidmap,
which in turn requires the "create id_resolver * * /usr/sbin/nfsidmap %k %d 600" to be added either to /etc/request-key.conf (as stated in nfsidmap man page), or, better, to a new /etc/request-key.d/id_resolver.conf file.
Currently, net-fs/nfs-utils ebuilds do not do that, which causes chown/chgrp on files on NFS4 mounts to fail with "Invalid argument" on such kernels.
CONFIG_NFS_USE_NEW_IDMAPPER is dead. the behavior is automagic now, so configuring keyutils is not required. see Bug 413173 where this was covered.
(In reply to comment #1)
> CONFIG_NFS_USE_NEW_IDMAPPER is dead. the behavior is automagic now, so
> configuring keyutils is not required. see Bug 413173 where this was covered.
I believe it's still necessary to have a correctly-configured /etc/request-key.conf to use the new upcall behavior, otherwise the kernel will fall back to the old behavior. Everything works correctly if a single missing line is added to /etc/request-key.conf
yes, the config is needed for the upcall, but the point is that things don't fail if the file isn't there
Hello and thanks for quick answer,
First, I see that newly added to the tree ebuild for nfs-utils-1.2.6 installs "/etc/request-key.d/50_id_resolver.conf".
Unfortunately, this does not work as request-key searches for exact name "/etc/request-key.d/<keytype>.conf" (see man 8 request-key) - it can't have any prefix (or postfix, to be exact).
Second, the nfsidmap invocation has actually changed in this very version, and now it needs "create id_resolver * * /usr/sbin/nfsidmap -t 600 %k %d" (it's minus "t" before 600 now).
Commit message: Update request-key.d config settings