Is there any reason to move away from fstab on a systemd system?

Question

I'm on an Arch Linux system, which means systemd.

In systemd there are native unit files for mountpoints, with the extension .mount. I've always just used /etc/fstab, which never gave me problems because systemd just picks up information from that. But now that I've actually read the documentation, I'm wondering if I should change to native systemd unit files.

The Arch Wiki suggests that there's no benefit, because it says to populate your fstab in the beginner's guide.

Answer 1

From man systemd.mount itself:

fstab

Mount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details). Mounts listed in /etc/fstab will be converted into native units dynamically at boot and when the configuration of the system manager is reloaded. In general, configuring mount points through /etc/fstab is the preferred approach to manage mounts for humans. For tooling, writing mount units should be preferred over editing /etc/fstab. See systemd-fstab-generator(8) for details about the conversion from /etc/fstab to mount units.

Note that certain features are only implemented for fstab. For example when systemd in the initrd is used to mount the /usr filesystem as well as the / filesystem. systemd in the initrd reads etc/fstab on / and looks for an entry for /usr.

It also lets you use mount /mountpoint manually. systemd is generally happy for you to do this, e.g. it will update the status of the mount unit when you unmount or mount the filesystem.

Answer 2

systemd mountpoints support more flexible configuration of at least when to mount each point. That's sometimes useful in really complicated problems with network mounts etc.

As a rule of thumb, you just use fstab unless you're stuck with configuring some complex behaviour (if you ever do), then try to find systemd solution.

Answer 3

I just came across a use case for systemd.mount that others haven't mentioned: for package management (e.g. RPM), it's a great way to avoid grep/sed tricks messing with /etc/fstab. Since there's no real equivalent to grubby for fstab, it's much easier to package a service file that mounts what you require.

At least with RPMs, I also found that the uninstall scripts even automatically unmounted when the RPM was removed.

Answer 4

Systemd is a better solution for mounts as it enables you to stage dependencies when mounting.

ie: By using the After= directive in the .mount file you can ensure a mount for a LUN doesn't happen until after it's first been connected. Here's a snippet from a script I wrote to automate mounting remote storage:

cat <<EOF> /etc/systemd/system/mnt-$ISCSIDISKMOUNTFOLDER.mount
[Unit]
Description=iSCSI Disk
After=connect-luns.service

[Mount]
What=/dev/disk/by-uuid/$(ls -al /dev/disk/by-uuid | grep $ISCSIDEVICE | awk '{print $9}')
Where=/mnt/$ISCSIDISKMOUNTFOLDER
Type=$FILESYSTEM

[Install]
WantedBy=multi-user.target

EOF

The mount was happening before the service "connect-luns.service" started, but once I plugged the service into the After= directive, the storage now rose-up correctly on boot. Systemd offered a very simple & elegant way of managing dependencies in respect to mounting remote storage in this use case.

Exception:

In some cases you might not be able to use SystemD to mount your storage, a very notable exception being Alpine Linux which still uses SysVinit and an /etc/fstab to maintain a tiny profile. Alpine Linux is popular in the container world. So there is still a place for /etc/fstab believe it or not even in the all-singing, all-dancing age of SystemD