Introduction

Not every filesystem should be mounted permanently at boot. AutoFS and systemd automounts activate resources on demand, while image and encryption tools handle removable or protected storage.

What you should be able to do after this lesson:

Configure direct and indirect AutoFS maps.
Explain systemd automount behavior.
Recognize ISO 9660, UDF, and common extensions.
Create a basic optical-media image.
Describe the dm-crypt and LUKS storage layers.

Big Idea: Mount on Demand, Encrypt Below the Filesystem

This objective combines two different ideas. Automounters delay a mount until a path is accessed. Block encryption creates a protected mapping first, then places a normal filesystem above it.

path access -> automounter -> mount remote or local filesystem
encrypted device -> LUKS unlock -> /dev/mapper name -> filesystem -> mount

Keeping these layers separate prevents mistakes such as trying to mount a closed LUKS container directly.

AutoFS

The master map points to one or more mount maps. A common file is /etc/auto.master or a file below /etc/auto.master.d/.

Example master entry:

/shares /etc/auto.shares --timeout=300

Example indirect map /etc/auto.shares:

projects -fstype=nfs4,rw server.example:/exports/projects

Accessing /shares/projects triggers the mount. After inactivity, AutoFS can unmount it.

A direct map uses /- in the master file and full paths in the map:

/- /etc/auto.direct

/srv/archive -fstype=nfs4,ro server.example:/exports/archive

Reload or restart the automounter after validating changes.

systemd Automount Units

An .automount unit watches a path and activates the corresponding .mount unit on access. The unit names must encode the path.

Benefits include dependency integration and on-demand mounting without a separate AutoFS map. AutoFS remains useful for large dynamic maps and directory-service integration.

Optical Filesystems

ISO 9660 is common for CD images.
UDF supports newer optical media and larger files.
Rock Ridge preserves Unix-style names and permissions on ISO 9660.
Joliet improves Windows-compatible names.
El Torito describes bootable optical media.
HFS awareness matters for some cross-platform media.

Create an image:

mkisofs -o archive.iso -R -J directory/

Mount it through a loop device:

mount -o loop,ro archive.iso /mnt/iso

dm-crypt and LUKS

dm-crypt provides block-device encryption; LUKS standardizes metadata and key slots around it.

cryptsetup luksFormat /dev/<device>
cryptsetup open /dev/<device> secure_data
mkfs.ext4 /dev/mapper/secure_data
cryptsetup close secure_data

Formatting destroys existing data. Back up the LUKS header and recovery information securely. Encryption protects data at rest, but an unlocked mounted filesystem is available to the running system.

Guided Practice: Read an Automount from End to End

On a lab system with AutoFS installed, inspect the effective master map:

grep -Ev '^\s*(#|$)' /etc/auto.master
find /etc/auto.master.d -maxdepth 1 -type f -print 2>/dev/null
systemctl status autofs

Create a plan for an indirect map at /shares and answer before applying it:

Which master-map line points to the child map?
Which key becomes the directory below /shares?
Which mount options and remote export are used?
How long should an idle mount remain active?

After an administrator applies the map, verify both trigger and expiration:

ls /shares/projects
findmnt /shares/projects
journalctl -u autofs --since '-5 minutes'

For encryption practice, use only a disposable image or virtual disk. Confirm with cryptsetup luksDump that LUKS metadata exists, then trace the unlocked mapper device with lsblk -f.

Troubleshooting Scenario

ls /shares/projects hangs, but mounting the NFS export manually works. AutoFS logs show that it tried to resolve the key project while the map defines projects.

The network and export are healthy; the path-to-key mapping is wrong. Correct the key, reload AutoFS, and trigger the exact path again. Restarting the NFS server would not address the mismatch.

Exam Focus

Distinguish direct and indirect AutoFS maps and know /etc/auto.master plus /etc/auto.* files.
Match .automount and .mount units by their encoded path names.
Recognize ISO 9660, UDF, HFS, Joliet, Rock Ridge, and El Torito.
dm-crypt supplies block encryption; LUKS supplies standardized metadata and key slots.

Recap

AutoFS and systemd automounts delay mounts until access.
Direct and indirect AutoFS maps use different path models.
ISO 9660 extensions improve portability and metadata support.
LUKS wraps encrypted block storage; filesystems live above the unlocked mapping.

203.3 Creating and configuring filesystem options