NFS share does not mount on boot using fstab

[CaptainPlanet]

What I expected to happen?

I want an NFS share to be mounted on startup using

192.168.178.66:/media/captainplanet/7EF8B26FF8B22575/ /media/captainplanet/banane/ nfs rw 0 0

What happened instead?

It does not mount on startup. Systemd waits 91sec instead and finally starts after failing.

I can successfully mount the NFS share with

sudo mount 192.168.178.66:/media/captainplanet/7EF8B26FF8B22575 /media/captainplanet/banane/

When I try to shutdown Xubuntu it hangs forever. Unmounting the NFS share manually before shutdown fixes the second problem.

Do you need more information?

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: systemd 229-4ubuntu4
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_modeset nvidia
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: XFCE
Date: Mon May 2 23:10:50 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-04-22 (10 days ago)
InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
MachineType: LENOVO 20DM003XUK
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-21-generic root=UUID=eece9973-0430-4a60-9291-9a994782bf86 ro quiet splash
SourcePackage: systemd
SystemdDelta:
 [EXTENDED] /lib/systemd/system/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
 [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf

 2 overridden configuration files found.
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/26/2015
dmi.bios.vendor: LENOVO
dmi.bios.version: JFET44WW(1.21)
dmi.board.asset.tag: Not Available
dmi.board.name: 20DM003XUK
dmi.board.vendor: LENOVO
dmi.board.version: SDK0E50512 STD
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrJFET44WW(1.21):bd08/26/2015:svnLENOVO:pn20DM003XUK:pvrThinkPadS3Yoga14:rvnLENOVO:rn20DM003XUK:rvrSDK0E50512STD:cvnLENOVO:ct10:cvrNone:
dmi.product.name: 20DM003XUK
dmi.product.version: ThinkPad S3 Yoga 14
dmi.sys.vendor: LENOVO

[CaptainPlanet (captainplanet)]

I just noticed the shutdown part of my bug description is not true (anymore). Maybe I got things mixed up or something changed during the last week. Anyway, the boot problem is alive and well.

[Launchpad Janitor (janitor)]

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

[Kelvin Middleton (kelvin-middleton)]

Have been plagued with this for a while now, noted that Debian tracked a similar issue (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746358) but the solution/scripting is different for ubuntu but could this be ported? Problem presents on every boot, I use the linux-bridge package to create a bridge for a kvm/qemu guest networks. NFS server is in my local network one physical hop from the client.

/etc/fstab contains:
192.168.1.2: /nfs/mnt/blacknas nfs defaults 0 0

Boot hangs for the 91 seconds trying to mount this, fails, completes the boot to desktop. Once on the desktop a 'sudo mount -a' the successfully mounts the nfs share. No issues on shutdown.

[Gunni (fgunni)]

I have similar problems with a cifs/smb mount sometimes.
Can not reliable reproduce this, but maybe adding lines to

/lib/systemd/system/remote-fs-pre.target

helps:

Wants=network-online.target
After=network-online.target

like stated here: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1429975

[Markus Birth (mbirth)]

This bug reappeared (with cifs/smb mounts in fstab) after upgrade to 17.10 "artful" for me. The fix in #5 worked just fine.

[Glenn J. Schworak (glenn-schworak)]

I am experiencing the exact same issue with a fresh install of Ubuntu 18.04. Five other machines on the same network with the same NFS mount are not experiencing the issue. Three are 18.04 but were upgraded from 14.04 or 16.04 and the other two are on 16.04 and were upgraded from 12.04 and will soon be upgraded to 18.04.

I have reinstalled 18.04 from scratch twice on the new box and each time the same issue happens. The NFS fails to mount using /etc/fstab.

The temporary fix is to use the crontab to mount shortly after boot.

[Adrian Cantrill (acantril)]

I have the same issue - installed version of 18.04 today and none of my NFS mounts happen at boot.

May 30 17:23:41 can-srv systemd[1]: mnt-docker.mount: Directory /mnt/docker to mount over is not empty, mounting anyway.
May 30 17:23:41 can-srv systemd[1]: Mounting /mnt/docker...
May 30 17:23:41 can-srv mount[834]: mount.nfs: Network is unreachable
May 30 17:23:41 can-srv systemd[1]: mnt-docker.mount: Mount process exited, code=exited status=32
May 30 17:23:41 can-srv systemd[1]: mnt-docker.mount: Failed with result 'exit-code'.
May 30 17:23:41 can-srv systemd[1]: Failed to mount /mnt/docker.

They work fine with a mount -a at login ... but i need them up before services start.

[Robert Dinse (nanook)]

This is affecting me as well but oddly not all hosts. One host will be problematic for a while then it will shift to another.

[Jason D. Kelleher (jdkelleher)]

Same issue here. NFS fails to mount at boot, but logging in and issuing a manual "mount -a" resolves until the next reboot.

It should also be noted that there's a significant delay on boot with nfs entries in fstab - need to time it, but ~1 minute.

Why issues with something as old/stable/boring as NFS?

[Jason D. Kelleher (jdkelleher)]

I should note this is impacting an image built from 16.04.4. Another image built from 16.04.1 is working fine.

Both have been pulled forward via apt dist-upgrade and their behaviors differ - concerning in it's own right.

[Jason D. Kelleher (jdkelleher)]

Quick update - switched to autofs as a workaround for this 16.04 issue.

That was fine until I ran 'apt upgrade' today. Now I get the following error:

root@chi:~# ls -la /vol/home/
ls: cannot access '/vol/home/': Too many levels of symbolic links
root@chi:~#

I'll be opening a new bug for autofs while considering a move back to Debian or a jump to CentOS.

If anyone is using autofs as a workaround for the systemd issue, be very careful with an apt upgrade.

[Jason D. Kelleher (jdkelleher)]

I did a little more testing and this looks to be specific to /home. Even mounting over /home (no linking) with autofs results in the same issue.

All autofs files as well as the list of packages installed have been attached.

As a side note, having /home as a link is an artifact of some very old build scripts and worked fine with an /etc/fstab NFS mount. autofs was deployed as a workaround for bug #1577575.

The new workaround for both these bugs is to update all /etc/passwd entries to /vol/home/<user>.

[Jason D. Kelleher (jdkelleher)]

Sorry - those last two comments were meant for bug #1827286.

[Dan Streetman (ddstreet)]

please reopen if this is still an issue