nfs mounts specified in fstab is not mounted on boot.

Please specify what version of Ubuntu you are using, and the concerned version of the sysvinit package (if you are sure that the bug is with this package).

this is for Ubuntu intrepid

Well I noticed the problem before

https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/270158

it's some type of race in the boot sequence.

adding
ASYNCMOUNTNFS=no
to
/etc/default/rcS
makes it work again. real problem is probably in
 /etc/init.d/mountnfs.sh
or even more likely it should be run as port of ifup
/etc/network/if-up.d/mountnfs

thats not being run or it's run to early or something.

> I have the home directory mounted over NFS by listing it in /etc/fstab. has been working fine up until a few days ago.
I've the same problem too -> still up to now (with 8.10 beta). I couldn't fix it, so I've every time to mount the NFS dirs by shell.

I have this problem too. However, adding ASYNCMOUNTNFS=no to /etc/default/rcS did not help. Running 8.10.

I'm on Jaunty alpha and I also have this problem.

I tried adding ASYNCMOUNTNFS=no but that had no effect.

I noticed that you actually get an error message in the boot process. The try to mount is clearly done before the network i started. I will try to halt the boot and write down the error (since it's not recorded in any file).

Also found bug #46516 which seems to have been the same problem but it got fixed. Probably something has regressed since.

The error reads something like this:

mount.nfs: DNS resolution failed for 192.168.0.113: name or service unknown

Same problem. This problem has only emerged since Intrepid as I never had this problem with the previous versions. Sudo mount -a works after boot every time, so presumably the network is not available during boot. I have tried re-installing Intrepid but this has not helped.

How is your network configured ?

You should probably be using static system-wide network definition (/etc/network/interfaces) if you want the network to be up in time for the NFS mounts (and network services) to start correctly... If you're using NetworkManager or any other session-related network-handling tool, then the network won't be up until at least someone logs in...

Please attach your /etc/network/interfaces file to this bug.

I'm using NetworkManager (interfaces is empty).

I guess I have to disable NM and go back to using config in /etc/network/interfaces.

If you were to run the mountnfs.sh script as the last script + mount with a long timeout, would that also work?

Thomas: I don't think it would work (at least not in all cases) as the network goes up only when the session is joined. At that point you should definitely avoid using network-manager if you want to mount filesystems at boot. The alternative would be to use gvfs network filesystem access from inside Gnome.

Could the other reporters confirm that they are also trying to mount network filesystems from a NetworkManager-managed network ? If so, I would close this as wontfix since it fails by design.

Forgive my complete ignorance, but I am not sure what you mean by NetworkManager managed network. The NetworkManager applet has been operational for as far back as I can remember and as I said, nothing has changed from my end (from Feisty onwards) except the OS version. In other words, mounting from /etc/fstab worked right up until Intrepid came along.

epicurea: if your network is defined in /etc/network/interfaces, then it's not handled by NetworkManager. In doubt, please attach your /etc/network/interfaces file.

@epicurea: IIRC network for wired interfaces were configured in /etc/network/interfaces in Hardy and past versions.

If you manage your interface from there instead it will probably work. Something like:

auto eth0
iface eth0 inet dhcp

(if you get your IP-address from a DHCP server)

Good day! I am experiencing this same issue. I am currently performing a diskless client boot and the home directory located on a NFS filesystem is not being mounted automatically. when FSTAB is parsed by /etc/rcS.d/S45mountnfs.sh.

I can however, perform a mount -a, and the NFS filesystem is mounted.

If I remove the symlink /etc/rcS.d/S45mountnfs.sh and replace it with /etc/network/if-up.d/mountnfs my home directory is automatically mounted.

I am using Ubuntu 9.04 (Jaunty Jackalope) beta for the amd64 architecture.
I am not using NetworkManager to manage my interface, as I am booting diskless and NetworkManager would interfere with the process.
sysvinit: 2.86.ds1-61ubuntu11
uname -r: 2.6.28-11-server

I just upgraded from intrepid to jaunty and began seeing the same problem: NFS mounts are not performed at boot time but mount -a does mount them without a problem.

It seems that sysvinit is not installed. The relevant part of my /etc/network/interfaces is

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1

and the fstab line is

192.168.1.3:/unixhome /home nfs,auto bg

Setting ASYNCMOUNTNFS=no doesn't help.

I had the same issue on my daughters PC after upgrading from 8.04 to 8.10 then to 9.04. I did not test between upgrades so the fault may have started at 8.10.

During 1 of the upgrades it gave an option to use my custom dhcp.conf or a new one, I chose new.

On the first test after the final upgrade.
I found that none of the roaming profile accounts could login, unable to find /mnt/home/user
I then logged in with a local account and found that the NFS mount had not mounted. mount -a worked.

My solution was to backup /etc/network/interfaces then delete the originals.
Then in the NetworkManager Applet I setup a static IP.
rebooted, tested roaming accounts, now able to login.

Ram

Thierry Carrez: Sorry for the disappearing act - have been very busy. The lines in /etc/network/interfaces used to read:

auto lo
iface lo inet loopback

Following ThomasNovin's suggestion, I backed up the original file and replaced its contents with:

auto eth0
iface eth0 inet dhcp

Rebooting after this does not fix the problem. I cannot setup a static IP and must use DHCP as this machine is at work.

Any ideas?

I'm having the same problem in Jaunty - NFS not mounting on boot. It's a wireless connection - the relevant part of /etc/network/interfaces is

auto wlan0
#iface wlan0 inet dhcp

Am I understanding correctly that if I uncomment that line the NFS mount at boot may work properly?

@epicurea:
"Rebooting after this does not fix the problem": you mean you don't get a DHCP address for eth0 ? Or that you get an address but NFS still doesn't mount at boot ?

@COD:
The problem with wireless is that the connection is usually tied up to user-level data (AP to connect to, passwords...) that NetworkManager handles for you. I'm just not sure that in your case uncommenting the iface line will be sufficient.

@Thierry Carrez:
I do get a DHCP address, but the NFS still does not mount. sudo mount -a still works of course.
Thanks

rudd-o@manuel-desktop:~$ grep nfs /etc/fstab
192.168.2.254:/var/shared/Entertainment/Music /media/music nfs ro,bg,soft 0 0

fails to mount on boot.

the trick is to KILL networkmanager and let the default system networking init.d script take over. if networkmanager is the one bringing up the network interface, the mountnfs.sh script never gets run.

sudo update-rc.d -f NetworkManager remove
sudo update.rc-d -f networking remove
sudo update.rc-d -f networking defaults

then reboot. or service stop networkmnager and service start networking. presto, filesystem is automounted.

this is a bug in the networkmanager package, it's not picking up system ifup / ifdown hooks. that's it.

Thank you, Rudd-O. I was going nuts about this. :)

This bug caused a hang on shutdown as well here. No fun ... but finally solved.

I am having this exact problem as well. Unfortunately rudd-o's fix is not working for me.

Interestingly enough, I have two identical machines, and one is running an exact image of the other's install of ubuntu 9.04 that was cloned onto another SATA flash module using dd. The initial machine works fine, the one using an image of the first install does not. I have cloned the install onto another third flash module, and this one is doing the same thing.

I have noticed that on the one that this does not occur on, network manager icon shows wired network not managed, however the network connection works flawlessly. The images of that install when used on the other machine show an auto configured interface in the network manager icon.

For now I am going to place mount -a in rc.local as that seems to resolve the issue.

Just to add some more information to this:

mount -a works when I run it manually, however it does not work when added to crontab or in rc.local (even with sleep 10 preceding it)

I have three of these identical computers. The operating system install/configure was done on one of them, and then imaged onto the flash storage devices for the others.

Currently I can put any of the flash modules in the original workstation, and there are no nfs mount on boot issues.

When placed into one of the other workstations however, this bug seems to pop up. I have tried many fixes for the many "versions" of this bug that I have found online, however I am unable to get nfs mounts to work on boot with two of these machines even when using an install that works in another machine. Investigating this server side at the moment, but I do not understand how that could be the issue as mount -a works fine every time.

Thanks,
Derrick

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.04
DISTRIB_CODENAME=jaunty
DISTRIB_DESCRIPTION="Ubuntu 9.04"

Linux rambc 2.6.28-14-generic #47-Ubuntu SMP x86_64 GNU/Linux

Terminal server using Ubuntu Desktop install

I have found this bug to exist on a server that was upgraded from 7.04 directly to 9.04 (in steps). The problem was noticed after the upgrades were finished (the system was barely used in between upgrades). System is very customized as it is a terminal server. I have a LUN copy of the original 7.04 machine running on a blade if comparison is needed.

The problem appears to possibly be DNS related, but is definitely a race at boot. I use /etc/network/interfaces to hard code the static IP to the network interface (NetworkManager not installed). The NFS mount points were and still are in /etc/fstab, exactly has they have been (no change in upgrade). The NFS mounts use the server name via DNS to mount. The /proc/mounts does not show traces of "half mounted" filesystems.

If I put the NFS server name in /etc/hosts, the filesystems will automatically mount.
If I remove the NFS server name from /etc/hosts, the filesystems will not mount.
Adding "mount -a" in /etc/rc.local does not work.
Adding individual mount commands in /etc/rc.local does not work.

If I wait until the system is fully booted, "mount -a" will work.

Lines from /etc/fstab are pretty normal (all on one line, broken for ease of sight):
nas-03:/u64dev-s
  /home/shared nfs rw,rsize=8192,wsize=8192,hard,intr,timeo=14,bg 0 0
nas-03:/PSExport-ACCT
 /home/shared/PSExport/ACCT nfs rw,rsize=8192,wsize=8192,hard,intr,timeo=14,bg 0 0
nas-03:/PSExport-HR
 /home/shared/PSExport/HR nfs rw,rsize=8192,wsize=8192,hard,intr,timeo=14,bg 0 0

Line required in /etc/hosts contains an IP for "nas-03". This kludge is highly not preferred.

Lines from /etc/network/interfaces (munged):
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.11.12.20
netmask 255.255.255.0
gateway 10.11.12.1

This bug will very soon be affecting us on another 17 servers, all being upgraded from v6.06 and v7.04 to v9.04. Hard coding multiple DNS entries will cause massive loss of hair and years off life. Not now, and possibly not for me, but someone at some random point in the future.

Running the current release of Ubuntu 9.04, a few weeks ago I began having the same problem described here where my system stopped automatically mounting my NAS drive during a system boot (manually mounted using 'sudo mount -a). I use the following line in fstab.

//192.168.0.9/Volume_1 /media/NAS-Shared cifs credentials=/root/.smbcredentials,iocharset=utf8,file_mode=0777,dir_ mode=0777 0 0

After much research I came to this bug report where I read 'Network Manager' could have something to do with this problem. A few weeks earlier I switch from 'Network Manager' to 'Wicd' and after switching back to 'Network Manager', I re-booted my system and my NAs drive is automatically mounted. Thanks for your help in resolving my problem and I hope this gives you another piece of the solution puzzle.

I am interested to know if adding 'sleep 45' before 'mount -a' in rc.local will work for EmonkIA....

At first I was under the assumption that it wasn't working with mount -a in rc.local. As I am under the impression that the boot sequence has changed, I was wondering if rc.local was also affected. To test this I added 'sleep 10' before 'mount -a' in rc.local, which did not work. I stepped this up in 5second increments until I landed at 'sleep 45' which allows the rc.local script time for the network to be loaded before attempting the mount. This arrangement works on one out of my three identical workstations I am testing this with.

On one of the other workstations a simple 'sleep 10' before 'mount -a' in rc.local worked, as someone referenced in either this or one of the other bug reports on this issue.

I haven't tried a "sleep 45" in rc.local, but I am sure it, or something within 120 seconds would work. I can ssh into the server just as the daemon comes up and do "mount -a", as it works fine by then. I'd hate to put another delay in the boot, as it already has to time-out 2x for QLogic boards (2 minutes!) since Ubuntu's kernel package refuses to load add firmware to initrd (and I refuse to tinker it when it could easily be "fixed" with auto loading firmware as detected, we all have decent/large size /boot fs anyway).
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/328550

Anyway, I know the network is running fine, as the /etc/hosts hack works around this bug. The problem appears to be with mountnfs.sh not knowing DNS isn't up, or something along that line. Kinda reminds me of the NFS automount issue I had in v6.06 (only first NFS in fstab would mount at boot, it ignored all others).

This is just one server connecting to a single NAS NFS share. I have 18 servers using 4 NAS servers and one Ubuntu file server. It is going to get real ugly if I have to hack all of them. Ugly as in, don't move anything to new IPs..

I'd call Canonical for support, but we dropped it last year.

I'm new to this forum, so please bear with me.

My NFS mounts broke with Jaunty Jackalope. I tried all the tips above, but none worked.

Instead, I looked at Network Administrator and noticed that for my wired connection, ROAMING PROFILES was enabled.

My laptop doesn't roam, so I replaced roaming with DHCP and re-booted.

My NFS shares are now mounted automagically!

I'm experiencing the same problem with 9.04.
NFS doesn't mount on boot.
My boot sequence looks like this:

* Mounting local file systems... [OK]
* Activating swapfile swap... [OK]
* Configuring network interfaces... [OK]
* Starting portmap daemon... [OK]
* Starting NFS common utilities [OK]
* Waiting for /var/www... [fail] <-before it writes fail, system waits for a few sec.
* Waiting for (bunch of other nfs mounts) [fail]
* Settings up console font and keymap... [OK]

After that, system boots up normally.

Seems to be working ok as of today - possibly some updates fixed it, though I wouldn't know which.

Another option I learned while researching this, add a line to crontab to "mount -a" at reboot. I am using 'Scheduled Task' app to do this now and at least I now get my NAS drive to mount whenever I boot up. Still doesn't want to mount when logging off/on though. JohnL

'mount -a' in cron on boot is not really an option but a dirty workaround for a broken system. :(
It's supposed to be mounting on bootup...that's why there are startup scripts for it.

epicurea(#33), i just rebooted one of my servers with all the latest updates and it's still not mounting.

I concur but it beats having to run 'mount -a' from a terminal after each sys boot. I really find it hard to believe this problem has persisted for so long. Apparently the BUG approach has not been successful. I wonder if a fix is included in the 100 paper cut initiative?

#MxxCon - I was pretty skeptical myself after all it has not been working for a while and I have not really changed anything much. Except perhaps for explicitly defining the location of my credentials file (it was in home but it may be possible it was not picking it up at boot). So just to be clear, my fstab entries now look like the following:

//server.name/share /smb/somefolder smbfs auto,credentials=/home/username/smbcredentials,uid=XXX,gid=XXX,umask=000 0 0

Whereas previously they looked like:

//server.name/share /smb/somefolder smbfs auto,credentials=smbcredentials,uid=XXX,gid=XXX,umask=000 0 0

But I can confirm that it is definitely working now.

On Thu, 2009-08-13 at 06:02 +0000, Havard Bjastad wrote:

> ** Also affects: hundredpapercuts
> Importance: Undecided
> Status: New
>
I would not say that this is a paper cut.

Working on fixing this problem has been a multi-year effort so far, with
at least a year more of development to go.

Boot ordering is a fundamentally hard problem, and we're having to strip
everything back and re-engineer things from scratch.

Scott
--
Scott James Remnant
<email address hidden>

as per comment #38

epicurea:

> Except perhaps for explicitly defining the location of my credentials file
> ...
> //server.name/share /smb/somefolder smbfs auto,credentials=/home/username/smbcredentials,uid=XXX,gid=XXX,umask=000 0 0
> Whereas previously they looked like:
> //server.name/share /smb/somefolder smbfs auto,credentials=smbcredentials,uid=XXX,gid=XXX,umask=000 0 0

This bug, as I have seen it, is specifically NFS related.

Your SMB fix very well might have been adding a fully qualified file name for your credentials.

I still believe it is a race between NFS and domain name resolution. In my case, it is using other servers' DNS. A background mount flag will fail, but I might try a foreground, just in case it makes a difference.

Scott, If this is such a significant and fundamental problem, how come it's not affecting every single ubuntu installation out there? or are we the only ones to report it?

I would imagine something like this should be relatively simple to diagnose(not necessary fix) to pinpoint why exactly nfs mount on boot fails?

On Thu, 2009-08-13 at 17:56 +0000, MxxCon wrote:

> Scott, If this is such a significant and fundamental problem, how come
> it's not affecting every single ubuntu installation out there? or are we
> the only ones to report it?
>
Because very few people actually use NFS?

Scott
--
Scott James Remnant
<email address hidden>

I use NFS on a number of computers, all running Jaunty, but only one of them has this problem...

This is weird...
Today i cloned my install of ubuntu that was having problem into 2nd vm and it was able to mount nfs w/o any problems...
2 identical VMs...one can mount nfs, the other can't :/

I'm having the same problem in Karmic Alpha 6. It worked perfectly on the same machine in Jaunty. DNS resolution is failing even though all my hosts are in /etc/fstab

to //mark Greewood. Try upgrading your existing install. Out of three systems I maintain, the two upgraded one work but mine was a fresh install fails. jwillar

I experienced the problem after cloning a system: With the 1st system, everything works fine. After creating an identical clone the network mounts were missing. The good news is that after quite some hours of searching I could track down and resolve the problem. The basic cause is that the clone's NIC obivously has a different MAC address. This created a new entry eth1 in /etc/udev/rules.d/70-persistent-net.rules. In /etc/network/interfaces only eth0 was listed which still used the old MAC. As a consequence the NetworkManager created an entry for eth1 but this obviously starts too late during boot to restore the mounts.
The following helped to get rid of the problem on the clone: (1) edit /etc/udev/rules.d/70-persistent-net.rules so the actual NIC is eth0 (2) remove entry for eth1 in Network Manager. Now everything works fine again.

I'm having this problem 9.04 jaunty kubuntu install. Bonded interfaces and static IP caused problems with network manager. I removed network manager and then noticed the NFS mounts not auto-mounting a boot. Not sure when the behavior actually started. I'm planning a parallel install on this machine so I will report more info when I have it.

I just want to say that I upgraded an edubuntu machine from 8.04 to 8.10 and got this too. I added sleep 45 and mount -a to /etc/rc.local rebooted and it worked.

The problem went away after I upgraded from 9.04 to 9.10. You may want
to upgrade to the latest release as well. Good luck.

Thanks,

jwillar
<email address hidden>

"The answer to the question of life, the universe and everything is 42"

On 02/18/2010 05:31 PM, nroussi wrote:
> I just want to say that I upgraded an edubuntu machine from 8.04 to 8.10
> and got this too. I added sleep 45 and mount -a to /etc/rc.local
> rebooted and it worked.
>
>

Upgrading to 9.10 did NOT solve this for me.

Upgrading to 9.10 did fix this for me. Unfortunately 9.10 completely broke suspend/resume on my laptop so I had to go back to 9.04. Issuing a sudo mount -a before opening Rythmbox has become so 2nd nature for me now I don't even remember doing it most of the time.

I noticed mt install no longer has a mountnfs.sh in /etc/init.d or any other location.

It seems my issue was caused by network manager. Issuing the command

sudo update-rc.d -f NetworkManager remove

fixed it for me.

Actually, what solves the issue is adding _netdev to the nfs mount options in fstab. This way it is mounted after the network has come up.

Example:

10.1.1.1:/home /home nfs rsize=32768,wsize=32768,intr,noatime,_netdev 0 0

this fixed it for me.

I am running Ubuntu 10.04 as an NFS 4 server and 10.04 as an NFS 4 client. I am able to mount NFS shares manually on the client eg.

# mount -t nfs4 -o proto=tcp,port=2049 nfs-server:/music /home/user/Music

I am also able to mount shares on the client using

# mount -a (When there is an entry in fstab.)

However, the share is NOT mounted from boot when entered in fstab and any attempts to mount it after a failed 'boot' attempt do not work. The strange thing is that after booting with the mount point entered in fstab '# mount' lists the mount point as being mounted but browsing that directory shows it empty.

Here is some relevant config info...
--
Client, fstab entry:
NFS4Server:music /home/user/Music nfs4 _netdev,auto 0 0
--

--
NFS4Server, /etc/exports:
/export 192.168.1.0/24(rw,fsid=0,insecure,no_subtree_check,async)
/export/music 192.168.1.0/24(rw,nohide,insecure,no_subtree_check,async)
--

--
NFS4Server, /etc/default/nfs-kernel-server:

# Number of servers to start up
RPCNFSDCOUNT=8

# Runtime priority of server (see nice(1))
RPCNFSDPRIORITY=0

# Options for rpc.mountd.
# If you have a port-based firewall, you might want to set up
# a fixed port here using the --port option. For more information,
# see rpc.mountd(8) or http://wiki.debian.org/?SecuringNFS
RPCMOUNTDOPTS=--manage-gids

# Do you want to start the svcgssd daemon? It is only required for Kerberos
# exports. Valid alternatives are "yes" and "no"; the default is "no".
NEED_SVCGSSD=no

# Options for rpc.svcgssd.
RPCSVCGSSDOPTS=
--

--
NFS4Server, /etc/default/nfs-common:

# If you do not set values for the NEED_ options, they will be attempted
# autodetected; this should be sufficient for most people. Valid alternatives
# for the NEED_ options are "yes" and "no".

# Do you want to start the statd daemon? It is not needed for NFSv4.
NEED_STATD=

# Options for rpc.statd.
# Should rpc.statd listen on a specific port? This is especially useful
# when you have a port-based firewall. To use a fixed port, set this
# this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
# For more information, see rpc.statd(8) or http://wiki.debian.org/?SecuringNFS
STATDOPTS=

# Do you want to start the idmapd daemon? It is only needed for NFSv4.
NEED_IDMAPD=yes

# Do you want to start the gssd daemon? It is required for Kerberos mounts.
NEED_GSSD=no
--

This really is a bit of a show stopper for me so a fix or any temporary work-a-rounds would be greatly appreciated.

I should add that in the above I am using a default Ubuntu network set up and a wired connection

OK... NFS mounts via fstab on boot fine in Ubuntu 10.04 BUT (obviously) not if you are mounting into a directory contained in an encrypted home. The encrypted folders are not available on boot when the NFS share is mounted.

Use this guide for help https://help.ubuntu.com/community/NFSv4Howto

And _netdev does help :-)

On a lucid machine with several NFS and NFS4 mounts specified in /etc/fstab, no share is mounted. /var/log/boot.log does not contain any traces of an attempt at mounting a share.

$ sudo mount -a mounts all shares, but throws errors for each filesystem like 'mount.nfs: /backup is busy or already mounted'

Can confirm this bug for 10.04 server.
nfs isn't connected in 1/10 cases in the boot proces.
The rest of the times it connects within the boot proces.

But in either case the next error shows during boot:
mount.nfs: DNS resolution failed for 192.168.1.11: name or service unknown

The client is a 10.04 server and the server is a debian 5.0

We have the same problem here - all home dirs are nfs-shares which now don't mount on boot so one cannot login.

In the beginning (after our upgrade) some shares at least mounted, but the last few days none mount.

Server is still running NFS v3 under Hardy, clients are newly upgraded to Lucid.

Logging in with a local user and issuing mount -a does work after the system is started.

System: 10.04 KVM Guest
Guest: Linux 2.6.32-26-server #48-Ubuntu SMP Wed Nov 24 10:28:32 UTC 2010 x86_64 GNU/Linux
Host: Linux 2.6.32-24-server #43-Ubuntu SMP Thu Sep 16 16:05:42 UTC 2010 x86_64 GNU/Linux

I get the following errors, perhaps every 1 in 5 boots from cold:

mount.nfs: DNS resolution failed for some-host: Temporary failure in name resolution
mount.nfs: DNS resoltuion failed for some-host: Temporary failure in name resolution
mountall: mount /var/blah [587] terminated with status 32
mountall: mount /var/www [568] terminated with status 32

Boot hangs, and will not continue until I do a CTRL+ALT+DEL. (Cold boot does not resolve the issue)

Presumably it's because the network hasn't come up, and/or the KVM boot process to too fast to even initialize/connect the 'physical' interfaces.

Attempts to use _netdev mount option has no affect. We don't use DCHP, or NetworkManager.

/etc/fstab:
some-host:/var/www /var/www nfs rw,noatime,nolock,intr,noac,_netdevl 0 0
some-host:/var/blah/ /var/blah nfs rw,noatime,nolock,intr,noacl,_netdev 0 0

/etc/network/interfaces:
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.0.131
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        dns-nameservers 192.168.0.1
        dns-search our_domain

auto eth1
iface eth1 inet static
        address 192.168.1.131
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255

i just installed a Ubuntu 10 LTS instance in a Xen VM Guest.

i'm still seeing the same issue as reported here ... nfs4 mounts in /etc/fstab quietly hand the boot process, with no error messages.

manual mounts are fine.

if i change in /etc/fstab

  - nfs-server:/vm/test/ /mnt/test nfs4 _netdev,...,bg 0 0
  + nfs-server:/vm/test/ /mnt/test nfs4 noauto,_netdev,...,bg 0 0

and, in /etc/rc.local

 + mount /mnt/test

then boot completes, and mounts are made.

The workaround from dev001 was all that worked on my Ubuntu 10.04.2 LTS running on a ZOTAC MAG ND01. Even turning _netdev on did not help.

A FIX for the problem
=============

We have also noticed that for some hosts, more often with multiple cpu cores in our experience, NFS shares are not mounted in time during upstart.

We have tried NFS v3 and v4 with Ubuntu 8.04 servers and Ubuntu 10.04 clients.

If /home is an NFS share this will cause a lot of trouble since a login without a home catalog will result in a locked up gnome session that requires sudo rights and some command line skills to resolve.
(Not the kind of situation you would like your users to find themselves in...)

It is a shame that this problem still persists – we have suffered from its consequences since 10.04 was released and not been able to find its root cause. To help others in the same condition we have decided to publish our fix – even thought it is quite ugly it works and removes the symptoms.

(Most likely the problem is related to DHCP assigned network interfaces not being up when mountall expects them to. This will cause a time out condition that is only resolved after a considerable amount of time and sometimes not at all, I.e the NFS shares remain unmounted when the user logs in.)

The following fix will provide peace of mind and happy users:

1. In /etc/fstab make sure all NFS mounts have the flag “noauto” set like:
10.0.0.250:/home /home nfs4 noauto 0 0

2. Add the attached upstart script /etc/init/nfs-upstart-fixer.
If you use NFS v4, that uses idmapd, uncomment:
'start on (net-device-up and started idmapd)
'
If you use NFS v3, that does not depend on idmapd, uncomment:
'start on (net-device-up)
'

3. Add the attached script /sbin/ensure-nfsshares-mounted.

4. Above will take care of most situations but if you are using gdm and are quick when logging in there is still a chance that the home share may not be mounted.
To be sure add the following line to the script /etc/gdm/PostLogin/Default:
/sbin/ensure-nfsshares-mounted

This will act as a guard.
(Read instructions in /etc/gdm/PostLogin/Default.sample if ther is no /etc/gdm/PostLogin/Default
in your system.)

Note 1:
The “magic” time constant of 8 seconds /etc/init/nfs-upstart-fixer is empiric. It works on all hosts I have seen this far. If it is too small there will be a time out condition which will cause the time between entering password and until the login is completed by quite a long time.
If this happens try with 10, 12, 14 until this does not happen.

Note 2:
For non gdm users there is probably a “hook” corresponding to /etc/gdm/PostLogin/Default.

Note 3.
If you have NFS shares in /etc/fstab that are truly intended to be “noauto” the above solution will
have to be modified a bit.

Hope you may now also enjoy swift boot up and NFS mounted home shares in Ubuntu even though this embarrassing bug remains unfixed!

Best regards

Sorry I missed the script /sbin/ensure-nfsshares-mounted
 in my last post.

Regards

I also experience this problem with 10.04.2
I seem to solve it much simpler than creating custom startup scripts..
I simply added "nfs" to /etc/modules and now my servers don't get stuck on mounting nfs shares.
Seems like something happened in kernel/modules config that it no longer auto-loads nfs module..

Thanks MxxCon - your suggestion would have been much simpler.

Unfortunately it did not work for us.

We are not experiencing this problem so often on servers, only on clients (about 9 out of 12 client boxes).

On servers we use static IP:s on clients we use DHCP.
Changing a client to a static IP did fix the NFS upstart problem!!!
When we investigated that clue we turned a lot of stones (even replacing our
managed switches with dumb once) but we could not find a problem related
to DHCP in our setup.

Most of our clients are clones - therefore it is amazing that the problem is consistent
on one box and not on another.
If it is a timing problem related to how fast the hardware is it might make sense though.
(We have tried with flushing all DHCP leases records in order to rule out "unlucky" NIC)

On a private (MPD) server I have also had this problem,
In such cases, when there are services depending on NFS shares being mounted the
upstart script emits the event 'nfsshares-mounted',
This saves the day - allowing me to wait with starting these depending services.

Regards

I as well have been plagued by this problem (NFS mounts failing on bootup) ever since upstart was introduced to Ubuntu.

Not sure why it's so hard to have the network up before things like mount are called, but apparently it is with Ubuntu.

I have a fixed IP address in /etc/network/interfaces, tried _netdev as a mount option, forcing the ethernet module to be loaded on boot in /etc/modules, etc., etc. with no luck.

The only workaround I have found is to use an IP address instead of a hostname in /etc/fstab.

At least one part of the problem is DNS resolution not working properly by the time mount is called.

This bug report was originally filed in 2008. The entire handling of boot-time mounting in Ubuntu has changed radically since then, so the original issue that was being reported is almost certainly no longer present. I'm therefore closing this report.

I see in the bug log that some users are reporting similar symptoms on later releases of Ubuntu that use the reworked boot mounting (upstart+mountall). If you are still seeing such problems with NFS shares listed in /etc/fstab not mounting at boot, even after applying all relevant post-release updates, please file a new bug report against the 'mountall' package so that these can be analyzed individually.