autofs: Automatic Mounts

automount - a hands-on Linux lab on a real virtual machine.

Configure on-demand automounting with classic autofs, the RHCSA exam form (not systemd automount units). The two-file model: a master-map entry under /etc/auto.master.d/ that points a base directory at a map file, and the map file mapping a key to options and a remote export. Enable persistently with systemctl enable --now autofs. The defining behavior: the share is NOT mounted until you ACCESS the path, which triggers it; confirm with findmnt. Includes the wildcard home-directory map (the key and & substitution), the classic exam pattern. NFS and autofs are client skills; the server is provided. Serves EX200 file-systems: configure autofs.

Run ls /net/share and the directory is empty. There is nothing there. A second later you cat /net/share/hello.txt and it prints a file that lives on a server across the network. You never ran mount. Nobody staged it. The very act of touching the path pulled the remote filesystem into place under your feet.

That is not a trick. It is autofs, and it is on nearly every RHCSA exam. Where /etc/fstab mounts a share at boot and keeps it mounted forever, autofs mounts on demand. The share is absent until something accesses the path, then it appears, and after a few idle minutes it quietly unmounts itself. This lesson teaches the classic exam form of autofs, the one you configure by hand with two files.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs come from a real RHEL 10 machine (AlmaLinux 10.2). NFS and autofs are CLIENT skills on the exam: the server that holds the share is provided for you (in the exam it is content.lab.example.net, sometimes called serverb). The captures here used a share on the same host to get real output, so one findmnt line reads /dev/mapper/rhel-root where an exam machine would show the remote server. A note flags that spot. What stays true everywhere is the two-file config and the on-demand behavior.

autofs is a service that mounts filesystems automatically, only when they are accessed, and unmounts them automatically when they go idle. You configure WHICH paths it watches; the kernel tells autofs the instant someone steps on one, and autofs performs the mount right then.

Compare it to /etc/fstab, which you met in the last module. An fstab NFS line mounts the share at boot and holds it mounted whether anyone uses it or not. autofs sits in between: nothing is mounted until the moment of access. That is why it is the tool of choice for home directories. A user's home mounts the instant they log in and cd into it, and large sets of shares stay off the machine until someone actually needs them.

Classic autofs is always two files working as a pair, and this is the whole mental model:

1. A master-map entry under /etc/auto.master.d/ (a file ending in .autofs). It names a base directory to watch and points at a map file. Example: /net /etc/auto.net. 2. A map file (like /etc/auto.net). Each line maps a key (a subdirectory name) to mount options and a remote export. Example: share -rw content.lab.example.net:/srv/nfsshare.

Read together, those two lines say: watch /net; when someone accesses /net/share, mount content.lab.example.net:/srv/nfsshare there, read-write. The base plus the key form the path (/net + share = /net/share), and the map file supplies the where-from.

Do NOT create the mount directories yourself. autofs owns and creates the base (/net) and the per-key subdirectory (/net/share) on demand. If you mkdir /net/share by hand, autofs may refuse to mount over it. Let autofs manage those directories; you only write the two config files.

Before autofs can watch anything, its service has to be running, and it must come back after a reboot (the exam always wants persistence). One command does both: systemctl enable --now autofs. The enable half wires it to start at every boot; the --now half starts it this instant.

Turn it on and set it to survive reboots in a single move:

systemctl enable --now autofs

prompt: [root@servera ~]# answer: systemctl enable --now autofs output: hint: One systemctl call does both: enable for boot, --now to start immediately: systemctl enable --now autofs

No error means the service is active and enabled. enable alone would have set it to start next boot but left it stopped now; --now alone would have started it but not survived a reboot. Together they give you both, which is exactly what a persistence-graded exam task needs. Confirm any time with systemctl is-enabled autofs, which should print enabled.

This is the behavior that defines autofs, and it surprises everyone the first time. With the two config files in place and the service running, look at the path BEFORE you touch the share. autofs has not mounted anything yet, because nothing has accessed it. The mount is on standby, waiting to be triggered.

Before you run it, decide what you expect: is the remote share mounted right now, or not? Check the state before any access:

cat /net/share/status.txt

prompt: [root@servera ~]# answer: cat /net/share/status.txt output: not mounted yet (autofs mounts on demand) hint: Just read the sentinel file with cat to see the pre-access state: cat /net/share/status.txt

The share is not there yet. autofs is armed on /net/share but has performed no mount, because until this moment nothing had reason to. This is the exact opposite of fstab, where the share would already be mounted from boot. With autofs, the mount is lazy: it costs nothing until someone actually needs the data. The next access is what flips it live.

That not mounted yet line is a sentinel captured on the practice machine to show the pre-access state clearly. On a real exam machine you would instead see an empty listing or the local placeholder before access; the teaching point is the same, the remote data is not present until you access the path.

Now do the thing that fires the automount: access the path. Any access counts, an ls, a cd, or reading a file inside it. The kernel notices the access, signals autofs, and autofs mounts the remote export in place, all before your command returns. So reading a file that lives on the share both triggers the mount AND shows you the remote content in one step.

Read the real file on the share and watch autofs mount it for you:

cat /net/share/hello.txt

prompt: [root@servera ~]# answer: cat /net/share/hello.txt output: shared file from the server hint: Read a file that lives on the share; the access itself triggers the mount: cat /net/share/hello.txt

shared file from the server. That content lives on the remote export, not on this machine, and a moment ago the path was empty. Your cat did double duty: the access triggered autofs to mount content.lab.example.net:/srv/nfsshare at /net/share, and then the file was read from that freshly mounted share. This is the whole magic of autofs in one line: touch the path, get the mount.

The mount is not imaginary. Now that you have accessed the path, it is a genuine mount you can inspect like any other. findmnt walks the live mount table and, handed a path, shows exactly what is mounted there, the target, the source it came from, and the filesystem type. This is how you confirm on the exam that autofs actually did its job.

Ask findmnt what is mounted at the path you just triggered:

findmnt /net/share

prompt: [root@servera ~]# answer: findmnt /net/share output: /net/share /dev/mapper/rhel-root[/srv/nfsshare] xfs hint: Hand findmnt the path autofs manages to see the live mount: findmnt /net/share

There it is, a real entry in the mount table where a moment ago there was nothing. findmnt shows the target /net/share, the source it was mounted from, and the type. Leave the path idle for a few minutes and autofs unmounts it again; the next access re-mounts it instantly. That appear-on-access, vanish-when-idle cycle is autofs working exactly as designed.

The source reads /dev/mapper/rhel-root[/srv/nfsshare] xfs because this capture used a share on the same host to produce real output without a second machine. On a genuine exam client, the same findmnt /net/share would show the remote NFS source, something like content.lab.example.net:/srv/nfsshare with type nfs4. The teaching point is identical: after access, findmnt proves the automount is live.

The single most common autofs exam task is automounting user home directories from a server. You do not write one map line per user. You write ONE wildcard line that handles every user, and it is worth memorizing cold.

In the map file, the key * matches any name the user accesses, and the & on the right is replaced with whatever * matched. So a map file /etc/auto.home containing this one line handles everyone:

* -rw content.lab.example.net:/home/&

Its master-map entry (in a file under /etc/auto.master.d/) points the base at that map:

/home/guests /etc/auto.home

Now when user jsmith logs in and lands in /home/guests/jsmith: the access triggers autofs, * matches jsmith, & becomes jsmith, and autofs mounts content.lab.example.net:/home/jsmith at /home/guests/jsmith. One line, every user, homes that mount exactly when someone logs in. That last property, mounting a home the instant the user needs it, is precisely why autofs owns home directories on the exam.

Scaffolding off. No command is printed this time. You have every piece you need.

You have configured autofs for /net, the service is enabled, and you have just accessed /net/share so the automount should have fired. Before you call the task done, you want to prove it: show that /net/share is genuinely mounted right now, with its source and filesystem type, by reading the live mount table for that one path. Which single command does that?

prompt: [root@servera ~]# answer: findmnt /net/share output: /net/share /dev/mapper/rhel-root[/srv/nfsshare] xfs hint: The tool that reads one path out of the live mount table is findmnt, given the path: findmnt /net/share

findmnt /net/share reads the live mount table for that path and prints the target, the source, and the type, proving the automount is real. Remember the ordering the exam rewards: the mount only exists because you ACCESSED the path first (the cat or ls), and findmnt is how you then confirm it landed. Access triggers, findmnt verifies.

You earned this cheat sheet. Every row is a form you just ran or built:

The one behavior to burn in for the exam: with autofs, the share is NOT mounted until you access the path. Configure the two files, enable --now the service, then trigger the mount by touching the path and verify with findmnt. And use the wildcard * / & line for home directories; it is the pattern the exam asks for most.

On RHEL 10 the exam uses classic autofs (the two files above), NOT systemd .automount units. If a mount does not trigger, restart the service with systemctl restart autofs so it re-reads the map files after an edit, then access the path again. And never mkdir the mount directories; autofs creates them.

The practice terminal has shown you the full autofs loop: the two-file config (a master-map entry pointing a base at a map file), systemctl enable --now autofs to start it now and at boot, the defining moment where the share is absent until you ACCESS the path, the access that triggers the mount, and findmnt to prove it landed, plus the wildcard * / & line that automounts every user's home. Every command you typed yourself.

The file-systems module mission is where you run these against a real RHEL 10 machine. A full VM boots for you, with a share to automount and its own map files to write. The mission hands you objectives that use exactly what you practiced here: enable autofs persistently, write the master-map entry and the map file, trigger the mount by accessing the path, and verify it with findmnt. One difference from this lesson: the mission shows no commands. You read the objective, recall the two-file shape and the enable --now and the access-then-findmnt rhythm, and type it. That recall is what makes it stick on exam day.

Finish the other file-systems lessons, then go make a directory mount itself the moment you look at it.

Practice autofs: Automatic Mounts in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.