Linux system errors
Resource Busy
Reviewed for reference consistency: August 11, 2026
the target exists, but another holder refuses to release it right now
What 16 Means
The 16 error on the Linux system errors indicates resource busy — the target exists, but another holder refuses to release it right now. This typically occurs due to unmounting a filesystem while processes still hold files or directories open on it.
Exit code 16 corresponds to EBUSY, 'Device or resource busy'. The defining fact is contention: the resource exists, is healthy, and simply has another owner. Unlike missing files or bad arguments, nothing is broken — the operation arrived at a busy moment, and the kernel declined to yank the resource out from under its current user.
How to fix 16
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Name the processes holding the mount
fuser identifies every process with open files or a working directory on the target, the exact list an unmount waits for.
fuser -vm /path/to/mountEnumerate open files on the filesystem
lsof lists each open file under the mount with its owning process, useful when the holder list is long.
lsof +f -- /path/to/mountConfirm the current mount state
The mount table shows whether the target is mounted read-write and from where, ruling out state confusion before hunting holders.
mount | grep /path/to/mount
Technical Background
EBUSY is about contention, not absence. The device is present, the filesystem is mounted, the file is exactly where it should be — and someone else is using it. The kernel could service the request by force, and EBUSY is the design decision not to: removing a mounted filesystem from under a running process would corrupt more than convenience.
Volume lifecycle is where most people meet it. The classic unmount failure is not dramatic at all: a terminal parked in a subdirectory, a background indexer, a log tail. Each is an open reference, and the unmount fails politely until the last one lets go.
The same contract runs deeper in the kernel: modules with live references, devices claimed by drivers, resources mid-operation. In every case the report answers the same question — not 'what is broken' but 'who is holding it'.
Common Causes
- Unmounting a filesystem while processes still hold files or directories open on it
- A device claimed by a driver or another process, refusing a competing operation
- A kernel module or resource with an outstanding reference count blocking removal
Typical Scenarios
- An unmount of a data volume failing because a shell session still sits in a directory on it
- A disk-detachment request refused while a database keeps the device open
- A module removal declined because loaded code still holds references into it
What to Know
The holder list is the whole diagnosis: which processes have open references on the target. Once the holders are named, the choice is between finishing them politely and moving the resource's user elsewhere.
Frequently Asked Questions
Common questions about Linux 16 error
Process-oriented tools answer directly: fuser lists the processes using a mount point or file, and lsof enumerates every open file on the filesystem. Either names the holder that must finish first.
A shell sitting in a directory counts as holding it open — its working directory is a reference the kernel respects. The unmount waits until the reference is gone, which is why idle sessions block detached volumes.
No. Permissions decide who may operate; EBUSY (exit 16) says the operation is fine in principle but the resource is mid-use. The distinction matters: waiting or stopping the holder resolves it, permission changes do not.
Related Error Codes
No Space Left — the filesystem ran out of data blocks or of inodes
Permission Denied — the process does not have permission to access the resource
No Such Device — the operation targets hardware or a driver that is not present
Read-Only Filesystem — the mount itself refuses writes, so permission changes cannot help
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
Git paused the merge because it cannot automatically resolve overlapping changes.
Git aborted the merge to protect uncommitted changes in your working directory.
Git prevented a branch switch because it would overwrite unsaved changes in your working directory.
Git aborted the merge because it would overwrite untracked files in your working directory.