/etc/init.d/nfs and /etc/init.d/nfsmount calculate their dependencies incorrectly with regards to rpc.idmapd rpc.gssd and rpc.svcgssd. rpc.gssd and rpc.svcgssd are both needed on the client and on the server whenever kerberos is in use. As it stands currently /etc/init.d/nfs only starts rpc.svcgssd and /etc/init.d/nfsmount only starts rpc.gssd if it detects kerberos in use in /etc/fstab and /etc/exports respectively. The existing logic for detecting whether rpc.idmapd is need is not correct if nfs-utils is built with USE="nfsidmap". In this case the client (nfsmount) should NOT start rpc.idmapd and should instead rely a kernel configured with CONFIG_NFS_USE_NEW_IDMAPPER=y and a correctly configured /etc/request-key.conf. Unfortunately the default request-key.conf file shipped with sys-apps/keyutils is missing the required line and the kernel documentation for this feature at Documentation/filesystems/nfs/idmapper.txt misspells "nfsidmap" as "nfs.idmap". Reproducible: Always
that is not what the nfs-utils README says. gssd is for client, and svcgssd is for the server. rpc.idmapd logic is correct if CONFIG_NFS_USE_NEW_IDMAPPER=n. we aren't going to change it to require a recent kernel with that set to y. if there is a way to detect that config at runtime, i can update the nfs.idmapd script to do so. otherwise, it's not changing.
(In reply to comment #1) > that is not what the nfs-utils README says. gssd is for client, and svcgssd > is for the server. I spent all weekend trying to make kerberos authentication work with NFS and the only way I could get it to work is loading both processes on the client and on the server. For example, without rpc.svcgssd on the client I can mount shares and view their contents but any attempt to write fails even if I have the correct kerberos credentials to do so. Also attempting to mount with sec=krb5i or sec=krb5p fails. Loading rpc.svcgssd on the client fixes both of these problems. In addition from looking at my logs with both of them set to extra verbose mode (-vvv) I can see that both the client and the server are using both services (gssd and svcgssd). Perhaps the documentation is outdated? > rpc.idmapd logic is correct if CONFIG_NFS_USE_NEW_IDMAPPER=n. we aren't > going to change it to require a recent kernel with that set to y. if there > is a way to detect that config at runtime, i can update the nfs.idmapd > script to do so. otherwise, it's not changing. Starting with kernel 3.4 CONFIG_NFS_USE_NEW_IDMAPPER=y effectively becomes the default. The old method of using rpc.idmapd as a daemon still will work but it's a fallback instead of the default expected behavior. https://github.com/torvalds/linux/commit/e6499c6f4b5f56a16f8b8ef60529c1da28b13aea My suggestion is that USE="nfsidmap" should check for CONFIG_NFS_USE_NEW_IDMAPPER=y at build time and sys-apps/keyutils (which is pulled in as a dependency) should include the correct line in the default /etc/request-key.conf to make the new upcall routine work.
Another option would be to make /etc/init.d/nfsmount use NFS_NEEDED_SERVICES in /etc/conf.d/nfs to pull in rpc.idmapd just like /etc/init.d/nfs does. That would allow people who do not need rpc.idmapd on the client to disable it without editing /etc/init.d/nfsmount.
build time checks aren't going to cut it. i'm running 3.4-rc1, but i don't think the new idmap changes were merged for that, so i can't poke around /proc to see if there's anything useful in there. guess i'll wait until 3.4 final is released. as for gssd/etc..., feel free to inquire on the nfs lists. i don't have any need for encrypted nfs services, so i have kerberos disabled everywhere.
(In reply to comment #4) > build time checks aren't going to cut it. i'm running 3.4-rc1, but i don't > think the new idmap changes were merged for that, so i can't poke around > /proc to see if there's anything useful in there. guess i'll wait until 3.4 > final is released. I don't know exactly when the change went it but I do know it's included in -rc4.
i'm not really seeing any info in /proc to tell whether the system supports the new mapper. i'm not terribly keen on doing `uname` check at runtime, but we might not have a choice here.
I guess, but i'm not sure, that I have the same problem. It happens only since yesterday (with update to net-fs/nfs-utils-1.3.2-r6). Now at boot i have a mail saying Service `nfsclient' needs non existent service `rpc.idmapd` (it's not "nfsmount' but I think this init file changed name recently). nfs-utils is installed with the following use flag (there's nfsidmap, but not nfsv4) : Installed versions: 1.3.2-r6^t(23:56:47 05/02/2015)(libmount nfsidmap tcpd uuid -caps -ipv6 -kerberos -nfsdcld -nfsv4 -nfsv41 -selinux)
*** Bug 554196 has been marked as a duplicate of this bug. ***
If a kernel is using the new nfsidmapper then the id_resolver keyring will show up in /proc/keys: # cat /proc/keys 016c5d86 I--Q--- 1 perm 1f3f0000 0 65534 keyring _uid_ses.0: 1 1558a32a I--Q--- 2 perm 1f3f0000 0 65534 keyring _uid.0: empty 1bbe499e I------ 1 perm 1f030000 0 0 keyring .id_resolver: empty 372baaaf I------ 1 perm 1f030000 0 0 keyring .dns_resolver: empty So iff /etc/request-key.d/id_resolver.conf exists and the keyring exists you shouldn't start rpc.idmapd?
(In reply to Justus Ranvier from comment #2) > (In reply to comment #1) > > that is not what the nfs-utils README says. gssd is for client, and svcgssd > > is for the server. > > I spent all weekend trying to make kerberos authentication work with NFS and > the only way I could get it to work is loading both processes on the client > and on the server. I have a working NFSv4/Kerberos installation working and I only have rpc.svcgssd running on the server and rpc.gssd on the client. (I didn't try krb5i and krb5p). I described everything here : https://pelican.craoc.fr/nfsv4.html https://pelican.craoc.fr/kerberos.html (it's in french, sorry)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b088105deeb5406690698f092535767f71546570 commit b088105deeb5406690698f092535767f71546570 Author: David Seifert <soap@gentoo.org> AuthorDate: 2024-02-26 10:36:28 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2024-02-26 10:36:28 +0000 net-fs/nfs-utils: drop 2.6.3-r3, 2.6.4-r4 Closes: https://bugs.gentoo.org/413173 Closes: https://bugs.gentoo.org/694288 Closes: https://bugs.gentoo.org/798831 Closes: https://bugs.gentoo.org/914203 Signed-off-by: David Seifert <soap@gentoo.org> net-fs/nfs-utils/Manifest | 1 - net-fs/nfs-utils/files/nfs.confd | 38 ----- net-fs/nfs-utils/files/nfsclient.confd | 18 --- net-fs/nfs-utils/files/nfsmount.initd-1.3.1 | 26 ---- net-fs/nfs-utils/metadata.xml | 35 ++--- net-fs/nfs-utils/nfs-utils-2.6.3-r3.ebuild | 233 --------------------------- net-fs/nfs-utils/nfs-utils-2.6.4-r4.ebuild | 234 ---------------------------- 7 files changed, 16 insertions(+), 569 deletions(-)
