Bug#739721: NFS shares are not automatically mounted during boot

Martin Apel martin.apel at simpack.de
Fri Oct 10 12:49:13 BST 2014


Hi,

I am experiencing the same problem as described in the bug report.
In my case I could generate the following, hopefully helpful output from 
systemctl:

    Loaded: loaded (/etc/fstab)
    Active: failed (Result: exit-code) since Fri 2014-10-10 13:13:15 
CEST; 22min ago
     Where: /home/home_dev
      What: lnxhomes-dev:/home_dev
      Docs: man:fstab(5)
            man:systemd-fstab-generator(8)
   Process: 1765 ExecMount=/bin/mount -n lnxhomes-dev:/home_dev 
/home/home_dev -t nfs -o defaults,soft,nfsvers=3 (code=exited, status=32)

Oct 10 13:13:15 debian64 rpc.statd[1793]: Version 1.2.8 starting
Oct 10 13:13:15 debian64 rpc.statd[1793]: Flags: TI-RPC
Oct 10 13:13:15 debian64 rpc.statd[1793]: failed to create RPC 
listeners, exiting
Oct 10 13:13:15 debian64 mount[1765]: mount.nfs: rpc.statd is not 
running but is required for remote locking.
Oct 10 13:13:15 debian64 mount[1765]: mount.nfs: Either use '-o nolock' 
to keep locks local, or start statd.
Oct 10 13:13:15 debian64 mount[1765]: mount.nfs: an incorrect mount 
option was specified
Oct 10 13:13:15 debian64 systemd[1]: home-home_dev.mount mount process 
exited, code=exited status=32
Oct 10 13:13:15 debian64 systemd[1]: Failed to mount /home/home_dev.
Oct 10 13:13:15 debian64 systemd[1]: Unit home-home_dev.mount entered 
failed state.

To me this looks like there's a missing dependency between mount and 
rpc.statd. Note that although the rpc.statd
output is before the mount output, it has a higher pid, which probably 
means, that it has been started after the mount command.

Hope this helps,

Martin Apel



More information about the Pkg-systemd-maintainers mailing list