How do I find out which processes are preventing unmounting of a device?

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?

Asked By: Stefan


Use lsof | grep /media/whatever to find out what is using the mount.

Also, consider umount -l (lazy umount) to prevent new processes from using the drive while you clean up.

Answered By: Peter Eisentraut

You can use lsof like Peter said, or if you’re sure you just want to kill all those things and unmount it, you can probably do something like:

fuser -Mk /mnt/path
umount /mnt/path
Answered By: pioto

Most of the time, the best command to use is lsof (“list open files”).

lsof +f -- /media/usb0

where /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:

  • mount points: you can’t unmount /foo if /foo/bar is a mount point.
  • mount devices: you can’t unmount /foo if /foo/bar is a mounted block device or loop-mounted regular file, or if it is the source of a Linux bind mount.
  • NFS export: lsof won’t detect that a tree is exported by a kernel NFS server.

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

If you use GNOME, unmounting via Nautilus will display a message stating which process is still using the drive, and the file it’s using.

alt text

Answered By: tshepang

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.

Answered By: Johannes Linkels

Open files

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:

losetup -la

Anonymous inodes (Linux)

Anonymous inodes can be created by:

  • Temporary files (open with O_TMPFILE)
  • inotify watches
  • [eventfd]
  • [eventpoll]
  • [timerfd]

These are the most elusive type of pokemon, and appear in lsof‘s 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).

inotify watches (Linux)

This comment explains why inotify shouldn’t prevent an unmount, but this note describes the situations in which it will:

an unmount can hang in the vx_softcnt_flush() call. The hang occurs because inotify watches increment the i_count variable and cause the v_os_hold value to remain elevated until the inotify watcher releases the hold.

Answered By: Tom Hale

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 make processes.

Answered By: Kusalananda

I just want to add one other scenario to look out for.

Is your partition being exported as an NFS mount?

If so, you need to remove it from /etc/exports and run sudo exportf -ra

Then you should be able to umount the partition. Might seem obvious, but worth mentioning.

Answered By: twhitney
Categories: Answers Tags: , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.