18

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?

Tom Hale
  • 30,455

1 Answers1

17

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

Tom Hale
  • 30,455
  • "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? – Jonathon Reinhart Jan 08 '19 at 12:16
  • @Jonathon check man umount. I'd need to google otherwise. Please post your findings if you do this. – Tom Hale Jan 09 '19 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. – Jonathon Reinhart Jan 10 '19 at 02: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. – Jonathon Reinhart Jan 10 '19 at 02:23
  • I elaborated a bit on what you said, and added some other examples in this answer. Thanks for the information! – Jonathon Reinhart Jan 10 '19 at 04:11
  • @JonathonReinhart if a process has its cwd or root on a lazily unmounted fs or has an open handle to a directory there, then that process and other processes can access them too, via /proc/<PID>/cwd, /proc/<PID>/root and /proc/<PID>/fd/<FD> respectively. Those are absolute paths, and the files are accessible by name, so the list of "things you can't do" from the linked answer is pretty pointless and misleading. –  Jan 26 '21 at 18:58
  • @user414777 All of those are symlinks. So yes, while they are absolute paths, they are are not absolute paths to the original mountpoint. I appreciate a certain level of precision, but can't help but think the level of pedantic that your statement is on serves nothing more than to be technically correct, yet mostly unhelpful. The point is, after a lazy unmount, you can't use the damn mountpoint anymore. If you think my answer is "pointless and misleading" then I encourage you to submit your attempt at clearing up the documentation. – Jonathon Reinhart Jan 27 '21 at 03:46
  • @JonathonReinhart if you bothered to test it before calling people pedantic, you would've seen that those "symlinks" are NOT really symlinks, as a cd to /proc/<PID>/cwd => / (where PID is a process whose cwd is on an unmounted fs) will not change to your root directory, but to the actual cwd of that process, within the unmounted fs. And yes, you can also use that directly e.g. as /proc/<PID>/fd/<DIRFD>/subdir/file. Even though it's the "culture" here and I should've get used to it, this total disregard for the facts still pisses me off. Mightily. –  Jan 27 '21 at 08:23
  • @user414777 I apologize, and retract my comment. I'm not even sure what I was thinking, because I even knew about that behavior, despite the confusing /. I think I stumbled on this behavior and remembered being surprised when working on gitlab-pages. But if you look at this thread, I clearly didn't 100% understand it. And re-reading that thread led me to post my (again) inaccurate comment above. – Jonathon Reinhart Jan 27 '21 at 18:11
  • @user414777 Now that you've sufficiently pounded it into my head, it's quite clear: A lazy unmount is essentially just like an unlink for the FS from its original mountpoint. Other than that disconnect, the mountpoint is still completely viable and usable. Again, sorry for the stubbornness and thanks for setting me straight. – Jonathon Reinhart Jan 27 '21 at 18:18
  • @user414777 With that said, I think only a minor correction to my answer is required: You can do anything with the mountpoint mounted filesystem, except open new files/directories by absolute path from the original mountpoint**. Do you concur? Feel free to leave any feedback at that answer, as this conversation has become a little detached. – Jonathon Reinhart Jan 27 '21 at 18:20