Mount file systems on demand with autofs

autofs mounts a file system only when its mount point is accessed, then unmounts it on its own after a period of inactivity. This guide shows how to install the automounter, write maps for a local disk, an NFS share and home directories with a wildcard, then check that the mount triggers on access and disappears after the timeout. For intermediate administrators, on Debian, Ubuntu or RHEL. It is both an RHCSA and an LFCS objective. Outputs from an AlmaLinux 10 test.

What you will learn

• What on-demand mounting is and why it is better than fstab in some cases.
• Install and enable the autofs service.
• Write an indirect map, a direct map and a wildcard map.
• Mount a local disk, an NFS share and home directories automatically.
• Check the trigger and diagnose a mount that does not happen.

What on-demand mounting is for

A classic mount in /etc/fstab is permanent: the file system is mounted at boot and stays mounted. That is perfect for the root partition or a data disk always in use. But for an NFS share consulted once a week, or the home directories of a hundred users of whom three are logged in, keeping all mounts active continuously wastes resources and weakens the boot: an NFS server unreachable at boot can block the machine.

autofs meets this need. It watches a mount point and triggers the mount only on first access (an ls, a cd, opening a file). After a period without activity, the timeout, it unmounts automatically. The share only exists, from the system's point of view, while it is being used.

autofs versus fstab, in one sentence

fstab mounts right away and forever; autofs mounts on demand and unmounts after use. Both coexist: the root and permanent disks stay in fstab, occasional or network mounts go through autofs.

Install autofs

The package is called autofs on every distribution. To mount NFS, add the NFS client package (nfs-common on Debian/Ubuntu, nfs-utils on RHEL).

Debian/Ubuntu

sudo apt update
sudo apt install autofs nfs-common

RHEL/AlmaLinux

sudo dnf install autofs nfs-utils

Then enable the service and check that it is running:

sudo systemctl enable --now autofs
systemctl is-active autofs

The output must show active. The service is there, but it does nothing as long as no map tells it what to mount and where.

How autofs is organised

autofs reads a master map, /etc/auto.master, which associates each parent mount point with a map file describing what to mount below it. On recent distributions, you do not edit /etc/auto.master directly: you drop a .autofs file into /etc/auto.master.d/, which is included automatically.

A master map line follows this format:

/parent-mount-point   /etc/map-file   [options]

The map file, for its part, describes each mount. There are two main forms:

• Indirect map: autofs manages a parent directory and creates the subdirectories on demand. It is the most common form. Each line associates a key (the subdirectory name) with a source:

  key   -options   source

• Direct map: each mount has an independent absolute path. In /etc/auto.master, the parent point is the /- symbol, and the map key is the full path of the mount.

The source field designates what to mount: a network share (server:/export), a local device (:/dev/sdb1), or a file image. Let us look at the three concrete cases.

Mount a local disk on demand

First case, the clearest one: mount a local file system only when it is accessed. Here, an XFS image serves as a demonstration disk.

1. Prepare the file system to mount.

   sudo mkdir -p /srv/backing
   sudo truncate -s 512M /srv/backing/data.img
   sudo mkfs.xfs -q /srv/backing/data.img

   mkfs.xfs refuses images smaller than 300 MB: keep at least 512 MB.

2. Declare the parent point in /etc/auto.master.d/.

   echo '/mnt/local  /etc/auto.local  --timeout=30' \
     | sudo tee /etc/auto.master.d/local.autofs

   The --timeout=30 option unmounts after 30 seconds of inactivity.

3. Write the indirect map. The data key will become the /mnt/local/data subdirectory; the loop option asks mount to attach the image to a loop device.

   echo 'data  -fstype=xfs,loop  :/srv/backing/data.img' \
     | sudo tee /etc/auto.local

4. Reload autofs so that it picks up the new master map. reload is enough, and it keeps the mounts already active (see the troubleshooting section).

   sudo systemctl reload autofs

Now check the key behaviour. Before any access, nothing is mounted. Observe it in the mount table, and not with findmnt, which would access the path and trigger the mount itself:

grep /mnt/local/data /proc/self/mounts
# (no output: the mount does not exist yet)

Access triggers the mount. A simple ls or a write is enough:

touch /mnt/local/data/proof.txt
findmnt /mnt/local/data

TARGET          SOURCE     FSTYPE OPTIONS
/mnt/local/data /dev/loop0 xfs    rw,relatime,seclabel,...

The file system is mounted on a loop device, exactly as if you had done it by hand, but it only appeared at the moment you needed it. Let the timeout pass without touching it, then rerun the grep on /proc/self/mounts: it returns nothing anymore, autofs unmounted on its own.

Mount an NFS share on demand

The flagship use case of autofs, the one expected in RHCSA and LFCS, is the NFS mount. The configuration is identical, only the source changes: a server:/export path.

echo '/mnt/nfs  /etc/auto.documents  --timeout=60' \
  | sudo tee /etc/auto.master.d/documents.autofs
echo 'documents  -rw,soft  nfs-server.example:/srv/nfs/documents' \
  | sudo tee /etc/auto.documents
sudo systemctl reload autofs

An ls /mnt/nfs/documents then mounts the share on demand. The soft option prevents a process from staying blocked forever if the server disappears (to be kept for non-critical data; for sensitive writes, prefer the default hard).

Trap: NFS server on the same machine

If the NFS source points to the local machine (localhost: or its own name), autofs does not create a real NFS mount: it does a local bind. A findmnt then reveals an xfs type (the local disk) instead of nfs4. It only shows with a remote server: to really test the NFS mount, the share must live on another machine.

Mount home directories with a wildcard

Declaring one line per user would be unmanageable. The wildcard map solves this classic case: the * character matches any requested key, and the ampersand & reuses its value in the source.

echo '/mnt/homes  /etc/auto.homes  --timeout=30' \
  | sudo tee /etc/auto.master.d/homes.autofs
echo '*  -fstype=nfs,rw  nfs-server.example:/export/homes/&' \
  | sudo tee /etc/auto.homes
sudo systemctl reload autofs

With this single line, accessing /mnt/homes/alice mounts nfs-server.example:/export/homes/alice, and /mnt/homes/bob mounts his, without either being declared explicitly. That is how home directories are served on demand across a whole fleet.

Check and troubleshoot

Three commands cover everyday diagnosis, each with its limit, detailed below:

• findmnt <point> confirms that a mount is active and gives its real type, but it triggers the mount by accessing it.
• systemctl status autofs and journalctl -u autofs report the errors of the service, not mount failures.
• sudo automount -m lists the maps autofs has loaded.

reload rather than restart, and often nothing at all

systemctl restart autofs does reload the configuration, but it is the most brutal solution: it destroys all active mounts. Measured on AlmaLinux 10, two mounts in place: after a restart, zero; after a reload, both are kept.

Better still, a key added to a mount map is served without any reload: autofs rereads the map at each access. Reloading is only useful for the master map, and reload is enough there.

What you change	Action needed
A key in a mount map (/etc/auto.local)	nothing, it is picked up at the next access
The master map (auto.master, auto.master.d/)	systemctl reload autofs
Nothing works anymore, last resort	systemctl restart autofs, which unmounts everything

Swipe to see more

findmnt triggers the mount it claims to observe

A diagnostic trap to know before concluding anything: findmnt <path> accesses the path, therefore triggers the automatic mount.

On a point not mounted yet, the command exits with rc=1 without printing anything, which suggests that nothing is mounted. But right after, the mount does exist: the next check then seems to contradict the first one, and you believe in an inconsistency.

To observe without triggering, read the mount table directly:

grep /mnt/local/data /proc/self/mounts

Mount failures do not appear in journalctl -u autofs

Do not rely on the unit's journal to diagnose a mount that fails. Measured on AlmaLinux 10: a missing key in the map is indeed logged (key "inexistante" not found in map source(s).), but a real mount failure, key present and source non-existent, produces no line at all, neither under journalctl -u autofs nor under _COMM=automount.

The tool that talks is automount run in the foreground in verbose mode:

sudo systemctl stop autofs
sudo automount -f -v

Trigger the mount from another session

The "in another terminal" you read in documentation is not a convenience, it is a condition. Measured on AlmaLinux 10: with automount -f -v started then triggered from the same SSH session, the access fails with No such file or directory and the trace stays silent. From another session, the same access shows attempting to mount entry followed by the path, then mounted.

So open a second terminal to trigger the access while the first one shows the trace.

Once the trace is displayed, each access attempt from the second terminal (ls /mnt/local/data) shows there the exact cause of the failure. Then restart the service with sudo systemctl start autofs.

Here are the most frequent symptoms and their fix.

Symptom	Probable cause	Solution
Access mounts nothing, empty directory	Syntax error in the map	Rerun with automount -f -v and fix the faulty line
Permission denied on an NFS home under SELinux	Blocking SELinux boolean	sudo setsebool -P use_nfs_home_dirs on
NFS mount announced but type xfs	Server on the same machine (local bind)	Use a remote NFS server

Swipe to see more

autofs or systemd's automatic mounting

systemd offers an alternative with the x-systemd.automount option in fstab or an .automount unit: it also mounts on demand. The difference lies in centralisation. autofs shines with wildcard maps and large fleets (hundreds of network home directories from a few lines); systemd automatic mounting is better suited to a few fixed points already described in fstab. For a single permanent NFS mount, fstab with the _netdev option remains the simplest.

Put it into practice

Nothing beats a mount that appears before your eyes at the first ls. In this lab, you configure autofs with a master map and a mount map so that access to /autofs/data mounts the spare disk on demand, then unmounts it on its own after the inactivity timeout.

Guided lab Practice

Learn how to do it

Mount a filesystem on demand with autofs

$ dsoxlab run l2-autofs-ondemand

Environment: VM·Duration: ~30 min

How it is checked: the state of the system is checked after a reboot, not the command you typed.

First time? What DSOXLab is and how to install it

DSOXLab is the command line that prepares a disposable environment (an isolated shell or a VM), runs the lab scenario, then checks the real state of the system and computes a score. Nothing is installed or broken on your workstation.

It needs Python 3.11 or later, uv or pipx, and git. The installation guide details these prerequisites; on Windows, or on a Mac without Python, use the appliance instead.

This lab starts virtual machines: it also needs ansible-playbook, a hypervisor (KVM or Incus), Terraform and hardware virtualization (/dev/kvm), which inside a VirtualBox VM means nested virtualization. The first time, dsoxlab start l2-autofs-ondemand checks all of it before creating the machines. Prepare your machine for vm labs.

Install the CLI and add the catalogue, once:

uv tool install dsoxlab   # or: pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training

Before you run the lab, check:

• DSOXLab installed
• catalogue available
• compatible environment (isolated shell or VM)

To check, nothing is probed from this page: run dsoxlab doctor. Read the diagnosis

Run this lab, then validate your work:

dsoxlab run l2-autofs-ondemand
dsoxlab check l2-autofs-ondemand

See every lab: dsoxlab list-labs. Track your progress: dsoxlab progress. The full dsoxlab guide covers scoring and the pitfalls.

Key points

• autofs mounts on demand and unmounts after the timeout: the share only uses resources while in use.
• Configuration is done in /etc/auto.master.d/*.autofs (the parent point) and a map file (the mounts).
• An indirect map manages a parent directory; a direct map uses /- and absolute paths; a wildcard map (* and &) serves one mount per key.
• The source can be local (:/dev/..., loop image) or network (server:/export).
• A local NFS server gives a bind, not NFS: always test with a remote server.
• Diagnosis: /proc/self/mounts to observe without triggering, automount -f -v (from another session) to see the failures, which journalctl -u autofs does not show.
• After changing the master map, reload is enough; restart unmounts everything.

Knowledge check

Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →