"umount: target is busy": find what holds the filesystem, and when umount -l is safe

1. Check your own shell first

A terminal whose current directory is inside /data keeps it busy, and it’s the most common cause. Try it in the terminal, which starts in just that situation:

pwd
cd ~
sudo umount /data

Remember your other windows too: another terminal or tmux pane, an editor, or a file manager showing that folder.

2. Find the process

sudo lsof +f -- /data

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
rsync   2143 root  cwd    DIR   8,17     4096    2 /data
python3 2288 app     3w   REG   8,17   841234   13 /data/logs/app.log

FD tells you how it’s held: cwd is a current directory, a number like 3w is an open file, and txt is a program running from there. If you can’t use lsof, fuser also works, and it’s usually installed with the psmisc package:

sudo fuser -vm /data

                     USER        PID ACCESS COMMAND
/data:               root     kernel mount /data
                     root       2143 ..c.. rsync
                     app        2288 F.... python3

-m means “anything on this filesystem”, and that kernel line is normal: it’s the mount itself. In ACCESS, c is a current directory, F is a file open for writing, f for reading, and e is a running program.

3. Stop it

A service? Stop it properly, as kill won’t do, because systemd may restart it:

sudo systemctl status 2288
sudo systemctl stop myapp

A plain process? Ask it to exit:

sudo kill 2143

fuser can do this for every process at once, after showing you who they are. Check the list first, as this ends everything on the filesystem:

sudo fuser -kvm /data

Then unmount:

sudo umount /data

Also check for services you might not think of, such as Docker with its data or volumes there, PostgreSQL, swap files (swapon --show, and then sudo swapoff /data/swapfile), or an indexer or antivirus scanning it.

4. lsof shows nothing

It’s still busy, and no process holds it. Here’s what’s left:

Something’s mounted inside it. Unmount those first, deepest first:

findmnt -R /data

TARGET            SOURCE     FSTYPE
/data             /dev/sdb1  ext4
└─/data/backups   /dev/sdc1  ext4

sudo umount /data/backups
sudo umount /data

sudo umount -R /data does this for the whole tree.

A bind mount or another namespace. A container’s mount can keep it alive, and it’s invisible from the host’s lsof. Find them with:

sudo grep -l '/data' /proc/*/mountinfo 2>/dev/null
findmnt -o TARGET,SOURCE | grep data

The number in each path is a process ID. Often it’s a container: docker ps, then stop that one. On Kubernetes, it can be a pod that still uses the volume.

LVM, RAID or encryption on top. Those hold the device rather than the mount:

lsblk

5. NFS: when the server’s gone

If the NFS server has disappeared, umount may hang or report busy, and lsof itself can hang. Try these, in order:

sudo umount -f /mnt/share    # force: for NFS, gives up on the unreachable server
sudo umount -l /mnt/share    # lazy: see below

lsof -b avoids blocking on it. Mount with soft, or at least with _netdev and x-systemd.automount in /etc/fstab, so that a missing server doesn’t stall your machine at boot.

6. umount -l: lazy unmount

sudo umount -l /data

It removes the mount from view right away, and really finishes when the last process lets go. It’s not a way to skip finding the cause:

• Programs keep writing to the disk through files they already have open.
• The device can’t be safely unplugged or checked. It isn’t released yet, and fsck on it can corrupt data.
• A new mount on the same folder can hide that it’s still in use.

It’s reasonable for a dead NFS server, or to get out of the way before a reboot. It’s the wrong way to prepare for fsck or for removing a disk.

umount -f is not a stronger version for local disks. On ext4 or XFS, it generally does nothing more, and still reports busy.

7. Then check it worked

findmnt /data

No output means it’s unmounted. For something that should stay that way, comment out its line in /etc/fstab, or the next boot mounts it again, or fails if the disk’s gone. To remount from fstab, use sudo mount /data. If you were unmounting to repair it after an error, see read-only file system.