Fix 'umount: target is busy' on Linux USB drive
The kernel says the USB mount point is in use. Start with the lazy unmount, then find the culprit process. Works on Ubuntu, Fedora, Debian.
30-Second Fix: Try the Lazy Unmount
This is your first go-to move. Almost always does the trick if the drive isn't actively being written to. The lazy unmount (-l) tells the kernel to detach the filesystem immediately but clean up any pending I/O in the background. You won't lose data — it just unmounts now, finishes the cleanup later.
sudo umount -l /mnt/usbReplace /mnt/usb with your actual mount point. If that works, you're done. The drive will unmount, and you can yank it after the LED stops blinking. If it spits out the same error, move to the next step.
5-Minute Fix: Find and Kill the Blocking Process
The culprit is almost always a file open by a shell, a file manager, or a background daemon. You need to find it and kill it. Two tools for this: lsof and fuser. I use fuser because it's faster and gives you PIDs directly.
sudo fuser -vm /mnt/usbThis prints the PIDs of any processes using that mount point. You'll see something like 1234 next to a cwd (current working directory) or a txt (executable). Kill the process:
sudo kill -9 1234Replace 1234 with the PID. Then try unmounting again:
sudo umount /mnt/usbIf fuser isn't installed, use lsof:
sudo lsof | grep /mnt/usbSame deal — grab the PID and kill it. One warning: killing a file manager like Nautilus or Dolphin might close all open file dialogs. Save your work first. Also don't bother with umount -f here — it rarely helps on modern kernels. Use the lazy unmount instead.
15-Minute Fix: Remount Read-Only, Then Unmount
Sometimes a process is stuck in an uninterruptible sleep state (D state) writing to the drive. You can't kill those. The workaround is to remount the filesystem as read-only, which forces any pending writes to fail gracefully, then unmount.
sudo mount -o remount,ro /mnt/usbIf that command succeeds — no error — then immediately unmount:
sudo umount /mnt/usbIf the remount fails because something is still writing, you need to find that specific process. Use strace to see what's hanging:
sudo strace -p PIDReplace PID with the stuck one from fuser. You'll probably see it stuck on a write() syscall. In that case, reboot. Yes, it's heavy-handed, but it's the only safe way. A hard power-off corrupts the filesystem. A reboot at least syncs the journal.
What if none of these work?
You might have a kernel bug or a failing USB controller. Try the same drive on another USB port. If that fails too, check dmesg | tail for I/O errors on the SCSI device. Replace the cable or the drive. But 9 times out of 10, the lazy unmount or fuser kill does it.
Quick reference table
| Tool | Command | When to use |
|---|---|---|
| Lazy unmount | umount -l |
First try — safe, no data loss |
| fuser | fuser -vm |
Find blocking processes fast |
| lsof | lsof | grep |
Fallback if fuser missing |
| Remount ro | mount -o remount,ro |
Kill-stealing processes or D-state |
Pro tip: Alwayssyncbefore unmounting. I've seen this catch a few edge cases where the buffer cache was sitting on data. Runsync, wait a second, then unmount.
That's it. You'll fix this in under a minute most days. The lazy unmount is your friend — remember it.
Was this solution helpful?