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.

  • 7
    /etc/fstab has the, for me, distinct advantage of managing mounts in the one file...
    – jasonwryan
    Commented Sep 15, 2013 at 7:19
  • 3
    I have used /etc/fstab for years without any concerns/problems. Even with NFS mounted partitions... As long as you know how to maintain your configuration, it is totally fine.
    – Bichoy
    Commented Sep 15, 2013 at 15:56

4 Answers 4


From man systemd.mount itself:


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.

  • I'm not sure if it is still valid that reference to fstab in initramfs. It's empty nowadays and dracut generates systemd units for eg. EFI fs, so I would assume the same applies for /usr.
    – Jiri B
    Commented Jan 5, 2023 at 23:02
  • @JiriB "systemd in the initrd reads etc/fstab on / and looks for an entry for /usr". I meant the fstab in the "real" root filesystem, not the /etc/fstab inside the initrd.
    – sourcejedi
    Commented Jan 6, 2023 at 0:01
  • still why would it need /etc/fstab in real FS? dracut-init-queue and subsequent mounts /, /usr (if applicable) and activates swap before switching to real root. Then you can have .mount units instead of /etc/fstab. Have you tested that and if so, what systemd/dracut version?
    – Jiri B
    Commented Jan 6, 2023 at 11:33
  • @JiriB Simples! It's so that you can't get in a situation where the initramfs has an outdated copy of the mount options etc for /usr. The mount options etc for /usr are stored in /etc/fstab on the "real" root filesystem, and in no other place. You don't need to regenerate the initramfs when you change the mount options. At least, when I last checked.
    – sourcejedi
    Commented Jan 6, 2023 at 11:43

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.

  • 1
    No, it really doesn't, especially on any system which is more complex than a pretty straight-up Linux server or desktop. In my line of work, "first, get rid of systemd" is pretty much how we roll. Commented May 18, 2020 at 17:09

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
Description=iSCSI Disk

What=/dev/disk/by-uuid/$(ls -al /dev/disk/by-uuid | grep $ISCSIDEVICE | awk '{print $9}')



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.


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

  • 2
    OK, but isn't that just equivalent to "x-systemd.after=connect-luns.service" as an fstab option? Using "after" is not really a reason to use a mount unit over fstab.
    – Étienne
    Commented May 5, 2023 at 7:49

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .