Sometimes, I would like to unmount a usb device with
umount /run/media/theDrive, but I get a
drive is busy error.
How do I find out which processes or programs are accessing the device?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
Most of the time, the best command to use is lsof (“list open files”).
lsof +f -- /media/usb0
/media/usb0 is the mount point of the USB drive or other filesystem to unmount.
+f -- tells lsof to treat the subsequent argument as a mount point; it usually, but not always, manages on its own, so that
lsof /media/usb0 also works. This finds open files (even unlinked ones), memory mapped files, current directories, and some more obscure uses. You'll need to run the command as root to get information on other users' processes (and I think there are unices where
lsof has to be run as root).
There are uses that lsof will not find; these are uncommon on removable media. They include:
/foo/baris a mount point.
/foo/baris a mounted block device or loop-mounted regular file, or if it is the source of a Linux bind mount.
Another command that can serve in a pinch is fuser, which only lists PIDs of processes with open files on the device:
fuser -m /media/usb0
Processes with open files are the usual culprits. Display them:
lsof +f -- <mountpoint or device>
There is an advantage to using
/dev/<device> rather than
/mountpoint: a mountpoint will disappear after an
umount -l, or it may be hidden by an overlaid mount.
fuser can also be used, but to my mind
lsof has a more useful output. However
fuser is useful when it comes to killing the processes causing your dramas so you can get on with your life.
List files on
<mountpoint> (see caveat above):
fuser -vmM <mountpoint>
Interactively kill only processes with files open for writing:
fuser -vmMkiw <mountpoint>
After remounting read-only (
mount -o remount,ro <mountpoint>), it is safe(r) to kill all remaining processes:
fuser -vmMk <mountpoint>
The culprit can be the kernel itself. Another filesystem mounted on the filesystem you are trying to
umount will cause grief. Check with:
mount | grep <mountpoint>/
For loopback mounts (thanks Stephen Kitt), also check the output of:
Anonymous inodes can be created by:
These are the most elusive type of pokemon, and appear in
TYPE column as
a_inode (which is undocumented in the
lsof man page).
They won't appear in
lsof +f -- /dev/<device>, so you'll need to:
lsof | grep a_inode
For killing processes holding anonymous inodes, see: List current inotify watches (pathname, PID).
an unmount can hang in the
vx_softcnt_flush()call. The hang occurs because inotify watches increment the
i_countvariable and cause the
v_os_hold valueto remain elevated until the inotify watcher releases the hold.
For (at least) OpenBSD:
$ fstat /mnt/mountpoint
For example (using
doas to execute
fstat as root as we otherwise would only see our own processes):
$ doas fstat /usr/ports USER CMD PID FD MOUNT INUM MODE R/W SZ|DV NAME _pbuild make 15172 wd /usr/ports 3923598 drwxrwxr-x r 1536 /usr/ports/ _pbuild make 40034 wd /usr/ports 3923598 drwxrwxr-x r 1536 /usr/ports/
In this case, I would not be able to unmount
/usr/ports until user
_pbuild had finished running those two
This is a common pitfall: You su to a different user (either root or any other user), change to the directory of a mounted device, and then log out as that user. When you forget that you left in that directory, you can try and find until you are blind.
lsof does show the shell which current directory is using that device. You might want to su as that user again to change your directory.