How to remount a Systemd mount unit with different options?

Question

I wish to express the following sequence of commands in terms of Systemd mount units and systemctl invocations:

# mount /some/path /some/mountpoint -o ro
# mount /some/mountpoint -o remount,rw
# touch /some/mountpoint/foo # placeholder for write action
# mount /some/mountpoint -o remount,ro

The conceptual problem appears to be that systemd.mount(5) operates on mountpoints. Since units are activated by passing the full path into systemctl, one cannot have multiple mount units for the same mountpoint. Templates don’t work for mount units either.

So how does it work? Is it possible at all?

Answer 1

Use a service unit instead of a mount unit

A simple oneshot service unit with the mount command worked for my remount use case (and I assume it'll work for yours).

Given that the mounts are often already defined in /etc/fstab and systemd automatically generated a <mountpoint>.mount for fstab entries, there are two approaches:

1. Simply fallback to a standard service unit instead of a mount unit and directly control the mount command.
2. Try use a systemd override? (Not tested, don’t think it’s viable)
   • Mount units have a strict requirement that the unit be named according to the mountpoint, so it’s probably not possible to run two separate mount units for the same mountpoint (already noted in the question).
   • Hence, this probably won't work for remounts, assuming it only overrides the original mount unit definition generated from fstab, and won’t execute twice.
   • If attempted, it’s more likely the original mount will probably fail given the remount option applied to something not yet mounted.

Example

I needed something similar and bumped into the following issue with trying to use the systemd mount unit type (because I didn't define my unit filename according to the mountpoint):

Where= setting doesn't match unit name. Refusing.

Given a bind mount to a data dir with more space, but with the parent mountpoint having nosuid and nodev set, I needed to add suid and dev privileges for lxc at /var/lib/lxc.

The service unit file /etc/systemd/system/lxc-remount.service:

[Unit]
Description=Remount the /var/lib/lxc folder with suid and dev privileges
Requires=var-lib-lxc.mount
After=var-lib-lxc.mount
Before=lxc.service

[Service]
Type=oneshot
ExecStart=/bin/mount -o remount,rw,suid,dev,relatime,discard,data=ordered /var/lib/lxc

[Install]
WantedBy=lxc.service

Commands to put it into effect:

$ sudo systemctl daemon-reload
$ sudo systemctl enable lxc-remount.service
Created symlink from /etc/systemd/system/lxc.service.wants/lxc-remount.service to /etc/systemd/system/lxc-remount.service.
$ sudo systemctl start lxc-remount.service

Answer 2

It is technically possible to implement this on top of systemd mount units. Therefore I cannot simply answer "no". There are a couple of disadvantages of this approach.

On the other hand, you can meet every requirement except for "use systemd mount units", by doing the remount part using the mount command. Note that systemd is generally quite happy for people to use the mount command. For example, if you temporarily unmount a filesystem with umount, the systemd mount unit will be marked as inactive. And when you use mount to mount a filesystem manually, systemd creates a transient mount unit for it. (Note it does not create a unit file).

Therefore in practice I would recommend using the mount command to perform the remount operations.

If you are reading this question and you have an additional reason not to use the mount command, please ask a new question with the specific reason. Without knowing any such reason, I cannot recommend actually using the method below. It is presented for educational purposes only.

---

You need to alter the Options= setting of the mount unit, and then systemctl reload the mount unit.

You can do this using a drop-in file which has this option only, underneath /run/systemd/system/. So you don't have to edit the on-disk configuration. If the system crashes part-way through, there is no risk of leaving a stale configuration.

It's not very "clean", however. It still risks that your commands are interrupted part-way through, and you could leave a stale configuration in two places - the state of the mount in the kernel, and the state of the mount in systemd. The first problem would exist anyway when using mount. But it means you could fix the first problem and forget about the second problem. Then the second problem could possibly cause a lot of confusion later on.

Note that when you create a drop-in file or edit the unit file, you will also have to run systemctl daemon-reload to pick up the new Option= value, before you reload the mount unit.

This is the second problem - I wouldn't really recommend to use this, at least for now. systemctl daemon-reload is a somewhat heavyweight operation :-). It could also have unwanted side-effects if you are unlucky. Some code was added at some point, to work towards reloading an individual unit file, but I don't see that documented as a usable feature yet.

(I also noticed one of the special unit directories /run/systemd/system.control/ is described as "transient configuration created using the dbus API". I believe this is used to keep track of changes to resource control settings and a few others. I think these are special cases, which can be changed using systemctl --runtime set-property. I assume they do not require a full reload).

Answer 3

Why not use a script? How can systemd suspend for you to edit?

I think a script is perfect for you, such as this:

#!/bin/bash
mount /some/mountpoint -o remount,rw
bash
# do some editing
# touch /some/mountpoint/foo # placeholder for write action
exit the shell/ctrl-d
mount /some/mountpoint -o remount,ro