2

A colleague of mine mounted an incorrect volume onto the directory, and then mounted the correct volume onto the same directory. Is there a way to unmount this "incorrect" volume without touching the "correct" volume?

Here's a reproducible example of this situation:

$ dd if=/dev/zero of=file-a bs=1M count=1 $ mkfs.ext4 file-a $ dd if=/dev/zero of=file-b bs=1M count=1 $ mkfs.ext4 file-b $ mkdir target $ sudo mount -o loop file-a target $ sudo mount -o loop file-b target

Here's the situation after these commands:

$ findmnt TARGET SOURCE FSTYPE OPTIONS / /dev/xxx ext4 └─/home/user/test-umount/target /dev/loop1 ext4 rw,relatime └─/home/user/test-umount/target /dev/loop2 ext4 rw,relatime

So we want to unmount the /dev/loop1 device here, but keep the /dev/loop2 mounted onto target.

Doing umount target will unmount the second volume, which is not the intended effect. Trying to umount the loop device itself gives:

$ sudo umount /dev/loop1 $ umount: /dev/loop1: umount failed: Invalid argument.

Is there some way to solve this conundrum?

Improve this question

1 Answer 1

Reset to default
1

Yes, there is.

Move that target mount elsewhere, unmount the original, and then move it back:

# mkdir target-1 # mount --move target target-1 # umount target # mount --move target-1 target

If the root or any other parent mounts of target have their propagation set to shared (the default when using systemd), a move mount will not work. In that case, you could bracket the mount --move by a pair of mount --make-rprivate /; ...; make --rshared / commands:

# mkdir target-1 # mount --make-rprivate /; mount --move target target-1; mount --make-rshared / # umount target # mount --make-rprivate /; mount --move target-1 target; mount --make-rshared /

It's a good idea to check that, though. Before and afterwards:

# grep -v shared /proc/self/mountinfo #
Improve this answer
5
  • Doesn't seem to work - I get "bad option; moving a mount residing under a shared mount is unsupported" when trying to do "mount --move target target-1". Commented Oct 16, 2021 at 9:45
  • I'm using Linux 5.14.9-arch2-1, if that matters. Commented Oct 16, 2021 at 9:46
  • 1
    the shared error is about having /home or / mounted shared by systemd on boot. It has to be turned off with mount --make-private Commented Oct 16, 2021 at 9:56
  • @A.B - If I use --make-private, then I get "wrong fs type, bad option, bad superblock, missing codepage or helper program, or other error" when trying to move afterwards. Tried using --make-private on both / and target. And findmnt shows that the "shadowed" target is still "shared". Commented Oct 16, 2021 at 10:11
  • 1
    Solved it! Had to use mount --make-rprivate / to recursively set all mounts to "private" propagation type, and that included the shadowed mount as well. Commented Oct 16, 2021 at 10:18

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.