Fix 'Cannot Unmount Device Target Is Busy' on Linux

You're trying to unmount a USB drive, an external disk, or maybe an NFS share, and you get:

umount: /mnt/data: target is busy

This usually happens when you plug in a drive, mount it, work on some files, and then try to yank it out. I see it all the time with USB flash drives on Ubuntu 22.04 or CentOS 7 boxes, and also when NFS mounts lose connection but the system still holds them open.

The root cause is simple: a process is accessing the filesystem. Could be a terminal open inside that mount point, a file being written to, or even a background service like updatedb scanning it. The kernel won't let you unmount because it would break that process. Makes sense, but it's annoying when you just want to eject your drive.

Step 1: Find What's Using the Mount

Don't panic. First, check if you have a shell open in that directory. Run:

lsof +f -- /mnt/data

Or use the simpler fuser:

fuser -v /mnt/data

The fuser output will list process IDs and names. For example:

                     USER        PID ACCESS COMMAND
/mnt/data:          root       1234 cwd   bash
                    root       5678 rtd   rsync

That cwd means a shell has its current working directory there. rtd means a process root directory is set there. Both block unmounting.

If fuser or lsof aren't installed (shame on you), install them. On Debian/Ubuntu:

apt install lsof

On RHEL/CentOS:

yum install lsof

Step 2: Kill the Offending Processes

You got a PID. Now kill it. Be careful what you kill — don't kill systemd or sshd. For a shell session, just exit it. If it's a file write, wait for it to finish.

If you must kill, use:

kill -15 1234

Wait a second, then check again with fuser. If it's stubborn, use kill -9 as last resort. I once had a client who had an rsync job stuck for hours because the NFS server went down. That needed kill -9.

Step 3: Force Unmount with umount -l

If you can't figure out what's holding it, or the process is system-critical (like systemd-logind), you can lazy unmount:

umount -l /mnt/data

The -l flag detaches the filesystem immediately. The kernel will clean up the open handles later when they close. This works great for USB drives you just want to yank out — but be careful, any unwritten data gets lost. I do this for external backup drives that I know are idle.

Step 4: Force Unmount with umount -f (NFS Only)

For NFS mounts that are stuck because the remote server disappeared, use:

umount -f /mnt/nfsdata

The -f flag forces unmount on NFS. Won't work on local filesystems. I've used this on a server where an NFS share hung for 10 minutes after a network outage. Saved a reboot.

Step 5: Check for Bind Mounts and Submounts

Sometimes the busy thing is another mount inside the mount point. Check with:

mount | grep /mnt/data

If you see lines like /dev/sdc1 on /mnt/data/subdir, unmount that first:

umount /mnt/data/subdir

I ran into this on a Raspberry Pi where Docker mounted a volume inside a mount point. Had to unmount the Docker volume first.

If It Still Fails

Try a reboot. I know it's lazy, but it works. If you can't reboot, check if systemd has the mount managed. Run:

systemctl list-units | grep mnt-data

If it shows a mount unit, stop it with:

systemctl stop mnt-data.mount

Also check for autofs or gvfs mounts — they often hold references. Finally, if nothing works and you really need to remove the device, use umount --force (same as -f) but only on NFS, or umount -l for local drives.

Bottom line: always check lsof or fuser first. Killing the right process takes 10 seconds. Rebooting takes 2 minutes. Choose wisely.