NFS share does not mount on boot using fstab

Bug #1577575 reported by CaptainPlanet on 2016-05-02
50
This bug affects 9 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Medium
Unassigned

Bug Description

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) wrote :
CaptainPlanet (captainplanet) wrote :

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.

summary: - NFS share does not mount on boot using fstab and does not unmount if
- mounted manually
+ NFS share does not mount on boot using fstab
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu):
status: New → Confirmed
Changed in systemd (Ubuntu):
importance: Undecided → Medium

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) wrote :

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) wrote :

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

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) wrote :

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) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.