`umount /data` returns "target is busy". What kinds of references make a Linux filesystem busy, and what does `umount -l` actually do that a plain unmount does not?
answer
- something still holds a reference
- cwd counts, so do deleted-but-open files
- lazy detaches the path, not the filesystem
- the device stays held afterwards
basics
~20 sA filesystem is busy while anything still references it: open file descriptors, a process whose working directory or root is inside it, memory-mapped files, an active swap file, or a submount. umount -l (MNT_DETACH) only detaches the subtree from the path namespace — the filesystem stays alive until the last reference goes away.
solid answer
~60 sEBUSY means the kernel still holds references into that mount. The usual culprits are open file descriptors — including descriptors on files that have already been deleted — a process whose current working directory or root is inside the tree, a memory-mapped file, a swap file on the filesystem, a loop device backed by it, and anything mounted underneath, including a bind mount of the same filesystem somewhere else. The right move is to find and stop the holder. `umount -l` is not that: it performs a lazy detach, removing the subtree from the path namespace immediately so nothing new can reach it, while the filesystem itself stays mounted internally until the last reference is dropped. That means the path looks free but the block device is still held, so a following `cryptsetup close`, `losetup -d` or storage detach still fails, and writes in flight are still being flushed to a device you may be about to yank. `umount -f` is a different thing again — it is mainly meaningful for network filesystems, where it aborts pending requests to an unresponsive server.
go deeper
Know that a filesystem cannot be unmounted while something is using it, and that the most common cause is a shell whose current directory is inside the mount.
List the reference kinds — open descriptors including deleted files, cwd or root, memory mappings, swap, loop devices and submounts — and explain that a lazy unmount detaches the path while the filesystem stays alive.
Show judgment under pressure: remount read-only to stop writes first, identify and stop the holder, and refuse to lazy-unmount immediately before detaching or closing the underlying device.
Treat repeated busy unmounts as a design signal — which services hold data paths open, whether they can drain on demand, and how storage detachment is sequenced in runbooks so an operator is never tempted to hide the problem.
## What "busy" means to the kernel A mount cannot go away while anything still refers to objects inside it. `umount(2)` returns `EBUSY` and the tool prints `target is busy`. The references that count: - **Open file descriptors.** Any process holding a file or directory open. This includes descriptors on files that have already been unlinked — the name is gone, the inode is not, and the filesystem is pinned until the descriptor closes. - **A process's working directory or root.** A shell sitting in `/data`, or a daemon that `chdir`ed there at startup, is enough. Your own shell is the most common cause and the most embarrassing. - **Memory mappings.** A file mapped with `mmap` — an executable running from that filesystem, a database's data file, a mapped log — keeps it busy even if the descriptor was closed after mapping. - **A swap file** on the filesystem, still active. - **A loop device** whose backing file lives there. - **Submounts.** Anything mounted underneath the mount point. Unmount from the leaf upward, or use `umount -R` to walk the subtree. - **Another mount of the same filesystem.** Bind mounts, and copies of the mount in another mount namespace, are independent references. This is the one that catches people: every path has been cleared and the device is still held, because a second namespace has its own copy of the mount. ## The three ways out **Stop the holder.** Identify the process keeping the reference and stop or restart it, then unmount normally. This is the only option that actually completes the unmount, flushes the filesystem and releases the device. **Remount read-only first.** `mount -o remount,ro /data` stops all further writes and forces a flush while leaving the mount in place. It usually succeeds where unmount fails, because it does not require the references to go away. On a filesystem you suspect is failing, this is the fastest way to make the situation stop getting worse while you work out who is holding it. **Lazy unmount.** `umount -l` passes `MNT_DETACH`. The kernel removes the mount from the path namespace right away — the mount point becomes free, whatever was underneath it becomes visible again, and no *new* opens can reach the filesystem — but existing references keep it alive. The filesystem is unmounted for real only when the last one is dropped. ```bash umount /data # umount: /data: target is busy. mount -o remount,ro /data # stop writes without detaching umount -l /data # MNT_DETACH: path freed, filesystem still alive ``` ## Why lazy unmount is a trap, not a fix It looks like success — the command returns 0 and the path is gone from `findmnt` — so it gets used as a reflex. The consequences: - **The device is still held.** `cryptsetup close`, `losetup -d`, `vgchange`, detaching a cloud volume or removing a SAN LUN will still fail or, worse, succeed while the kernel still has dirty pages for it. - **The writer keeps writing.** A process with a descriptor into a lazily detached filesystem continues to write into it. Pulling the storage out from under it corrupts data and can wedge the process in uninterruptible sleep. - **The problem becomes invisible.** You no longer have a path to inspect, so the holding process is now much harder to identify. - **Space is not reclaimed.** Nothing is freed until the references drop, so if you did this to recover disk space you have not. Use it when you genuinely want the path free and you are content for the filesystem to drain on its own — for example detaching a hung network mount so that new callers get an error instead of blocking. Do not use it as a step before physically or logically removing storage. ## What -f actually does `umount -f` passes `MNT_FORCE`, and its meaning is filesystem-specific. For NFS it aborts in-flight requests so that processes stuck waiting on a dead server get an error and can be killed. For a local filesystem it does very little; it does not override references and it is not a stronger version of the lazy flag. The two are also frequently combined by superstition rather than reason — on a hung NFS mount `-f -l` is a defensible pairing, on a local ext4 it just conceals the real question, which is who has the filesystem open. ## A practical order of operations When a production unmount fails: remount read-only to stop the damage, identify the holder and stop it cleanly, then unmount. Reach for the lazy flag only when you have decided that leaving the filesystem to drain in the background is acceptable, and never immediately before you take the underlying device away.
- Every process using /data has been stopped and the unmount still fails. What else can be holding it?Another mount of the same filesystem. A bind mount elsewhere in the tree is an independent reference, as is a copy of the mount that exists in another mount namespace — a service started with its own namespace, or a container runtime, can hold a filesystem the host thinks nobody is using. Check for submounts under the mount point too, and unmount the whole subtree rather than just the top.
- You need to unmount a filesystem whose backing device has already failed and processes are stuck. What is the sequence?Expect the processes to be in uninterruptible sleep, so killing them may not work until the I/O errors out. Remount read-only if it still responds, then decide: a lazy detach frees the path so nothing new blocks, but the kernel still holds the dead device. For a hung network mount, a forced unmount aborts in-flight requests so the waiting processes get errors and become killable, which is usually the step that unblocks the rest.
- Does umount -l free the disk space used by files on that filesystem?No. Nothing is released until the last reference to the filesystem is dropped, at which point the real unmount happens. Lazy detach only removes the subtree from the path namespace — it makes the mount point available and hides the filesystem from new callers. If the goal was to reclaim space or release the device, the lazy flag accomplishes neither.
saying these in an interview costs you the question
- Reaches for umount -l as the standard fix for busy
- Thinks -f is a stronger version of -l
- Forgets their own shell's working directory is the holder
- Believes lazy unmount releases the block device
- Assumes stopping the service clears mounts held in another namespace