rpc.idmapd not working

Bug #87382 reported by Gustavo Carneiro on 2007-02-23
12
Affects Status Importance Assigned to Milestone
nfs-utils (Ubuntu)
Medium
Unassigned
Nominated for Hardy by DaveAbrahams
Nominated for Intrepid by DaveAbrahams
Nominated for Jaunty by DaveAbrahams

Bug Description

I get "Warning: rpc.idmapd appears not to be running." every time I try to mount an nfs4 server, even though rpc.idmapd is running.

I have utf-utils 1:1.0.11~git-20060105-2.

root@spectrum:/home/gjc/mnt # /etc/init.d/portmap restart
 * Stopping portmap daemon... [ OK ]
 * Starting portmap daemon... [ OK ]
root@spectrum:/home/gjc/mnt # /etc/init.d/nfs-common restart
 * Stopping NFS common utilities [ OK ]
 * Starting NFS common utilities [ OK ]
root@spectrum:/home/gjc/mnt # mount -tnfs4 ying64:/tele/gjc ying64/
Warning: rpc.idmapd appears not to be running.
         All uids will be mapped to the nobody uid.
root@spectrum:/home/gjc/mnt # mount -tnfs4 ying64:/tele/gjc ying64/
Warning: rpc.idmapd appears not to be running.
         All uids will be mapped to the nobody uid.
root@spectrum:/home/gjc/mnt # ps ax |grep idmap
17818 ? Ss 0:00 /usr/sbin/rpc.idmapd
17836 pts/0 R+ 0:00 grep idmap

Revision history for this message
Cristian Aravena Romero (caravena) wrote :

$uname -a ?

Revision history for this message
Gustavo Carneiro (gjc) wrote :

Linux ying64 2.6.20-8-server #2 SMP Tue Feb 13 01:19:38 UTC 2007 x86_64 GNU/Linux

Revision history for this message
Gustavo Carneiro (gjc) wrote :

Sorry, the above comment was uname -a on the server. On the client, uname -a is "Linux spectrum 2.6.20-8-generic #2 SMP Tue Feb 13 01:14:41 UTC 2007 x86_64 GNU/Linux".
I'm not sure where rpc.idmapd needs to be running, but I have it running in both client and server.

Revision history for this message
Gustavo Carneiro (gjc) wrote :

I saw here a possible solution: http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=389557;msg=5

Although the suggested "--pidfile /var/run/rpc.idmapd.pid" didn't work, manually writing the pid file seems to work:

24176 ? Ss 0:00 /usr/sbin/rpc.idmapd
root@spectrum:~ # echo 24176 > /var/run/rpc.idmapd.pid
root@spectrum:~ # mount -tnfs4 ying64:/ /mnt/ying64/
 -> works!

Revision history for this message
Scott Henson (scotth) wrote :

Stupid question perhaps, but what is the content of your /etc/default/nfs-common file?

Revision history for this message
Gustavo Carneiro (gjc) wrote :

STATDOPTS=
NEED_LOCKD=
NEED_IDMAPD=yes
NEED_GSSD=no

Revision history for this message
Joseph Fannin (jfannin) wrote :

I'm seeing this too, with 1.0.11~git-20060105-2 (i.e. feisty).

I strace'd mount(8), and see that mount prints that warning just after failing to locate the file /var/run/rpc.idmapd.pid. The warning seems to be spurious -- rpc.idmapd is running, and I'm seeing the correct owners on the mounted NFSv4 share.

Gustavo, do the files on your own NFS mount have the correct owners?

Adding the --pidfile parameter to start-stop-daemon does make the error go away here, but it's necessary to pass --make-pidfile also.

This used to work, though -- mount only printed the message when rpc.idmapd was in fact not running.

I'm attaching a diff that demonstrates the change I made to /etc/init.d/nfs-common .

Revision history for this message
Luis Mondesi (lemsx1) wrote :

Please fix this. Remember to add --pidfile to the "stop" argument as well.

Revision history for this message
Sarazar (rcrook) wrote :

I ran the patch you suggested Joseph.. only issue is the pid that ends up in the pid file is always one out from the actual idmapd pid.

I am not sure why its doing it.
I added this just under the --exec line to get the real pid. just a temp solution till a proper patch shows.

ps -ef | grep idmapd | grep -v grep | awk ' { print $2} ' >/var/run/rpc.idmapd.pid

works for the moment. Just a suggestion.

Hope this helps someone.

Randall.

Revision history for this message
Wade Nelson (hollywoodb) wrote :

Experiencing this same bug on a fresh feisty install.

This is a pretty major bug, which deserves to be fixed. Editing /etc/init.d/nfs-common as mentioned above works.

Revision history for this message
Steinar H. Gunderson (sesse) wrote :

This is a bug in mount, not nfs-utils. The warning is simply bogus and should be ignored.

As others have pointed out, you can't just ask start-stop-daemon to make a pid file, since rpc.idmapd forks.
Thus, you end up with entirely the wrong pid, which makes "/etc/init.d/nfs-common start" fire up _another_
idmapd, and at that point things start to get all wrong.

/* Steinar */
(Debian nfs-utils maintainer)

Revision history for this message
Rolf Leggewie (r0lf) wrote :

still an issue?

Changed in nfs-utils:
assignee: nobody → r0lf
status: New → Incomplete
Revision history for this message
misi (misi-aaaa) wrote :

yes, still an issue, I have gutsy and modified the nfs-common script as follows:

                    log_progress_msg "idmapd"
                    start-stop-daemon --start --oknodo --quiet --pidfile /var/run/rpc.idmapd.pid --make-pidfile \
                            --exec /usr/sbin/rpc.idmapd

but no effect! Hovewer with or without the --pidfile invention, if I restart /etc/init.d/nfs-common manually after boot, activates the idmapd.

Revision history for this message
misi (misi-aaaa) wrote :

hehe.... I think I found the solution....

no need for --pidfile etc., leave the nfs-common script untouched and add

nfsd /proc/fs/nfsd nfsd defaults 0 0

to the /etc/fstab on the nfs server machine

Rolf Leggewie (r0lf) on 2008-02-24
Changed in nfs-utils:
assignee: r0lf → nobody
importance: Undecided → Medium
status: Incomplete → Triaged
Revision history for this message
DaveAbrahams (boostpro) wrote :

The Linux/NFSv4 people seem to think this is their bug and have accepted a patch to fix it:
http://linux-nfs.org/pipermail/nfsv4/2005-September/002615.html
http://linux-nfs.org/pipermail/nfsv4/2005-September/002618.html

For me, on Intrepid, misi's line in /etc/fstab does make the symptom go away. Misi, can you explain what that actually does?

Thanks,
Dave

Revision history for this message
DaveAbrahams (boostpro) wrote :

Sorry, that's the RedHat people, not the Linux/NFSv4 peeps.

Revision history for this message
Steve Langasek (vorlon) wrote :

This bug appears to be fixed in the version of nfs-utils in karmic; mounting nfs4 filesystems doesn't trigger any warnings about rpc.idmapd not running.

Changed in nfs-utils (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers