How to Use Systemd for Mounting Network and Local Filesystems on Linux: A Modern Guide

If you’re managing a Linux system, you’re probably familiar with /etc/fstab, the classic way of setting up local and network filesystems to mount at boot. It works, but let’s face it - there’s a more modern, efficient way to handle mounts now, and that’s with systemd. Systemd mount units give you better performance, more flexibility, and more control than fstab ever could.

In this post, I’ll walk you through how to use systemd for mounting local and network filesystems. Plus, I’ll explain why you might want to ditch fstab and take advantage of systemd’s features to simplify your life and boost your system’s performance.

Why Switch from fstab to Systemd for Mounting Filesystems?

1. Faster Boot Times

Systemd can mount filesystems in parallel, meaning your system boots up faster compared to fstab, which mounts filesystems one after the other. If you’ve got multiple local or network filesystems to mount, systemd’s ability to handle them all at once can shave some time off your startup process.

2. Smart Dependency Handling

One of the coolest features of systemd is its ability to handle dependencies between services and mounts. You can make sure your network drives mount only after the network is up, or that a local filesystem won’t mount until the device is ready. This prevents a lot of issues that happen when mounts try to happen out of order. We've used this recently at work by ensuing network shares would mount before PowerMTA would start.

3. Dynamic Mounting

Systemd doesn’t just mount filesystems at boot - it allows you to mount filesystems on-demand or based on certain conditions. This makes it super useful for network drives or temporary mounts that only need to be active when certain services are running. It’s like having a smarter fstab.

4. Better Error Handling

With systemd, if a mount fails, you don’t have to scramble. It has better error handling built in, including retries and alerts, which is far more reliable than relying on the old fstab system. If a mount fails, systemd can at least let you know, rather than silently leaving you with an issue you didn’t notice until later.

Mounting Local Filesystems with Systemd

Let’s start with a simple example: mounting a local filesystem with systemd. Let’s say you’ve got a local disk at /dev/sdb1 that you want to mount at /mnt/data.

Create the Mount Unit File: Systemd handles mounts through “unit” files. These files are stored in /etc/systemd/system/. To create a mount unit for /dev/sdb1 to mount at /mnt/data, run:

sudo nano /etc/systemd/system/mnt-data.mount

Then, add the following configuration:

[Unit]
Description=Mount Local Data Drive
DefaultDependencies=no
After=local-fs.target

[Mount]
What=/dev/sdb1
Where=/mnt/data
Type=ext4
Options=defaults
TimeoutSec=30

[Install]
WantedBy=multi-user.target

Explanation:

• What: Defines the device you’re mounting (in this case, /dev/sdb1).
• Where: Specifies the mount point (e.g., /mnt/data).
• Type: The filesystem type (e.g., ext4).
• Options: Mount options like defaults and rw (read/write).
• TimeoutSec: How long systemd should wait before considering a mount attempt failed.

Enable the Unit File: After creating the unit file, reload systemd’s configuration:

sudo systemctl daemon-reload

Now, enable the mount so that it automatically mounts at boot:

sudo systemctl enable mnt-data.mount

Check Mount Status: To make sure everything’s working, check the status of your mount:

systemctl status mnt-data.mount

Mounting Network Filesystems with Systemd

Systemd is also perfect for mounting network filesystems, like NFS or CIFS (SMB) shares. Here’s how you can swap out fstab for a systemd unit when mounting an NFS share.

Mounting an NFS Share with Systemd

Create the NFS Mount Unit File: If you want to mount an NFS share from 192.168.1.100:/data to /mnt/nfsdata, here’s the unit file you’d create:

sudo nano /etc/systemd/system/mnt-nfsdata.mount

Add the following:

[Unit]
Description=Mount NFS Share
After=network.target

[Mount]
What=192.168.1.100:/data
Where=/mnt/nfsdata
Type=nfs
Options=_netdev,rw,timeo=14,intr
TimeoutSec=30

[Install]
WantedBy=multi-user.target

Explanation:

• What: The NFS share (192.168.1.100:/data).
• Where: The mount point (/mnt/nfsdata).
• Type: The filesystem type (nfs).
• Options: The options you want to apply, like _netdev (which ensures the network is up before mounting).
• After: Makes sure the NFS mount happens after the network is ready (network.target).

Enable the NFS Mount Unit: Reload systemd to pick up the new unit file:

sudo systemctl daemon-reload

Enable the mount so it gets mounted automatically on boot:

sudo systemctl enable mnt-nfsdata.mount

Mount it immediately with:

sudo systemctl start mnt-nfsdata.mount

Check NFS Mount Status: Check the status of your NFS mount:

systemctl status mnt-nfsdata.mount

Why Systemd is Better for Mounting Filesystems Than fstab

While fstab has been the go-to method for years, systemd just offers more power and flexibility for managing your mounts. Here’s why you should consider switching:

• Faster Boot Times: With systemd, mounts happen in parallel, which can speed up your boot process significantly.
• Better Dependency Handling: Systemd makes sure your filesystems mount in the correct order, avoiding errors related to mounts trying to happen out of sequence.
• Dynamic Mounting: You can mount filesystems dynamically as needed, rather than just at boot.
• More Reliable Error Handling: Systemd will retry failed mounts and notify you of issues, unlike the silent failures you might get with fstab.

Wrapping Up: Why You Should Make the Switch to Systemd

If you want to take full advantage of modern Linux system management, switching from fstab to systemd mount units is the way to go. Systemd offers you more control, faster boot times, and better management of local and network filesystems.

Give it a try and see the improvements for yourself. If you’ve got a system running fstab, now’s a good time to migrate to systemd - don't be a dinosaur; you’ll be glad you did.