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