rpc.idmapd on my nfs server starts without /proc/net/rpc/nfs4.nametoid/channel being present, so idmapping names does not work on the clients. restarting rpc.idmapd fixes this syslog: rpc.idmapd[6243]: nfsdopenone: Opening /proc/net/rpc/nfs4.nametoid/channel failed: errno 2 (No such file or directory) nfs related modules: nfsd 259112 17 exportfs 7424 1 nfsd (these modules are _not_ listed in /etc/autoload.d) Reproducible: Always Steps to Reproduce: 1. reboot 2. access server from nfs client 3. Actual Results: All files on the nfs client are owned by nobody. Expected Results: correct file ownership I'm using the default runnlevel atm. rc-update -s acpid | default xen alsasound | boot apache2 | default xen apcupsd | default bootmisc | boot checkfs | boot checkroot | boot clock | boot consolefont | boot courier-authlib | default courier-imapd | default courier-imapd-ssl | default cpufrequtils | boot cupsd | default dhcpd | default distccd | default fetchmail | default hald | default xen hostname | boot keymaps | boot local | default nonetwork xen localmount | boot maradns | default xen modules | boot mysql | default net.eth0 | xen net.lo | boot netmount | default xen net.xenbr0 | default xen nfs | default xen nfsmount | default xen ntp-client | default ntpd | default xen portmap | default xen postfix | default rmnologin | boot rpc.gssd | default rpc.idmapd | default rpc.statd | default rsyncd | default samba | default xen saslauthd | default smartd | default squid | default xen sshd | default xen syslog-ng | boot urandom | boot vdr | default vdradmin | default vixie-cron | default vnc | default xend | xen xinetd | default xen
Forgot the versions: net-fs/nfs-utils-1.1.0-r1 USE="kerberos tcpd -nonfsv4" Linux version 2.6.24-gentoo-r5 (root@deepthought) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2)) #1 SMP
Hit the same on Ubuntu, and also found a mailing list thread for it: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/235930 http://thread.gmane.org/gmane.linux.nfsv4/6311/focus=6312 Cause of the problem seems to be that /proc/net/rpc/nfs4.nametoid is provided by nfsd.ko, the nfs SERVER module, so that needs to be loaded even for nfs4 clients. The solution would probably be to have the rpc.idmapd init script modprobe nfsd, perhaps after checking for /proc/net/rpc/nfs4.nametoid.
i dont think so ... as they say, that warning is harmless in the client case i think files/nfs.initd should check to see if nfsd is a module and if so, silently send a SIGHUP to the idmapd daemon ...
implemented that in cvs http://sources.gentoo.org/net-fs/nfs-utils/files/nfs.initd?r1=1.14&r2=1.15
I don't understand why this nfsv4 proc entry is expected at all here: USE="kerberos tcpd -nonfsv4" I have a similar option on the current build: [ebuild R ] net-fs/nfs-utils-1.2.0 USE="nfsv3 tcpd -ipv6 -kerberos -nfsv4" 0 kB I don't have nfsv4 in the kernel bash-4.0#grep -i nfs .config CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_NFS_V3_ACL is not set # CONFIG_NFS_V4 is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y # CONFIG_NFSD_V3_ACL is not set # CONFIG_NFSD_V4 is not set CONFIG_NFS_COMMON=y I don't have that proc entry but dmesg shows an ERROR when it is not found. Aug 15 04:02:44 genbox rpc.idmapd[5674]: nfsdreopen: Opening '/proc/net/rpc/nfs4.nametoid/channel' failed: errno 2 (No such file or directory) Aug 15 04:02:44 genbox rpc.idmapd[5674]: nfsdreopen: Opening '/proc/net/rpc/nfs4.idtoname/channel' failed: errno 2 (No such file or directory) Aug 15 04:02:44 genbox sm-notify[9520]: Already notifying clients; Exiting! Sorry if this is a separate issue, I'll open another bug, but it seems relevant to the USE clause stated above.
here's a better question ... why are you starting rpc.idmapd if you arent using nfs4 ? the init.d scripts arent installed for USE=-nfsv4
