🚨 Linux Error: Device or resource busy — Cause, Fix, and Troubleshooting Guide

Summary

Device or resource busy maps to the errno EBUSY (16). The kernel refuses to unmount, remove, or otherwise release a resource because something still holds it open — an open file, a running process with its working directory inside the mount, a nested submount, or an active loop/swap/LVM binding. The string is identical whether it comes from umount, rm, kill, or losetup; the fix is always to find and release the holder.

Common Symptoms

• umount /mnt/data fails with umount: /mnt/data: target is busy.
• rmmod or modprobe -r reports the module is in use.
• rm -rf on a directory returns Device or resource busy for a specific file.
• Detaching a loop device or deactivating an LVM volume fails while it is still open.
• A kill on a zombie or uninterruptible (D state) process appears to do nothing.

Most Likely Causes of the ‘Device or resource busy’ Error

The Device or resource busy error almost always means an open handle against the resource. In production, ranked by frequency:

1. A process has an open file or a CWD inside the mount. The most common unmount blocker — a shell, log tailer, or daemon whose current directory or an open fd lives under the mount point.
2. A nested submount or bind mount. You cannot unmount a parent while a child (/mnt/data/sub, a bind mount, or an overlay) is still mounted.
3. The filesystem is exported via NFS or held by a container. nfsd, a Docker/containerd bind, or a systemd namespace pins it.
4. A loop, swap, or LVM/dm binding is active. losetup -d, swapoff, or lvremove fails while the device is in use.
5. Busy-file deletion under a live mount (rm on a file mmapped or held open by a running binary — e.g. deleting a running executable’s backing file).

Quick Triage

# What is the mount and is it still mounted?
findmnt /mnt/data
# Who holds it open? (fast pass)
sudo fuser -vm /mnt/data
# Are there nested mounts underneath?
findmnt -R /mnt/data

If fuser -vm lists PIDs, that is your answer — one of those processes is pinning the mount.

Diagnostic Commands

# List every process with an open file/CWD under the mount
sudo lsof +D /mnt/data
# Faster, mount-scoped view (open files, mmaps, CWDs, roots)
sudo fuser -vm /mnt/data

lsof +D walks the whole tree (slow but exhaustive); fuser -vm is quicker and flags the access type (c=cwd, m=mmap, f=open file, r=root).

# Confirm the exact mount source, target, and options
findmnt /mnt/data
mount | grep /mnt/data
# Reveal nested submounts / bind mounts that block the parent
findmnt -R /mnt/data
cat /proc/mounts | grep /mnt/data

# Loop, swap, and device-mapper holders
losetup -a
swapon --show
sudo dmsetup ls --tree

If nothing shows in lsof/fuser but unmount still fails, suspect a kernel-side holder: an NFS export (exportfs -v), a container bind mount in another mount namespace, or an mmap that lsof +D skipped — check sudo lsof /mnt/data (without +D) too.

Fix / Remediation

1. Identify and gracefully stop the holder. Read the PIDs from fuser -vm /mnt/data, then stop the owning service cleanly:

   sudo fuser -vm /mnt/data
   sudo systemctl stop <service>   # preferred over killing PIDs directly

2. Change out of the directory. If your own shell is the holder (c = cwd), simply cd / and retry the unmount.

3. Unmount nested submounts first, deepest last, then the parent:

   findmnt -R /mnt/data
   sudo umount /mnt/data/sub
   sudo umount /mnt/data

4. Release loop/swap/LVM bindings if those are the blocker:

   sudo swapoff /dev/mapper/vg-swap
   sudo losetup -d /dev/loop3

5. If the holder cannot be stopped, use a lazy unmount. umount -l detaches the tree immediately and cleans up when the last reference closes — the safe way to clear a stuck mount without killing live processes:

   sudo umount -l /mnt/data

   Warning: umount -f (force) can interrupt in-flight writes and cause data loss or corruption, and kill -9 on a process mid-write can leave files half-written. Prefer stopping the service cleanly or umount -l first. Only force-unmount a broken/dead mount, and back up unsynced data where possible.

6. Last resort — force unmount a genuinely dead mount (e.g. a hung network filesystem that no lazy unmount will clear):

   sudo umount -f /mnt/data

Validation

# Mount should be gone
findmnt /mnt/data || echo "unmounted cleanly"
# No lingering holders
sudo fuser -vm /mnt/data 2>&1 | grep -q . && echo "still busy" || echo "clear"

A clean unmount returns no findmnt entry and no fuser PIDs.

Prevention

• Never cd into a mount point in long-lived scripts; use absolute paths and return to / before unmounting.
• In systemd units, express storage dependencies with RequiresMountsFor= so services stop before the mount is torn down.
• Tail logs and run backups against paths that you can quiesce; stop the writer before unmounting.
• Monitor for uninterruptible (D-state) processes — they often signal a hung backing device that will make unmount EBUSY.
• Keep an unmount-order runbook for stacked storage (bind mounts, overlays, loop devices) so teardown happens deepest-first.

Related Errors

• Transport endpoint is not connected
• Stale file handle
• Input/output error
• mount: wrong fs type, bad option, bad superblock
• Read-only file system

Final Notes

Device or resource busy is a reference-counting problem, not a corruption problem: the kernel will not free a resource that something still holds. Find the holder with fuser -vm or lsof +D, unmount nested filesystems deepest-first, and reach for umount -l when you cannot stop the process. Save umount -f and kill -9 for genuinely dead mounts, and only after protecting unsynced data.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.