When NFS server is rebooted, clients need to be rebooted too

Q I have a remote drive (rw) on a server connected by NFS which the client computer mounts at boot time using fstab. If the server computer is rebooted this seems to require any clients to be rebooted and the server disk remounted. On my Amiga I can do this by issuing a diskchange command on the client. Is there a way to do this on Linux without having to reboot the client or manually unmount and remount, or can I do this automatically?

A Thankfully, it's a simple task to remount a device in Linux: just use mount /mount/point -o remount However, this should not be necessary. NFS is capable of restoring a mount when the server comes back up, and should do this by default, but it can have problems when the reboot is lengthy (ie, around five minutes or more). Does the server have a static IP address? If it uses DHCP, it is possible that it gets a different address after a reboot. It is more likely to be an error with the original mounting or exporting of the filesystems. What do the system logs on the server and client machines show? These usually contain valuable clues. Check the export options on the server with

exportfs -v

particularly the sync or async setting. It also helps to have either the soft or intr option in the /etc/fstab entry on the individual client computers. The exportfs man page lists the various options for the server, and the NFS man page shows the various mount options. Intr is often preferable to soft as it is less likely to result in data loss if the server reboots. The alternative option, which is the default when none is given, is hard. These all determine how the client handles a lack of response from the server. As soft can sometimes cause data loss on the server, it is best used when exports are mounted read-only - intr is the best general-purpose setting, as it allows the client to respond to signals instead of just locking things up when the server goes away. It is really a matter of trying the various options, and seeing which works best for you, but intr is my preferred way of avoiding timeout problems.

Follow us on Identi.ca or Twitter

Username:   Password: