59

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?

60

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.

  • 24
    fuser -mv /path/to/mountpoint might be a more readable alternative for finding out processes using a mointpoint. – Riccardo Murri Oct 14 '10 at 17:59
  • @RiccardoMurri lsof | grep works better for me. fuser -mv seems to just dump 80+ of unrelated processes. I am using mount binded directories. – Ricky Boyce Aug 26 '17 at 10:27
  • 1
    umount -l is dangerous. mount -o bind a mode 000 empty directory on top instead, and clean up via lsof +f -- /dev/device. – Tom Hale Sep 3 '17 at 9:19
35

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
8

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
  • 1
    If you're going to do this, look into using -M for safety. – Tom Hale Aug 18 '17 at 8:41
  • @TomHale You might want to make clear which command -M should be applied to. – HSchmale Sep 5 '18 at 22:01
  • 1
    fuser: -M, --ismountpoint Request will be fulfilled only if NAME specifies a mountpoint. This is an invaluable seatbelt which prevents you from killing the machine if NAME happens to not be a filesystem. – Tom Hale Sep 8 '18 at 13:29
6

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>

Mountpoints

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.

  • There’s another one, loopback mounts: if you mount a file system, then mount a file on that file system using a loopback mount, you won’t be able to unmount the first file system, but nothing will show up in lsof. – Stephen Kitt Aug 20 '17 at 12:17
  • Cheers. Added to the Mountpoints section. – Tom Hale Aug 20 '17 at 12:50
5

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

1

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.

-2

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.

  • 2
    This answer is either incomplete or incorrect. I'm not sure which because it is also unclear. – hildred Nov 21 '16 at 2:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.