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?

1 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

  • "New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames" This is the information I was looking for. Do you have any additional links or references? Jan 8, 2019 at 12:16
  • @Jonathon check man umount. I'd need to google otherwise. Please post your findings if you do this.
    – Tom Hale
    Jan 9, 2019 at 23:04
  • I've read umount(2) several times recently. It says only "Perform a lazy unmount: make the mount point unavailable for new accesses, immediately disconnect the filesystem and all filesystems mounted below it from each other and from the mount table, and actually perform the unmount when the mount point ceases to be busy." But unfortunately this is less detail even than what you have provided. Jan 10, 2019 at 2:18
  • umount(8) says that a file system is busy "for example, when there are open files on it, or when some process has its working directory there, or when a swap file on it is in use." That doesn't sound like a definitive list, but is probably as good as I'll be able to find. Jan 10, 2019 at 2:23
  • I elaborated a bit on what you said, and added some other examples in this answer. Thanks for the information! Jan 10, 2019 at 4:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .