3

It appears that I cannot unmount dev after mounting it. I am running on Ubuntu 18.04.2 LTS with 4.15.0-1052-aws.

mkdir -p ~/jail/dev
pushd ~/jail
sudo mount --rbind /dev dev/
sudo umount  dev/
umount: /home/ubuntu/Code/conversations/jail/dev: target is busy.

Is there some way I can unmount it without rebooting my machine?

Alternately, is there a way I can mount it so that it is easier to unmount?

Update: This is the output of lsof /home/ubuntu/Code/conversations/jail/dev:

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
kdevtmpfs  55 root  cwd    DIR    0,6     2980    2 dev
kdevtmpfs  55 root  rtd    DIR    0,6     2980    2 dev
thanasisp
  • 8,122
merlin2011
  • 3,925
  • 1
    @airfishey The reason you can't unmount here, is there are submounts that need to be unmouted first. Because of --rbind, which is a recursive bind mount. – sourcejedi Nov 01 '19 at 20:40
  • Possible duplicates: https://unix.stackexchange.com/questions/452771/how-to-unmount-a-recursive-bind-mount-safely / https://unix.stackexchange.com/questions/263972/unmount-a-rbind-mount-without-affecting-the-original-mount / https://unix.stackexchange.com/questions/120827/recursive-umount-after-rbind-mount – sourcejedi Nov 01 '19 at 20:44

1 Answers1

11
mount --make-rslave dev/
umount -R dev/

The first command is required for safety. It will prevent the second command from unmounting subdirectories in the original /dev directory. This is due to "mount propagation".

The second command unmounts the whole tree recursively. This makes sure to unmount dev/pts, for example, before trying to unmount dev/. This is what caused the "target is busy" error.

As an optimization, you might use umount -l instead of umount -R. This might be useful when disassembling a whole tree of bind mounts.

`umount -R` on bind mounts takes a non-neglible amount of time, why?

However, care is needed if they are not all just bind mounts or virtual filesystems. The programs that had opened files will generally still be able to access them. Until they close them, the filesystem is still open. However, the filesystem is "detached" immediately. It won't clutter up the namespace anymore. It won't show up in findmnt and so on. This means you can't easily tell when the underlying device will be "safe to remove".

sourcejedi
  • 50,249
  • 1
    this issue probably appeared with systemd: debian - systemd - Known Issues and Workarounds - Shared bind mounts – A.B Nov 01 '19 at 21:04
  • @A.B That's the main reason you need the first command, yes. Note it's just following a design that comes from the kernel. The kernel just didn't update the default themselves, because they consider it very important that new kernels can still run old, unmodified userspace. – sourcejedi Nov 02 '19 at 10:12
  • 1
    @A.B thank you so much for directing us to that debian link. It finally explains why this mess happens in the first place. We see a bunch of people suggesting umount -l as a fix, but just using --make-rprivate or (better yet???) --make-rslave will avoid having to use umount -l. In fact, if you forgot to use the --make-r* flags when mounting, you can still remount using the flag. No more umount -l – user1593842 May 06 '22 at 11:56
  • @user1593842 good point. Helped confirm I wrote my answer "too clever". I think umount -l is useful here, but this is debatable and it maybe made it harder to see the most important point. Edited. – sourcejedi May 06 '22 at 18:45