rpc.statd not started automatically

[Christophe Lyon]

Hello,

I've noticed that if my NFS mounts do not have the 'auto' option, rpc.statd does not start automatically, without a password.

When I try to mount the share, I'm prompted for the sudo password, in order to start rpc.statd:

> Authentication is required to start 'rpc-statd.service'.

If the current user does not know the password, he cannot start rpc.statd and thus cannot mount the share.

Here is a sample session:
$ mount /media/xxx
[a popup window opens to prompt for a password, choose "cancel"]
Failed to start rpc-statd.service: Access denied
See system logs and 'systemctl status rpc-statd.service' for details.
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.
mount.nfs: an incorrect mount option was specified

/var/log/syslog contains:
Sep 17 20:22:41 mcqueen rpc.statd[5160]: Opening /run/rpc.statd.pid failed: Permission denied

$ systemctl status rpc-statd.service
● rpc-statd.service - NFS status monitor for NFSv2/3 locking.
   Loaded: loaded (/lib/systemd/system/rpc-statd.service; enabled; vendor preset
   Active: inactive (dead)

/etc/fstab entry:
192.168.0.5:/volume1/documents /media/xxx nfs user,noauto 0 0

Of course, if I enter the sudo password, or if I manually start rpc.statd as root before trying to mount, the mount operation succeeds.

Similarly, if I replace "noauto" with "auto", rpc.statd is started during the boot sequence, and everything works.

Yet, I'd expect that any user be able to mount this share, since it has the "user" option.

Problem currently noticed with ubuntu 16.04.

nfs-common:
  Installed: 1:1.2.8-9ubuntu12
  Candidate: 1:1.2.8-9ubuntu12
  Version table:
 *** 1:1.2.8-9ubuntu12 500
        500 http://fr.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Paul (heipa)]

Possibly connected to this bug: https://bugs.launchpad.net/ubuntu/+source/rpcbind/+bug/1558196 ?

The proposed solution (systemctl add-wants multi-user.target rpc-statd.service) does not work for me.

[Christophe Lyon (christophe-lyon)]

FWIW, I'm *not* using NIS (as is the case in https://bugs.launchpad.net/ubuntu/+source/rpcbind/+bug/1558196 referenced above.

[Paul (heipa)]

Neither do I, but part of the problem in that bug was the rpc.statd service (and rpcbind) not working as well.
I found that bug because it was mentioned a number of times on the web as the solution to the exact problem we have here.

[Mark Wagner (x-mark)]

The systemd unit erroneously thinks that only NFS servers need rpc.statd. Try this fix:

sudo cp /lib/systemd/system/rpc-statd.service /etc/systemd/system/
echo "WantedBy=nfs-client.target" | sudo tee -a /etc/systemd/system/rpc-statd.service
sudo systemctl reenable rpc-statd.service
sudo systemctl restart rpc-statd.service

This only needs to be done once.

[Mark Wagner (x-mark)]

The second line got wrapped on the "-". "statd.service" should be part of it.

[Christophe Lyon (christophe-lyon)]

This worked, thanks!

Is there going to be a package update or should I manually apply this to all my machines?

[Mikhail Novosyolov (mikhailnov)]

I confirm this bug on 16.04 , the workaround works, thank you...