NFS automount evolves

I’ve updated the NFS automount script that provides “self-healing” NFS mounts. The script now allows a mount to be defined as read-write or read-only, and then subsequently monitors that the share is mounted as R/W or R/O (of course, it can’t mount a share that has been shared as R/O as R/W). Both Linux (tested on CentOS 6.1) and FreeBSD versions are provided.

Since various systems can provide cross-mounts via NFS, and they may be started/rebooted at the same time, various shares may or may not be available at each system’s boot time. By utilizing this script the mounts become available soon after the respective share becomes available (simply adjust the run frequency in crontab to the needs of your specific application). Also, by not adding the NFS mount points in fstab the boot process is not delayed by a share that is not [yet] available.

First for CentOS/Linux:

Then for FreeBSD/UNIX:

You should run the automount script from a runfile, like so:

..and call the the above runfile from crontab:

NFS automount, Linux (CentOS) version

Last summer I posted a script that would repeatedly (via cron) check on a availability and status of a NFS mount, and attempt to keep it mounted if possible. That script was written for (Free)BSD. Below is a slightly modified version that runs on Linux (in this case, CentOS).

Mounting an NFS share after boot, and checking up on it periodically…

I needed to automatically mount an NFS share after reboot. But the availability of that share could not be guaranteed – the system on the LAN offering the share might be down for maintenance when the system mounting the share is being rebooted. In such case there would be a lengthy wait during the boot sequence until the mount attempt would time out.

So I wrote a short script to handle the situation. When initialized at boot time through init.d or rc.d, it’ll first attempt to mount the share, but then times out in two seconds (this is a LAN NFS share so if the system offering the share is up there should not be a longer delay than that) and so the boot sequence is not slowed down terribly. (see update below) Once boot is complete, the script is run via cron every five minutes. Depending on the criticality of the share you may want to make that time shorter or longer. In this case it is a backup share which is not critical for the system’s functioning.

This technique would handle circular mounts, too, but obviously you would run into trouble if the mounts are required for successful system boot.

For this to work successfully add a marker file, such as “.myremoteservertransfers” in my example script below, in the share folder on the system exporting the share. I usually set the undeletable attribute on the file to make sure it doesn’t get accidentally deleted.

Update: Even with this code the boot sequence appears to hang until portmap times out (which takes quite a while) if the NFS share is not available at boot time. I removed the rc.d mount attempt and just shortened the cron poll period to 1 minute. That way the share will be up very quickly once it becomes available, yet the overhead caused by the periodic ping is minimal (both servers are on local LAN).