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).