NFS and autofs

Every filesystem covered so far — Mount and Umount and fstab — dealt with physical or logical (LVM) disks: the device itself lived on the server. In practice, a filesystem often lives entirely on a different server and connects over the network. This article covers the most common network filesystem — NFS (Network File System) — and autofs, the service used to manage it automatically, on demand. NFS mounts can also be made permanent through fstab, but a plain fstab entry often isn't enough for network filesystems — which is why autofs gets its own coverage here.

What You Will Learn

By the end of this article you will be able to:

• explain the NFS server and client roles, and share a resource with /etc/exports and exportfs;
• connect to an NFS share from the client side with showmount and mount -t nfs;
• explain the main differences between NFSv3 and NFSv4;
• explain why autofs exists — on-demand mounting and automatically disconnecting unused mounts;
• read and write the structure of /etc/auto.master and map files;
• know the basic security measures around root_squash, network trust, and firewall ports.

What NFS Is and Why It's Needed

NFS is a network filesystem protocol, developed by Sun Microsystems and the most widely used in Unix/Linux environments. It lets a directory on one server be "exported" over the network to other machines and mounted there just like a local filesystem. From a user's or program's point of view, a directory mounted over NFS behaves almost exactly like an ordinary local directory — the difference is that file operations are sent to the server over the network in the background.

Typical use cases:

• sharing a common configuration or data directory across multiple servers;
• centralized user home directories (/home) — a user sees the same files no matter which server they log into;
• centralized backup or archive storage.

Server Side: /etc/exports and exportfs

On an NFS server, which directories are shared, with what permissions, and to whom is defined in /etc/exports. Format:

<directory>  <client>(<options>)

Example:

/srv/nfs/shared     192.168.1.0/24(rw,sync,no_subtree_check)
/srv/nfs/backup     192.168.1.50(ro,sync,root_squash)
/home               10.0.0.0/8(rw,sync,root_squash,no_subtree_check)

Each line contains:

• the exported directory's path;
• which client(s) are allowed (an exact IP, a network range, or a hostname/wildcard);
• the sharing options, in parentheses.

The most commonly used options:

After changing /etc/exports, apply the changes without restarting the service:

sudo exportfs -ra

-r — reread all exports based on /etc/exports, -a — apply every entry. Viewing current exports:

sudo exportfs -v

Client Side: showmount and Mounting

From the client side, before mounting, it's possible to check which directories a server has shared:

showmount -e 192.168.1.10

Export list for 192.168.1.10:
/srv/nfs/shared 192.168.1.0/24
/home           10.0.0.0/8

Manually mounting an NFS resource is no different from an ordinary mount command, except the filesystem type is nfs and server:/path is given instead of a device:

sudo mkdir -p /mnt/nfs-shared
sudo mount -t nfs 192.168.1.10:/srv/nfs/shared /mnt/nfs-shared

For a permanent mount, the same fstab logic applies directly:

192.168.1.10:/srv/nfs/shared  /mnt/nfs-shared  nfs  defaults,noatime,nofail,_netdev  0  0

hard vs soft Mounts: the Classic NFS Question

What happens to a client when the NFS server disappears mid-operation is decided by a single mount option, and it's the most-asked NFS interview question.

• hard (the default, and the recommended one) — if the server stops responding, the client retries the I/O indefinitely, blocking the process until the server comes back. A program reading a file just hangs, then resumes exactly where it left off once the server returns. No data is lost or silently truncated.
• soft — after retrans retries of timeo each, the I/O gives up and returns an error (EIO) to the application. The process doesn't hang, but a write that failed this way can leave a file silently corrupted or partially written, because the application may not check the error.

The practical rule: use hard for any read-write mount (it's the default for a reason), and only consider soft for read-only data where a hung mount would be worse than an error. Pair hard with bg (background-retry the mount at boot) and _netdev/nofail so a slow server doesn't stall boot.

The Difference Between NFSv3 and NFSv4

NFSv4 is recommended on modern systems, especially where a firewall and security requirements are involved — thanks to a single port and stronger authentication. The version can be specified explicitly at mount time:

sudo mount -t nfs4 192.168.1.10:/srv/nfs/shared /mnt/nfs-shared

autofs: Why It's Needed

An NFS resource permanently mounted via fstab has one drawback: the mount happens immediately at boot and stays in place permanently, even if the user never accesses that directory. This creates a few inconveniences:

• if the server is temporarily unavailable, client boot can slow down, or (as noted above, without nofail) stop entirely;
• an unused network connection keeps a standing resource (such as a TCP session) occupied;
• managing many NFS resources through fstab requires a large, static list.

autofs solves this with on-demand mounting: a directory is mounted automatically only the first time it's accessed, and automatically unmounted if unused for a period. To the user this is transparent — accessing the directory looks ordinary, but behind the scenes an automount daemon manages the mount/unmount process.

/etc/auto.master and Map Files

autofs configuration has two levels: the central /etc/auto.master file determines which "trigger" directory is managed by which map file, and the map file describes how each subdirectory should be mounted.

/mnt/nfs   /etc/auto.nfs   --timeout=600

Here, /mnt/nfs is the top-level directory autofs manages, /etc/auto.nfs is the map file, and --timeout=600 means an unused mount is automatically detached after 600 seconds (10 minutes).

Sample map file:

shared   -rw,soft,intr   192.168.1.10:/srv/nfs/shared
backup   -ro,soft,intr   192.168.1.10:/srv/nfs/backup

Each line contains:

• the first column — the name accessible under /mnt/nfs (for example, /mnt/nfs/shared);
• the second column — mount options (similar to fstab, prefixed with -);
• the third column — the source, i.e. server:/path.

Restart the autofs service after changing the configuration:

sudo systemctl restart autofs
sudo systemctl status autofs

Now, the first time /mnt/nfs/shared is accessed (for example, with cd or ls), autofs mounts it automatically:

ls /mnt/nfs/shared
mount | grep nfs

If it isn't used for the configured timeout, the mount is automatically detached and no longer appears in mount output.

Security Notes

Since NFS operates over the network, its configuration deserves particular attention to the following points.

root_squash should always be enabled, unless there's a clear and justified reason not to. no_root_squash gives the client's root user full root privileges on the exported directory on the server too — which fully exposes the server if the client machine is compromised.

Network trust (AUTH_SYS) limitations. With NFSv3 and standard NFSv4 configuration, client authentication is often based purely on UID/GID information provided by the client itself — which can be forged on an untrusted network. This is why NFS is generally recommended only on a trusted, isolated internal network (for example, a private VLAN), not over the open internet. If stronger authentication is needed, NFSv4 + Kerberos (sec=krb5) is worth considering.

Firewall ports. For NFSv4, opening a single TCP port — 2049 — is generally enough. NFSv3 uses several services (rpcbind — 111, mountd, nfsd, nlockmgr, statd) on different ports, often chosen from a random port range unless bound to fixed ports through /etc/nfs.conf or a matching configuration file. This makes configuring NFSv3 behind a firewall considerably more complex — another reason NFSv4 is generally preferred in practice.

sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --reload

Practical Scenario: Mounting an NFS Resource On-Demand via autofs

Problem. Several clients need to automatically access a shared /srv/nfs/shared directory when needed, but not via a permanent fstab entry — because the resource is rarely used and the server is periodically taken down for maintenance.

Inspection (confirming the export exists on the server side).

showmount -e 192.168.1.10

Export list for 192.168.1.10:
/srv/nfs/shared 192.168.1.0/24

Action (configuring autofs on the client).

sudo apt install autofs

/mnt/nfs   /etc/auto.nfs   --timeout=300

shared   -rw,soft,intr,nofail   192.168.1.10:/srv/nfs/shared

sudo systemctl enable --now autofs

Result. Automatic mounting works on the first access to the directory:

ls /mnt/nfs/shared
mount | grep shared

If it isn't used for 5 minutes (300 seconds), the resource unmounts automatically — waiting and running mount | grep shared again confirms this (the result should be empty).

Conclusion. autofs replaces a static fstab entry with on-demand mounting — the server being temporarily unavailable has no effect at all on client boot, since the mount only happens at actual use.

Common Mistakes

Disabling or Ignoring root_squash

no_root_squash should only be used in specific, limited, trusted situations (for example, a backup server trusting a single, known client). By default, root_squash should stay enabled.

Leaving Out nofail/_netdev for an NFS Mount in fstab

This is the most common mistake leading to a boot problem — the network-filesystem-specific case of the general rule covered in fstab.

Opening Only Port 2049 When Configuring a Firewall for NFSv3

NFSv3 uses several ports (rpcbind, mountd, statd); opening only port 2049 causes the mount to fail. Either switch to NFSv4, or fix NFSv3's ports through /etc/nfs.conf and open all of them.

Setting the autofs Timeout Too Short

A very short timeout (for example, 10 seconds) causes a frequently used resource to be mounted and unmounted constantly, creating unnecessary network and CPU load. The timeout should match how often the resource is actually used (usually several minutes).

Exercises

1. Prepare two disposable VMs: one as an NFS server (nfs-kernel-server), the other as a client. On the server, export one directory with rw,sync,no_subtree_check.
2. On the client, check the export with showmount -e, then connect manually with mount -t nfs, write to a file, and confirm it appears on the server side.
3. Configure the same resource through autofs instead of fstab, with a short --timeout (e.g. 60 seconds), and observe it unmounting automatically.
4. Try the export with root_squash and then no_root_squash in turn, and compare which owner (nobody or root) a file created by the client's root user ends up with on the server.

Verification criterion: given an NFS export configuration, you should be able to identify whether root_squash is enabled and explain the security consequence if it isn't.

Summary

NFS opens directories to the network on the server side through /etc/exports and exportfs, and connects on the client side through a plain mount -t nfs or an fstab entry (with _netdev, nofail). NFSv4 is preferred over NFSv3 thanks to its single port and stronger authentication. autofs replaces a static, permanent mount with on-demand mounting and automatic unmounting, making it considerably more resilient when working with rarely used or intermittently available network resources. root_squash, tight network restrictions, and correct firewall settings are the minimum requirements for NFS security. How much space mounted filesystems occupy and how that's restricted per user continues in Disk Quotas.

References

• man7.org: nfs(5)
• man7.org: exports(5)
• man7.org: exportfs(8)
• man7.org: autofs(5)
• man7.org: automount(8)
• man7.org: showmount(8)
• Red Hat: Exporting NFS Shares
• Red Hat: Configuring autofs
• Ubuntu Server Guide: NFS