Bug 101624 – idmapd not started for nfs4 clients

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Tim Hobbs 2005-08-07 03:10:22 UTC]

/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.

[Comment 1 SpanKY 2005-08-07 03:19:21 UTC]

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

[Comment 2 Bret Towe 2005-09-03 14:04:07 UTC]

any progress on this or somethin to test?

[Comment 3 Jan Oravec 2006-07-25 08:26:31 UTC]

I think that the same applies to rpc.gssd as well.

[Comment 4 SpanKY 2006-09-02 12:40:09 UTC]

*** Bug 146001 has been marked as a duplicate of this bug. ***

[Comment 5 Erik Logtenberg 2006-09-02 13:44:36 UTC]

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.

[Comment 6 SpanKY 2006-10-04 06:39:24 UTC]

*** Bug 150006 has been marked as a duplicate of this bug. ***

[Comment 7 Daniel Burr 2006-11-27 09:12:15 UTC]

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?

[Comment 8 Olliver Schinagl 2006-12-06 05:16:06 UTC]

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?

[Comment 9 Thomas Bettler 2006-12-30 02:42:45 UTC]

Would be awsome to see some progress here...

[Comment 10 SpanKY 2006-12-30 03:41:00 UTC]

nothing is stopping you from helping do the work rather than just expecting other people to do it all for you

[Comment 11 Thomas Bettler 2006-12-30 07:10:37 UTC]

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?

[Comment 12 Thomas Bettler 2006-12-30 10:35:36 UTC]

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

[Comment 13 David Girault 2007-02-07 17:24:08 UTC]

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

[Comment 14 David Girault 2007-02-12 10:13:30 UTC]

(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

[Comment 15 Daniel Burr 2007-02-18 14:34:41 UTC]

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.

[Comment 16 nobody 2007-03-24 17:08:06 UTC]

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

[Comment 17 SpanKY 2007-03-25 12:30:49 UTC]

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