📅 April 18, 2021
NFS (Network File System) is a great way to mount remote drives across a network and treat them like local drives on a local Linux system.
With a 10 gigabit Ethernet connection (10GbE) and remote SSD or NVMe storage, remote drives can be every bit as speedy and zippy as local SSD or NVMe storage. This is an excellent way to create centralized network storage for multiple Linux clients.
One little downside to NFS involves auto-mounting the remote shares using /etc/fstab. If the server is online, everything is good, but if there is no network connection, client boot time increases as Linux times out while attempting to mount a nonexistent remote share.
One way to solve the automounting problem is to use a program called autofs.
Summary of Installation
Step 1. Install autofs on the client, not the server.
sudo apt install autofs
Step 2. Edit auto.master for direct mapping
/- /etc/auto.misc
Step 3. Edit auto.misc
/nfs/myshare -fstype=nfs4,rw 192.168.100.10:/media/myshare
The exact paths and address will depend upon your network and NFS server.
Step 4. Restart autofs to apply the changes
sudo service autofs restart
Why Not Use /etc/fstab?
/etc/fstab is intended for persistent storage. autofs dynamically mounts remote shares when needed.
- /etc/fstab – Persistent mounting
- autofs – Dynamic mounting
/etc/fstab is intended to mount filesystems during system boot. These filesystems are intended to remain mounted while the Linux computer is on. This makes /etc/fstab excellent for local storage devices like hard drives.
This works well when the filesystems are up and running, but what if a drive (local or remote) is down? The system will timeout as it waits for a device that will never mount. This can add up to 1min 37seconds to the boot time of Linux Mint 20.
Because of this issue, autofs was developed. autofs avoids the /etc/fstab delay issue by automatically mounting the NFS share when the user needs it. After a set amount of time, autofs will automatically release the share to conserve resources. Think of it as intelligent mounting. If the share exists, use it. If not, skip it, and move on. There is no added boot delay since /etc/fstab is not needed when mounting the NFS share.
autofs Issues
However, autofs is not perfect either.
- More complicated to set up
- Mount points within /media can cause duplicate shares, making you wonder, “What?”
- For mount points outside /media, Nemo file manager does not automatically show new shares in its sidebar while /etc/fstab does
Another program, called amd (not the CPU company), offers more intelligence over autofs, but it can be even more complex to set up. Both autofs and amd are freely available in the Ubuntu repository. (You can locate amd by searching for am-utils in Synaptic. autofs is known as…you guessed it…autofs.) This article will focus on autofs.
Plenty of Outdated Guides
I thought autofs would be easy to use.
- Install autofs
- Configure it following an online guide.
How hard can that be?
Only it was not easy. In fact, hardly anything I tried worked. autofs would not mount any remote shares despite following many, many online guides exactly. To this day, I still cannot get autofs indirect mapping to work despite following examples verbatim.
It turns out that detailed, useful information about autofs is sparse, and guides are usually 12+ years old, making them somewhat outdated with the newer version of autofs I had installed in Linux Mint 20. Many take the approach that users should already know about autofs and its inner mysteries.
From my recent experience installing and using autofs, there are a few differences in configuration files that make a huge difference, and I wrote this article to show what worked for me when mounting a remote NFS share in Linux Mint 20.
It was simple once I realized the differences and figured out what to do, but arriving at that conclusion required hours of trial and error and many, many system reboots. Hopefully, the advice here will help save your time.
Installation
autofs is available for free from the Ubuntu repository.
sudo apt install autofs
This will add an empty directory, auto.master.d, and five files in /etc.
/etc/auto.master.d is an empty directory after installation. Its purpose is to create custom mount instructions. We will not be using it.
/etc also adds five extra files related to autofs. We need to edit auto.master and auto.misc before autofs will automount an NFS share.
autofs has its own man page for more details about operation.
man autofs
/etc/auto.master and Direct Mapping
Open this file as root in a text editor.
sudo xed /etc/auto.master
Add this line to the end of the file and save. Leave the existing contents of the file alone.
/-Â Â /etc/auto.misc
auto.master is the main file autofs will check in order to mount an NFS share. Optionally, we can use custom files in auto.master.d, but this is not necessary and requires extra setup.
autofs uses entries found in two files in order to mount a single share. Yes, this is confusing and more complicated than it needs to be, so it is easy to make mistakes somewhere and wonder why NFS shares are not mounting. Take your time and double check.
An entry in auto.master tells autofs where to find a map file. A map file maps remote shares to local mount points. In the example above, we are using the existing file auto.misc as the map file.
An auto.master entry consists of three parts:
<mount_point> <map_file> <options>
mount_point
We are using a special notation consisting of a forward slash followed by a hyphen.
/-
This denotes direct mapping where auto.misc will specify the mount point details. Another way is to specify indirect mapping using a mount point as an absolute path and all remote shares will be mounted under it as a virtual directory structure, but I could never get this to work. We will use direct mapping.
map_file
This is the path to another file that contains the mapping/mounting details. Use the absolute path to the file. We are using /etc/auto.misc. auto.misc is the map file in this case.
options
Additional options for the mount go here. We do not need to specify any options for this example, so this is left blank.
/etc/auto.misc
Since we specified auto.misc as the map file in auto.master, this is the file we need to edit. We can use almost any text file in place of auto.misc as long as we specify the absolute path in auto.master, but we will reuse auto.misc for convenience because it already exists.
Open /etc/auto.misc in a text editor as root.
sudo xed /etc/auto.misc
auto.misc contains default comments for examples.
The NFS server should already be set up and configured for sharing. The article Intel NUC, Linux, Pi-Hole, and NAS – Part 10: NFS explains how to set up a basic NFS server. For this example, we will assume that the NFS server is located at IP address 192.168.100.10, and it is sharing /media/nfs_share_on_server.
Add an entry to auto.misc like this:
/media/myshare -fstype=nfs4,rw 192.168.100.10:/media/nfs_share_on_server
We are using NFSv4 on the server, so we can specify nfs4 for the filesystem type. Your exact mounting details will depend upon your system.
- /media/myshare – This is the mount point on the local Linux computer. There no need to create this directory in advance. Name it whatever you want. Placing it in /media causes Nemo file manager to automatically display it in its sidebar, but this can lead to duplicate listings.
- -fstype=nsf4,rw – The server is using NFSv4, so we specify nfs4 here. If using NFSv3 or NFSv2, use nfs. The rw means mount with read/write access.
- 192.168.100.10 – This is the NFS server’s IP address. A domain name is also allowed. In this case, the NFS server exists on a private LAN, isolated from the Internet, so security is not an issue.
- :/media/nfs_share_on_server – This is an absolute path of the share on the NFS server. This must be set up in advance on the NFS server, which we assume is up and running here. Make sure to separate the IP address from the path using a colon (:).
Save the file, and restart autofs to see what happens. Make sure that /etc/fstab does not contain any entries that mount the same NFS share since /etc/fstab is not needed for NFS if using autofs.
sudo service autofs restart
Nemo file manager in Linux Mint 20. autofs correctly mounts the share, but the share appears duplicated under Devices in Nemo.
The NFS share will be available in Nemo in the sidebar. Just select the share to access its contents.
Must I Create the Mount Point in Advance?
No. /media/myshare shown above is dynamically added to the local filesystem when the remote share is mounted. You do not need to manually create a mount point like you do with local mount points. autofs handles the details. Once the share is mounted, you can access it using the new mount point like any other directory.
Why Do Duplicate Shares Appear?
For reasons I am unable to explain at the moment, Nemo shows the same share twice in the sidebar. This is one of the minor annoyances of autofs versus /etc/fstab. /etc/fstab does not do this.
A Possible Solution
Until a better answer is found to avoid the duplicate share appearing in Nemo, we can mount the share outside of /media. (Nemo automatically lists devices mounted in /media.)
Change the mount entry in auto.misc to a mount point outside of /media. Avoid using any user’s home directory.
/nfs/myshare -fstype=nfs4,rw 192.168.100.10:/media/nfs_share_on_server
Again, do not manually create the mount point /nfs/myshare. autofs will handle that.
Restart autofs.
sudo service autofs restart
The share no longer appears duplicated in Nemo.
In fact, the share does not appear at all in the sidebar.
We know the share has been mounted because we see /nfs where it should be, and we can open it to see the share contents.
The same share contents as before are accessible.
We can access the share, but we can no longer select it from the Nemo sidebar. One solution to this is to add a bookmark.
Added a bookmark (renamed to NFS Share). Clicking the bookmark opens the share in Nemo.
Adding a bookmark allows us to access the share in Nemo by selecting the bookmark from the sidebar. This is very convenient, but it does not solve the underlying issue. For now, it works.
autofs or /etc/fstab?
I have encountered absolutely no problems mounting the share in /etc/fstab. Here is an entry I use:
192.168.100.10:/media/nfs_share_on_server /media/myshare nfs4 defaults 0 0
The mount point /media/myshare must be created in advance when using /etc/fstab.
The share mounts automatically under Devices in the Nemo sidebar without duplicates, and if the share is offline, Linux Mint 20 still boots just as fast. No hanging, and no increased boot time.
Strangely, setting up the same /etc/fstab on another test computer running Linux Mint 20 causes Linux Mint to timeout for 1min 37seconds during boot time if the share is offline. No idea why despite two similar test systems.
If you encounter long waits during boot when using /etc/fstab to mount the share, try using autofs. However, if /etc/fstab works out well, then autofs might not be needed unless you want the extra features.
The NFS Share is Not Showing Up!
This can happen if the NFS server is offline when a client tries to mount the NFS share. The local mount point will be empty. When the NFS server is brought online again, the local mount will still be empty despite attempting to mount the remote share manually from the command line because the client still thinks the NFS server is down.
Just restart the autofs service on the client, and the NFS share will mount.
sudo service autofs restart
This is one of the quirks of NFS. For best results, ensure that the NFS server is online before starting the clients. NFS best operates when the server is up and running all of the time.
Conclusion
autofs is a good complement to NFS with extra features to conserve resources and the ability to eliminate possible boot delays. I like both autofs and /etc/fstab, but, in practice, with newer Linux distributions, I prefer to mount shares using /etc/fstab for systems that do not exhibit any boot delays resulting from offline shares and use autofs on systems that do.
Have fun!
Delightly Linux 