/etc/init.d/nfsmount does not start idmapd for clients that map nfs4 volumes. This results in various issues, including incorrect ownership of shared volume files being reported. For nfs servers, idmapd is started, so nfs servers mounting other shared volumes do not have this issue. Reproducible: Always Steps to Reproduce: 1. Configure nfs4 server, export volumes 2. Configure nfs4 client 3. mount volume on client, uid/gid are not mapped to server uid/gid Actual Results: Ids are not mapped unless rpc.idmapd is started on the client. Expected Results: /etc/init.d/nfsmount should also use the start_idmapd function that is only defined in /etc/init.d/nfs Possible workaround is to start /usr/sbin/rpc.idmapd manually or from /etc/conf.d/local.start, but that's quite hacky.
no, the only real sane thing to do would be to split idmapd back out into its own init script so nfs/nfsmount can depend on it
any progress on this or somethin to test?
I think that the same applies to rpc.gssd as well.
*** Bug 146001 has been marked as a duplicate of this bug. ***
Allright, I'd like this little bug fixed. It's been open for more than a year, while as simple a thing as a mere init.d script would fix it. Say I'd write an rpc.idmap initscript and post it here as an attachment, would that be the way to get it into baselayout? (And ofcourse two small patches to the nfs and nfsmount init.d scripts for dependencies) Please acknowledge, and I'll write one tomorrow. Kind regards, Erik Logtenberg.
*** Bug 150006 has been marked as a duplicate of this bug. ***
Created attachment 102849 [details] Reorganized initscripts This fix seems to work for me. Can someone please verify that I have the dependencies correct? I noticed that the current nfs initscript has a bug where RPCSVCDOPTS is misspelt as RPCSVCDDOPTS. The only thing I am worried about is whether any of the rpc.* scripts require the nfs kernel module to be loaded before they will work (as is apparently the case for the current nfs script). I can't test this since I have nfs statically compiled into my kernel. Can someone please test this?
I'm just wondering, why do I need to start nfs (nfsmount?) whenever I want to use nfs shares. I have to start /etc/init.d/nfs on my workstation because of lockd: lockd: cannot monitor <hostname> lockd: failed to monitor <hostname> is what I get without it, and nfs performance is really really sad. Would this fix(es) help here aswell? Or is this the wrong bug at all?
Would be awsome to see some progress here...
nothing is stopping you from helping do the work rather than just expecting other people to do it all for you
Sorry that would have been my fault. Thought it is ready for inclusion. The proposed scripts work great for me. What are the TODOs until inclusion?
Created attachment 105000 [details] nfs-utils-1.0.10-r1.tar.bz2 New archive containing ebuild & files Corrected the nfsmount as nfs4 was missing in (u)mount -at nfs
Hi all, Thomas package work well in my network config. Not problem any more with bad uid/gid. A question: Why his package ins't in portage tree after more than one month ?!?! David
(In reply to comment #13) > Hi all, > Thomas package work well in my network config. > Not problem any more with bad uid/gid. > > A question: > Why his package ins't in portage tree after more than one month ?!?! > > David > Just a little thing: nfs module need to be loaded before /etc/init.d/rpc.idmap was started, else it failed. I just need to add nfs in autoloaded modules list to remove this problem. David
Created attachment 110537 [details] Attempt to load nfs module for idmapd > Just a little thing: nfs module need to be loaded before /etc/init.d/rpc.idmap > was started, else it failed. I just need to add nfs in autoloaded modules list > to remove this problem. Here's a version of rpc.idmapd that will load the nfs module it if it is needed.
first time you use nfsmount on a client machine /var/lib/nfs/rpc_pipefs directory doesn't exist, So you're script will fail if the client computer never ever start /etc/init.d/nfs (witch will create needed directory) look at Mar 24 17:49:12 [rpc.idmapd] Opened /proc/net/rpc/nfs4.nametoid/channel Mar 24 17:49:12 [rpc.idmapd] Opened /proc/net/rpc/nfs4.idtoname/channel Mar 24 17:49:12 [rpc.idmapd] main: open(/var/lib/nfs/rpc_pipefs/nfs): No such file or directory they avoid that bug in /etc/init.d/nfs by making directories first as mkdir_nfsdirs() { local d for d in /var/lib/nfs/{rpc_pipefs,v4recovery,v4root} ; do [[ ! -d ${d} ]] && mkdir -p "${d}" done } could you fix the script to handle first time use in a client exclusive context? also will be really cool if anyone commit the fix or a similar one :P
nfs-utils-1.0.12-r2 now in portage with split init.d scripts for any issues with this version (i'd be surprised if there werent any), please file new bugs
