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
    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
    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
    Jan 5 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
    Jan 6 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
    Jan 6 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
    Jan 6 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. May 18, 2020 at 17:09

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.


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

  • 1
    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
    May 5 at 7:49

You must log in to answer this question.

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