filesystem(7) man page does not explicitly state that network filesystems are not waited for

[Kevin Fishburne]

Binary package hint: upstart

This is probably related to a hidden feature of upstart or gdm. I'm using a clean install of Ubuntu 10.04 Desktop 64-bit and first noticed the problem when moving my PC to a different network cable, which probably introduced enough latency or interference to delay the mounting of nfs shares to make the bug noticeable. My fstab is the same it's always been across multiple versions of Ubuntu, including 10.04, so while altering it may be a workaround I don't think it's misconfigured.

Basically, nfs shares defined in fstab try to mount at some undetermined interval as the rest of the system speedily proceeds to boot to the desktop. Normally no one would care if the nfs shares mounted post-gdm, but in this case the user's home directory is mounted on an nfs share. Since the nfs shares mount just after gdm starts loading the user's settings, the following occurs:

Ubuntu, finding an empty home directory, loads /etc/skel giving them a default profile. As this is happening the nfs shares are mounted, including the home directory. Hitting F5 on the desktop refreshes it to load the user's desktop icons, and a few settings eventually are reloaded from the now-mounted home directory. Half the settings are still hanging out as skel defaults. Time for the ultimate horror:

The default skel settings are saved back to the home directory on the nfs share, wiping out the user's original settings. Now the user logically changes the wallpaper, icons, panels, etc., back to the way they like it. The next time the system reboots (when the nfs shares will be remounted) the same problem happens and again half their user settings are restored to skel status. Wash, rinse, etc.

The only way around this I've found is to disable automatic login and allow 10 or so seconds to elapse after reaching the login screen so the /home nfs share can mount before logging in. Nightmare to say the least. Any info appreciated.

[Andrew Edmunds (andrew-edmunds)]

This is actually a (mis)feature of mountall, rather than upstart. Mountall waits only for NFS mounts of /usr and /var, or their subdirectories, to succeed before issuing the "filesystem" event. The filesystem event is what triggers gdm to start.

To wait for any other NFS filesystem you have to add the option "bootwait" to the /etc/fstab entry. See paragraph about mountall in fstab(5). So in this case adding "bootwait" to the options for /home should fix the issue.

The filesystem(7) man page says "The filesystem event is generated by the mountall(8) daemon after it has mounted all filesystems listed in fstab(5)" but this is a blatant lie. Personally I would prefer to see the behaviour altered to match what this man page says, but failing that the man page should be corrected. Either way there is definitely a bug here.

I think the motivation for the current behaviour was to cater for people who have wireless networking that doesn't come up until the user logs in and yet still have NFS mounts listed in fstab. I believe those people should be using the "noauto" or "nobootwait" options on their NFS mounts, or leaving them out of fstab altogether. Failing to do so is just a user error in my opinion and mountall shouldn't be pandering to people who misconfigure their system in this way.

[Clint Byrum (clint-fewbar)]

I think the man page for 'filesystem' is all that needs to be fixed. I've changed the description as such and reassigned this bug to mountall.