Fedora 16 NFS Issue

Here at IWL, we use Fedora Linux rather heavily.

Recently we noticed a problem with Fedora 16 that caused us a lot of trouble. So we though it might be a good idea to make a public note of what happened and how we solved it.

The system in question is Fedora 16. Generally we use the 64-bit versions, but we would not think that this issue is any different on 32-bit platforms.

We use NFS file servers, such as the Netgear ReadyNAS units.

When our systems boot up the /etc/fstab file contains several entries designating file systems to be automatically NFS mounted.

In addition we use the autofs (automounter) to mount user home directories when users log in. These directories are mounted under /home. However the full set of user directories under one of the mountpoints that was mounted via fstab, as mentioned above.

What started to happen recently is this: Our set of startup mounts was not being mounted, but the user login mounts via autofs were working. (We could however, manually mount the items in /etc/fstab by “mount -a -t nfs”). The system log file – /var/log/messages – was showing NFS timeout errors, which usually recovered after a while, and failures of the NFS lock daemon, lockd.

As side effects of this some applications such as Firefox, Thunderbird, and sometimes Google Chrome would fail to start (and for Firefox and Thunderbird leaving a .parentlock file in their respective hidden directory hierarchies that prevented subsequent launches.) Many other applications, both KDE and GNOME, did work, however. Our guess is that there was some dependency on NFS lock semantics of the particular programs.

This started happening quite recently – with Fedora 16 updates occurring sometime in the first 9 days of May, 2012.

We found a work-around, which is to create user home directories on the local hard drive (and modify our /etc/auto.home files so that those would show up as /home/username.)

That seemed to cure the NFS timeouts, although it still left the automatic mounts via /etc/fstab inoperative (but they could still be mounted manually.)

Firefox, Thunderbird, and Chrome all work smoothly again.

And we could reach our old home directories via NFS without encountering any NFS errors or timeouts.

In our search for solutions we noticed a mention that there are issues in the systemd (systemctl) system that may be bring up parts of the system too quickly so that some networking dependencies were not actually satisfied.

In any event we hope that this helps people who encounter this situation.