Bugzilla Bug 101624

/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 an attachment (id=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 an attachment (id=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 an attachment (id=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