Why is lazy MNT_DETACH or `umount -l` unsafe / dangerous?

Question

I've read in a few places that umount -l is unsafe:

In an answer by @cas:

don't use umount's --lazy option if you care about when the external drive can be safely unplugged

A comment by @frostschutz:

umount --lazy is not safe and can not be made safe. [...]

This util-linux comment by Ruediger Meier:

You should avoid using umount -l at all. Just kill all processes which are using /tmp/mountpoint and then umount without option -l.

Why is umount -l unsafe / dangerous?

Is there a way to make it safe?

Answer 1

A lazy unmount creates a Schrödinger's cat mount

• You cannot know if the the device is actually unmounted or not
• The "unmounted" filesystem remains accessible in some circumstances
• The "unmounted" filesystem is not accessible in some circumstances

There is a false sense of security: it appears that the filesystem has been unmounted, but in reality it has only been hidden from the file namespace / heirarchy.

• Processes can still write via open file descriptors
• New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames

This means that if you umount -l /media/hdd you will no longer be able to access /media/hdd/dir/file (absolute pathname) but if you have a process with working directory /media/hdd it will still be able to create new processes which can read/write ./dir/file (relative pathname).

If you try to unmount the device, you will a confusing message:

# umount --force --all-targets /dev/sdb2
umount: /dev/sdb2: not mounted

This makes it look like the device has unounted, but there still can be processes writing to the disk.

Since there are various non-obvious situations that can cause umount to block, the filesystem may still not be unmounted even though lsof +f -- /dev/device shows nothing.

You'll never know if the filesystem actually unmounts. There's no way to find out.

Removable devices

If you do umount -l a removable disk, you're in limbo-land: you can't be sure that all pending data has been written to disk.

The best you can do after a umount -l is to ensure all writing completes and prevent future writing, but you still can't guarantee that it has been unmounted.

With removable devices, if the device isn't properly unmounted, strange behaviour can result the next time it is plugged in:

• The device will get an incremented device name, ie /dev/sdb becomes /dev/sdc. The kernel log messages may still refer to /dev/sdb even though that device no longer exists as a file under /dev. (The only way I know to resolve this is to reboot.)

• btrfs corruption can result. btrfs expects that only one filesystem with a given UUID is present at one time. The kernel still sees the same UUID available on the phantom device and the new device. (I had to rebuild my btrfs backup HDD).

systemd gotchas

• It seems that a lazy unmount or MNT_DETACH is caused by using either x-systemd.mount-timeout= in /etc/fstab or using TimeoutIdleSec= in an Automount file.

• Avoid the above systemd options especially is using btrfs. I learned from bitter experience (see btrfs reference above).