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.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 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. See systemd-fstab-generator(8) for details about the conversion.
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.
Method 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.
Method 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.
Method 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
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0