NFS shares in FSTAB no longer mount at boot

Bug #1385846 reported by Toxicshadow
260
This bug affects 50 people
Affects Status Importance Assigned to Milestone
nfs-utils (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Since moving to Ubuntu 14.10 my network shares in FSTAB no longer mount at startup.

Once the machine has booted the following command "mount -a" fixes the issue and all mounts become available.

This issue was not present in 14.04 and there are a number of people reporting issues in the forums:

http://ubuntuforums.org/showthread.php?t=2249713
---
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: toxicshadow 2543 F.... pulseaudio
 /dev/snd/controlC0: toxicshadow 2543 F.... pulseaudio
CurrentDesktop: Unity
DistroRelease: Ubuntu 14.10
HibernationDevice: RESUME=UUID=0b094f80-5aff-43e5-a66c-100a4274a339
InstallationDate: Installed on 2014-04-18 (190 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
IwConfig:
 eth0 no wireless extensions.

 eth1 no wireless extensions.

 lo no wireless extensions.
MachineType: System manufacturer System Product Name
NonfreeKernelModules: nvidia
Package: linux (not installed)
ProcFB: 0 VESA VGA
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-23-generic root=UUID=73d2e3f6-f93f-4bd2-9f69-be107307daef ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.16.0-23.31-generic 3.16.4
RelatedPackageVersions:
 linux-restricted-modules-3.16.0-23-generic N/A
 linux-backports-modules-3.16.0-23-generic N/A
 linux-firmware 1.138
RfKill:

Tags: utopic
Uname: Linux 3.16.0-23-generic x86_64
UpgradeStatus: Upgraded to utopic on 2014-10-24 (1 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 09/19/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2101
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: Rampage II Extreme
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 2.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2101:bd09/19/2011:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnRampageIIExtreme:rvrRev2.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

Revision history for this message
Toxicshadow (7oxicshadow) wrote :
Revision history for this message
Toxicshadow (7oxicshadow) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1385846

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Toxicshadow (7oxicshadow) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected utopic
description: updated
Revision history for this message
Toxicshadow (7oxicshadow) wrote : BootDmesg.txt

apport information

Revision history for this message
Toxicshadow (7oxicshadow) wrote : CRDA.txt

apport information

Revision history for this message
Toxicshadow (7oxicshadow) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Toxicshadow (7oxicshadow) wrote : Lspci.txt

apport information

Revision history for this message
Toxicshadow (7oxicshadow) wrote : Lsusb.txt

apport information

Revision history for this message
Toxicshadow (7oxicshadow) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Toxicshadow (7oxicshadow) wrote : ProcEnviron.txt

apport information

Revision history for this message
Toxicshadow (7oxicshadow) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Toxicshadow (7oxicshadow) wrote : ProcModules.txt

apport information

Revision history for this message
Toxicshadow (7oxicshadow) wrote : PulseList.txt

apport information

Revision history for this message
Toxicshadow (7oxicshadow) wrote : UdevDb.txt

apport information

Revision history for this message
Toxicshadow (7oxicshadow) wrote : UdevLog.txt

apport information

Revision history for this message
Toxicshadow (7oxicshadow) wrote : WifiSyslog.txt

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Troy Dack (troy-d) wrote :

Looks like https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1384502 might be relevant to this bug as well.

FWIW this has bitten me too.

Looking at dmesg idmapd is called for each mount point in /etc/fstab and then killed (TERM), this all appears to happen _before_ the network interfaces are brought up.

[ 15.427560] FS-Cache: Loaded
[ 15.537262] RPC: Registered named UNIX socket transport module.
[ 15.537270] RPC: Registered udp transport module.
[ 15.537273] RPC: Registered tcp transport module.
[ 15.537276] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 15.701313] FS-Cache: Netfs 'nfs' registered for caching
[ 15.994166] Installing knfsd (copyright (C) 1996 <email address hidden>).
[ 16.654672] init: idmapd-mounting (/storage/videos) main process (358) killed by TERM signal
[ 16.656498] init: idmapd-mounting (/storage/music) main process (360) killed by TERM signal
[ 16.659974] init: idmapd-mounting (/storage/downloads) main process (362) killed by TERM signal
[ 16.661613] init: idmapd-mounting (/storage/pictures) main process (364) killed by TERM signal
[ 16.663178] init: idmapd-mounting (/storage/ebooks) main process (366) killed by TERM signal
[ 16.665076] init: idmapd-mounting (/storage/www) main process (368) killed by TERM signal
[ 16.666773] init: idmapd-mounting (/storage/school) main process (370) killed by TERM signal
[ 18.185315] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 18.196591] r8169 0000:02:09.0 eth1: link down
[ 18.196618] r8169 0000:02:09.0 eth1: link down
[ 18.196692] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 19.784427] r8169 0000:02:09.0 eth1: link up
[ 19.784444] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 21.167763] tg3 0000:01:00.0 eth0: Link is up at 1000 Mbps, full duplex
[ 21.167779] tg3 0000:01:00.0 eth0: Flow control is on for TX and on for RX
[ 21.167809] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

For now I've added /bin/mount -a -t nfs to /etc/rc.local

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.18 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-rc2-utopic/

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
Revision history for this message
Peter Smith (ubuntu-forums) wrote :

Just to note to add that this also affects autofs.

Manually mounting works O.K.

Peter

tags: added: kernel-unable-to-test-upstream
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Toxicshadow (7oxicshadow) wrote :

Attempted to test the upstream kernel but this resulted in what appeared to be a shell with a comment of "Gave up waiting for root device"

The keyboard also stopped responding.

I installed the following packages:

linux-image-3.18.0-031800rc2-generic_3.18.0-031800rc2.201410262035_amd64.deb
linux-headers-3.18.0-031800rc2_3.18.0-031800rc2.201410262035_all.deb
linux-headers-3.18.0-031800rc2-generic_3.18.0-031800rc2.201410262035_amd64.deb

Recovered using Grub

Revision history for this message
Francois Gouget (fgouget) wrote :

I have run into this issue too. In case it helps anyone else, the workaround I came up with is to:
* Use the NFS server's IP address in /etc/fstab.
* Add 'mount -a' in the first non-comment line of /etc/init.d/mountnfs.sh. Note that it is important to call 'mount -a' before the '. /lib/lsb/init-functions' line as this script does not make it past that line.

Further notes:
* This script seems to be only concerned with mounting some /usr or /var mountpoints so it's probably nt supposed to mount my NFS filesystem which lies elsewhere. Still, it being run at about the right time which is all I care about for this gross hack.
* Resolving hostnames does not seem to work when that script is run, hence the need to use the IP address in fstab. That could be a problem if anyone was actually depending on that script to mount stuff.
* This script seems broken: it calls fstab_files which does not seem to be defined anywhere, resulting in running ls without parameters which obviously is not what's expected.

Revision history for this message
Dwaine Gonyier (dgonyier) wrote :

I am also seeing this affecting autofs. Same host, automounts under /net worked fine under 14.04, but do not work after upgrading the same host to 14.10

Revision history for this message
Dwaine Gonyier (dgonyier) wrote :

As a temporary workaround for automounts/autofs for NFS mounts that seems to work, I added the following to /etc/auto.master:

/nfs /etc/auto.net

So now I can access NFS automounts under /nfs rather that under /net which was working in 14.04 and earlier.

Revision history for this message
Dwaine Gonyier (dgonyier) wrote :

See Bug #1386869 for autofs issue and work around. I think there are two issues, one affecting autofs and one affecting NFS mounts via FSTAB at boot as described in original bug text here.

Revision history for this message
Forage (forage) wrote :

The issue appears to be fixed now. I didn't apply any work-arounds and the shares get auto-mounted again.

Possibly because of the recent nfs-common 1:1.2.8-9ubuntu1 or the linux 3.16.0-24 update?

Revision history for this message
Jens Jäschke (brokenphysics) wrote :

I can confirm that the issue seems to be fixed.
Since I first noticed it being fixed today, I assume the nfs-common update is responsible which was installed yesterday.

Sifr Moja (simplexion)
Changed in linux (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
guillaume ramelet (guillaume-ramelet) wrote :

I have nfs-common 1:1.2.8-9ubuntu1, kernel 3.16.0-25-generic and the bug is not fixed for me.

Here is my fstab entry for nfs:
nas:/volume1/homes/guillaume /home/guillaume/Nas/Home nfs defaults,user,nolock,nfsvers=4 0 0

Revision history for this message
Forage (forage) wrote :

@guillaume: my apologies for the confusion. The correct version should be nfs-common 1:1.2.8-9ubuntu1.1 (and linux 3.16.0-25.33 for that matter).
Make sure you enabled the "Recommended updates (utopic-updates)" repository in "Software & Updates" on the "Updates" tab if you did not get this update.

Revision history for this message
guillaume ramelet (guillaume-ramelet) wrote :

@forage : thanx, fixed with nfs-common 1:1.2.8-9ubuntu1.1

Sifr Moja (simplexion)
affects: linux (Ubuntu) → nfs-utils (Ubuntu)
Revision history for this message
Guillaume LAURENT (laurent-guillaume) wrote :

Seems fixed too after updates.

Revision history for this message
Dagur (dagurp) wrote :

This bug seems to have returned in 15.04. At least for me

Revision history for this message
Dagur (dagurp) wrote :

Actually I think has been already fixed. Ignore last comment

Revision history for this message
lnxusr (bjwest) wrote :

This needs to be reopened. I just installed 15.10 yesterday, and my nfs shares no longer mount on boot. I believe this was happening even before updating to 4.2.0.18, but I updated immediately before checking the system out, so can't be sure.

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1385846] Re: NFS shares in FSTAB no longer mount at boot

On Wed, Nov 11, 2015 at 09:24:01PM -0000, lnxusr wrote:
> This needs to be reopened.

Please file a separate bug report for your issue.

Revision history for this message
John Bradshaw (john-johnbradshaw) wrote :

Looks like 14.04 LTS Server isn't getting the nfs-common 1:1.2.8-9ubuntu1.1 package.
Latest package for LTS is 1:1.2.8-6ubuntu1.2 - we're running that and had this problem today.

Could we have this fix pushed out to LTS packages please?

Revision history for this message
Staten O. (toon0) wrote :

After a recent upgrade on 14.04 LTS Desktop, I am having this issue. It just started happening, whereas it wasn't happening before. The following from Bug #1227585 comment #7 is a valid workaround for me...

sudo su
crontab -e

put to crontab line:

@reboot /bin/sleep 60 ; /bin/mount -a

save crontab and reboot

It would be nice not to have to do this though especially when it was not needed at first.

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

Other bug subscribers

Remote bug watches

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