5

If you run mount --move on a system booted with systemd, it will be forbidden with the above message.

This means you can run mount --make-private on the parent mount, and the move is then permitted...

But I noticed that I was able to move a mount in to a shared subtree. E.g.

mount --make-private /boot/
mount --move /boot/efi /mnt

This distinction means that attempting to undo using mount --move /mnt /boot/efi, will also fail.

What is the reason for forbidding moving a mount which resides under a shared mount? And why is it permitted to move a mount in under a shared mount?

$ mount --version
mount from util-linux 2.30.2 (libmount 2.30.2: selinux, btrfs, assert, debug)
$ rpm -q util-linux
util-linux-2.30.2-1.fc26.x86_64
Improve this question
1
  • mount --make-private doesn't work for me. :-( Commented Nov 27, 2019 at 7:49

1 Answer 1

Reset to default
1

It's true that it's not documented anywhere why you cannot move a mount that resides under a shared parent. I've worked on this code a lot in the kernel and my reasoning has been that it's forbidden because it would be easy to violate mount propagation semantics.

So for example, think about the following code:

mount --bind /opt /opt
mount --make-shared /opt
mkdir /opt/A
mount --bind /tmp /opt/A

mount --move /opt/A /mnt

Since the parent of /opt/A is a shared mount it would mean that the whole source propagation tree that /opt belongs to would need to be moved from /opt to /mnt. But then it's easily possible to envision a scenario where not each mount in the origin propagation tree that/opt belongs to can be moved to /mnt because there might not be a corresponding mountpoint. That can easily happen with mount namespaces. So in that case the mounts that don't have a mountpoint in the destination propagation tree would have to be discarded. But this would mean a umount event would need to be triggered. But that has other problems. For example, one could argue that the umount event should then propagate. But that would mean that the whole mount tree that is about to be moved would be unmounted. It's worse if the mount trees somehow overlap. There's a whole lot of hidden complexity there which is why it's simply blocked.

Improve this answer
2
  • Hmm. I suspect I'm not understanding. I think master/slave mounts would cause that problem, not namespaces specifically? I still think the kernel could treat it by analogy to unmount+mount. It just... might let you shoot yourself in the foot in a bunch of ways, maybe make the locking harder to reason about, and not be worth implementing because it wouldn't actually be used. Commented Feb 28, 2023 at 0:53
  • My reasoning is solely based on mount propagation. Mount namespaces make this problem easy to run into because they're so many of them due to containers or systemd services. As stated umount() and mount() would cause significant implementation complexity. Mount propagation can easily trigger propagation events with thousands or ten thousands of mounts and so can umount events. Commented Feb 28, 2023 at 13:32

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.