🚨 Linux Error Guide: 'umount: target is busy' — Free a Busy Mountpoint

Overview

The kernel refuses to unmount a filesystem while anything is still using it, and umount reports the mountpoint as busy:

umount: /mnt/data: target is busy.

Newer util-linux phrases it with a hint, but the meaning is identical:

umount: /mnt/data: target is busy.
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)

“Busy” means at least one reference to the filesystem is still open: a process with its working directory inside the mount, an open file, a mapped executable, a swap file, or another mount stacked on top (including bind mounts). Until every reference is released, the unmount cannot complete.

Symptoms

• umount /path fails with “target is busy” while other filesystems unmount fine.
• Detaching a USB/SAN disk, resizing a volume, or a shutdown script hangs on the unmount.
• lsof/fuser list one or more PIDs against the mountpoint.
• The mount has a bind mount or an overlay/container layer stacked on it.
• A user’s shell is sitting with cd inside the directory.

Common Root Causes

• A process has files open under the mount (a daemon writing logs, a database, an editor).
• A shell’s working directory is inside the mount. Even an idle cd /mnt/data holds it busy.
• A running executable or library is mapped from the filesystem (mmap), so it counts as in use.
• A stacked or bind mount exists on or under the path; the child mount pins the parent.
• Swap on the filesystem. swapon against a file on the mount keeps it busy until swapoff.
• NFS/kernel references or a container/overlay using the mount as a lower/upper layer.

Diagnostic Workflow

Identify exactly what is holding the mount. fuser -m lists PIDs using the whole filesystem; lsof names the files:

sudo fuser -vm /mnt/data       # -m = whole mount; shows PIDs and access type
sudo lsof +f -- /mnt/data      # open files on that filesystem
sudo lsof +D /mnt/data 2>/dev/null | head

Catch the sneaky cases — a shell parked inside, or a stacked/bind mount:

ls -l /proc/*/cwd 2>/dev/null | grep /mnt/data     # processes cwd'd into it
findmnt -R /mnt/data                                # sub-mounts / bind mounts
grep /mnt/data /proc/mounts

Rule out swap on the filesystem:

swapon --show
cat /proc/swaps | grep /mnt/data

Example Root Cause Analysis

An operator needed to unmount /mnt/backup to grow the underlying LVM volume, but every umount returned “target is busy,” and the obvious rsync job had already finished.

fuser -vm /mnt/backup returned no processes at all, which was misleading. findmnt -R /mnt/backup then revealed the real problem: a bind mount, /mnt/backup/db -> /var/lib/db-snapshots, had been created earlier and never removed. The child bind mount pinned the parent, so the parent could never be unmounted while it existed.

Unmounting the bind mount first (umount /mnt/backup/db) released the reference, and umount /mnt/backup then succeeded cleanly. A lazy unmount (umount -l) would have appeared to “work” but left the filesystem detached-yet-referenced, risking a corrupt LVM resize — so the team deliberately resolved the real reference instead of forcing it.

Prevention Best Practices

• Before unmounting, stop or reconfigure services that use the path; don’t rely on them having finished.
• Never umount -f/-l a filesystem you’re about to resize, fsck, or physically remove — resolve the real reference so the unmount is truly clean.
• Track bind mounts and container/overlay layers; tear down child mounts before their parents.
• In scripts, cd / (or use a subshell) before unmounting so the script’s own working directory isn’t holding the mount.
• Move swap off data filesystems, and swapoff before unmounting anything hosting a swap file.

Quick Command Reference

# Who/what is using the mount
sudo fuser -vm /mnt/data
sudo lsof +f -- /mnt/data

# Find shells cd'd inside and any sub/bind mounts
ls -l /proc/*/cwd | grep /mnt/data
findmnt -R /mnt/data

# Gracefully signal the holders, then unmount
sudo fuser -k -TERM -m /mnt/data     # send SIGTERM to users of the mount
sudo umount /mnt/data

# Last-resort options (NOT before resize/fsck/removal)
sudo umount -l /mnt/data             # lazy: detach now, clean up when free
sudo umount -f /mnt/data             # force: mainly for unreachable NFS

Conclusion

“umount: target is busy” means the filesystem still has a live reference — an open file, a shell’s working directory, a mapped binary, swap, or a stacked/bind mount. Use fuser -m, lsof, /proc/*/cwd, and findmnt -R to find the exact holder, then stop the process or unmount the child first. Reserve umount -l/-f for genuinely stuck or unreachable mounts (like dead NFS), and never force an unmount you’re about to resize or fsck — a clean unmount is the only safe one.