Bug 457032

Summary: nfs mounts fail because rpc.statd is not started for non-root users
Product: [openSUSE] openSUSE 11.1 Reporter: Dr. Markus Ammer <markus.webmail>
Component: NetworkAssignee: Neil Brown <nfbrown>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None    
Version: RC 1   
Target Milestone: ---   
Hardware: x86   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Patch for /etc/init.d/nfs

Description Dr. Markus Ammer 2008-12-06 10:17:05 UTC
Trying to mount a nfs mount point I get

markus:~> mount /mnt/server/
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.

/etc/init.d/nfs says         
# remark: statd is started when needed by mount.nfs

but this obviously is not true for non-root users.
Comment 1 Matthias Koenig 2008-12-08 11:46:47 UTC
Works for me.
What's the content of your /etc/fstab?
Is /sbin/mount.nfs installed with SUID bit set (as it should by default)?
ls -l /sbin/mount.nfs
Comment 2 Dr. Markus Ammer 2008-12-08 17:15:38 UTC
~ >la /sbin/mount.nfs
-rwsr-xr-x 1 root root 88656 Nov 22 12:10 /sbin/mount.nfs

This is ok.

My /etc/fstab (nfs mount points only)

insp9400:/media/extdisk /media/extdisk  nfs     noauto,user,exec,async
dataserv:/srv/nfs       /mnt/server     nfs     noauto,user,exec,async

Note there are only "noauto" nfs entries. Thus /etc/init.d/nfs says
"Not starting NFS client services - no NFS found in /etc/fstab:     unused"

Of course, after root has mounted a nfs point, a regular user can follow without problems. 

I have modified /etc/init.d/nfs (see patch).
Comment 3 Dr. Markus Ammer 2008-12-08 17:16:46 UTC
Created attachment 258699 [details]
Patch for /etc/init.d/nfs
Comment 4 Matthias Koenig 2008-12-08 17:57:30 UTC
Since mount.nfs is SUID it starts rpc.statd even for a regular user. If this does not work, the reason must be somewhere else.
A possible cause might be that rpcbind is not running for some reason.
What is the output of 
chkconfig rpcbind

Comment 5 Dr. Markus Ammer 2008-12-08 19:30:12 UTC
rpcbind is running:

vmw-sl-111-cl2:~ # chkconfig rpcbind
rpcbind  on
vmw-sl-111-cl2:~ # ps aux | grep rpc
root      2578  0.0  0.1   2316   780 ?        Ss   19:34   0:00 /sbin/rpcbind
root      4585  0.0  0.1   2200   600 tty1     S+   19:39   0:00 grep rpc

But what I have found:

/var/log/messages (when trying a nfs mount as regular user)
Dec  8 19:36:30 vmw-sl-111-cl2 rpc.statd[3771]: Version 1.1.3 Starting
Dec  8 19:36:30 vmw-sl-111-cl2 rpc.statd[3771]: Flags:
Dec  8 19:36:30 vmw-sl-111-cl2 rpc.statd[3771]: Opening /var/run/rpc.statd.pid failed: Permission denied       <<<<<<<<<<<<<< ?

/var/log/messages (nfs mount as root)
Dec  8 19:40:05 vmw-sl-111-cl2 rpc.statd[4595]: Version 1.1.3 Starting
Dec  8 19:40:05 vmw-sl-111-cl2 rpc.statd[4595]: Flags:
Dec  8 19:40:06 vmw-sl-111-cl2 rpc.statd[4595]: statd running as root. chown /var/lib/nfs/sm to choose different user
Dec  8 19:40:06 vmw-sl-111-cl2 kernel: RPC: Registered udp transport module.
Dec  8 19:40:06 vmw-sl-111-cl2 kernel: RPC: Registered tcp transport module.

vmw-sl-111-cl2:~ # la -d /var/run/
drwxr-xr-x 23 root root 4096 Dec  8 19:40 /var/run/
vmw-sl-111-cl2:~ # la /var/run/rpc.statd.pid
-rw-r--r-- 1 root root 5 Dec  8 19:40 /var/run/rpc.statd.pid


Just to test I've tried (after reboot, no rpc.statd running)
chmod 777 /var/run

nfs mount as regular user fails again, but now there is a empty pid file 
owned by me. 

vmw-sl-111-cl2:~ # la -d /var/run/rpc.statd.pid
-rw-r--r-- 1 markus users 0 Dec  8 20:16 /var/run/rpc.statd.pid

/var/log/messages:
Dec  8 20:16:05 vmw-sl-111-cl2 rpc.statd[4801]: Version 1.1.3 Starting
Dec  8 20:16:05 vmw-sl-111-cl2 rpc.statd[4801]: Flags:
Dec  8 20:16:05 vmw-sl-111-cl2 rpc.statd[4801]: unable to register (statd, 1, udp)

Seems mount.nfs is not switching to root.
Comment 7 Neil Brown 2008-12-09 12:05:14 UTC
This was fixed just too late for -rc1.
It will be fixed in the next -rc.

Thanks for the report


*** This bug has been marked as a duplicate of bug 447812 ***