NFS4: "/etc/init.d/rpc.idmapd" is not started during "/etc/init.d/nfs start". Without rpc.idmapd being started within /etc/init.d/nfs, exported files all contain "nobody, nobody" respectively for "uid, gid". "/etc/conf.d/nfs" does however contain the variables to pass to these optional rpc services. Reproducible: Always Steps to Reproduce: 1. /etc/init.d/nfs start 2. ls -alh /nfs_exported_share_on_client 3. (lists folders/files with uid:gid nobody:nobody Actual Results: rpc.idmapd is not started Expected Results: rpc.idmapd should be started when nfs is started?
It should have been started automatically... Please post your `emerge --info' too.
What info are you looking for exactly within emerge --info? nfs is in useflags, but from what I know, /etc/init.d/nfs provides the required scripting.
Since I'm using nfs4, this is probably more likely what your really want to know. $ eix -scI rpc [I] dev-perl/Event-RPC (0.90 @07/19/08): Event based transparent Client/Server RPC framework [I] dev-perl/PlRPC (0.2020-r1 @08/05/08): The Perl RPC Module [I] net-libs/librpcsecgss (0.16 @08/06/08): implementation of rpcsec_gss (RFC 2203) for secure rpc communication [I] net-libs/rpc2 (2.0(1) @08/06/08): Remote procedure call package for IP/UDP (used by Coda) $ eix -scI nfs [I] net-fs/nfs-utils (1.1.2-r1 @08/06/08): NFS client and server daemons [I] net-libs/libnfsidmap (0.20 @08/07/08): NFSv4 ID <-> name mapping library
if you want nfs, you have to add rpc.idmapd yourself. rpc.idmapd is not a requirement for NFSv2/NFSv3, thus it is not a requirement for the nfs init script.
Is there a way to grep /proc/filesystems, or use /usr/sbin/nfsstat for signaling the server is using nfs4 v4. If so, start rpc.idmapd. (This would probably be added into /etc/init.d/nfs script.)
no ... it is not possible to devine user intention from feature availability
(In reply to comment #6) > no ... it is not possible to devine user intention from feature availability > Yes it is! ;) You could either spend some kind of variable in /etc/conf.d/nfs to enable NFS2/3/4 or add an extra "nfs4" init-script. I really don't need all the NFS2/3 stuff started and wasting time by adapting the firewall. I spent half of today on googling and searching for how to configure the user mapping until I realized there is a "use" dependency in /etc/init.d/nfs but no "need" dependency. Print at least some ewarn that rpc.idmapd has to be added manually for NFS4 in the nfs-utils ebuild, please!
I second this. I did exactly as you did ml after opening this bug. (Not only this, a year prior when I first started using NFS4, I couldn't find any answer for this bug, so user:groups never mapped.) At least some warning should be printed by /etc/init.d/nfsd that /etc/init.d/rpc.idmapd (?) should be started manually if you are using NFS4 and want user:group mapping! If nobody is going to fix this bug within the init scripts, at least print a d*mn warning. I'd do the same if it were my scripts & programming... then again, my programming is littered with warnings & debug info. (Reopening bug as above ml poster insists. I feel it's kicking a dead horse. ;-)
nfs-utils-1.1.6-r1 has a conf.d option for this that defaults to on when USE=nfsv4 http://sources.gentoo.org/net-fs/nfs-utils/nfs-utils-1.1.6-r1.ebuild?r1=1.1&r2=1.2 http://sources.gentoo.org/net-fs/nfs-utils/files/nfs.confd?r1=1.11&r2=1.12 http://sources.gentoo.org/net-fs/nfs-utils/files/nfs.initd?r1=1.18&r2=1.19
Thanks a million for this. (It's a bug that had me stumped for years before finding the solution! ... wasn't the only one either.)
