systemd Remount Filesystems: Units for Mount Options (2026)

systemd’s mount unit handling can be surprisingly opaque, but understanding how it remounts filesystems is key to managing dynamic option changes.

Let’s see it in action. Imagine you have a partition mounted at /data and you need to change its mount options from defaults,rw to defaults,ro,noatime.

First, let’s check the current state:

mount | grep /data

You’ll see something like:

/dev/sda3 on /data type ext4 (rw,relatime,data=ordered)

Now, the systemd way to modify this without a full reboot or umount/mount cycle is to create a .mount unit file. systemd automatically generates these for entries in /etc/fstab, but we can also create custom ones or override existing ones.

Let’s create a unit file to manage /data. The convention is to name it after the mount point, with slashes replaced by dashes and an appended .mount. So, for /data, it would be data.mount.

We’ll create a file at /etc/systemd/system/data.mount with the following content:

[Unit]
Description=Data Filesystem
Requires=local-fs.target
After=local-fs.target

[Mount]
What=/dev/sda3
Where=/data
Type=ext4
Options=defaults,ro,noatime

[Install]
WantedBy=multi-user.target

Here’s what’s happening:

• [Unit]: Standard systemd unit section. Description is for human readability. Requires and After ensure this unit starts after basic local filesystems are up.
• [Mount]: This is the core.
  • What: The device or source.
  • Where: The mount point.
  • Type: The filesystem type.
  • Options: This is where we specify the desired mount options. systemd will use these to remount the filesystem.
• [Install]: WantedBy=multi-user.target means this mount will be enabled to start automatically on boot.

After creating this file, we need to tell systemd to recognize it:

sudo systemctl daemon-reload

Now, to apply the changes and remount /data with the new options:

sudo systemctl restart data.mount

If you check mount again:

mount | grep /data

You should see:

/dev/sda3 on /data type ext4 (ro,noatime,relatime,data=ordered)

Notice how rw is gone and ro, noatime are present. systemd achieves this by issuing a mount -o remount,options /mountpoint command internally. It doesn’t unmount and remount; it directly modifies the kernel’s mount flags for the existing mount. This is crucial because it preserves open file handles and running processes that might be using /data, avoiding disruptions.

The Options line in the .mount unit file is the primary lever. If you have an entry in /etc/fstab for /data, systemd will often generate a .mount unit for it. You can either edit /etc/fstab and then run systemctl daemon-reload and systemctl restart data.mount, or create an override file (/etc/systemd/system/data.mount.d/override.conf) to only specify the changed Options.

For example, to only add noatime to an existing mount managed by fstab:

Create /etc/systemd/system/data.mount.d/noatime.conf:

[Mount]
Options=defaults,rw,noatime

Then run sudo systemctl daemon-reload and sudo systemctl restart data.mount. This is often cleaner than managing the full .mount file if you only need to tweak a few options.

The most surprising aspect of systemd’s mount units is their ability to remount existing filesystems without unmounting them first, preserving active connections and open files. This is achieved by directly manipulating the kernel’s mount options rather than performing a full unmount/mount cycle, making dynamic configuration changes much less disruptive.

The next challenge is understanding how systemd handles automounts with .automount units.