rpc.idmapd not working

[Gustavo Carneiro]

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

[Cristian Aravena Romero (caravena)]

$uname -a ?

[Gustavo Carneiro (gjc)]

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

[Gustavo Carneiro (gjc)]

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.

[Gustavo Carneiro (gjc)]

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!

[Scott Henson (scotth)]

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

[Gustavo Carneiro (gjc)]

STATDOPTS=
NEED_LOCKD=
NEED_IDMAPD=yes
NEED_GSSD=no

[Joseph Fannin (jfannin)]

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 .

[Luis Mondesi (lemsx1)]

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

[Sarazar (rcrook)]

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.

[Wade Nelson (hollywoodb)]

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.

[Steinar H. Gunderson (sesse)]

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)

[Rolf Leggewie (r0lf)]

still an issue?

[misi (misi-aaaa)]

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.

[misi (misi-aaaa)]

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

[DaveAbrahams (boostpro)]

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

[DaveAbrahams (boostpro)]

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

[Steve Langasek (vorlon)]

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.