In this lesson, you will learn how to integrate filesystem mounting directly into the systemd lifecycle to ensure your storage is available exactly when your applications need it.
Moving Beyond /etc/fstab
While the traditional /etc/fstab file is the standard way to mount filesystems at boot, systemd offers a more dynamic, dependency-aware approach. By creating a .mount unit file, you treat your mount point as a first-class citizen in the service manager. This allows you to define strict orderings: for example, you can ensure a database service waits for a specific external drive to mount before attempting to start, preventing application crashes or data corruption.
Anatomy of a Mount Unit
A systemd mount unit must be named exactly after the absolute path of the mount point. If you want to mount a drive at /mnt/data, the file must be named mnt-data.mount.
Here is a simple example of a mount unit:
[Unit]
Description=Mount High-Speed Storage
After=local-fs.target
[Mount]
What=/dev/sdb1
Where=/mnt/data
Type=ext4
Options=defaults,noatime
[Install]
WantedBy=multi-user.target
Why use systemd mounts?
The power of this strategy lies in dependency management. When you use a .mount unit, systemd tracks the state of the filesystem. If you define a service that requires this mount, you can use Requires=mnt-data.mount and After=mnt-data.mount in your service file.
Furthermore, systemd automatically generates corresponding automount units if you create a .automount file with the same name. This allows the system to remain "lazy"—it won't actually mount the disk until a process attempts to access the /mnt/data directory. This is incredibly useful for network drives or rarely used backup partitions, as it avoids hanging the boot process if a device is offline or slow to initialize. By integrating mounting into the systemd graph, you ensure that storage availability is treated as a core part of the system's operational lifecycle rather than an afterthought.
Key Takeaway: Using systemd .mount units allows you to bake filesystem availability into your service dependency graph, ensuring that applications start only when their required storage is verified and ready.