35

When I do

sudo umount /media/KINGSTON

I got

umount: /media/KINGSTON: device is busy.

I close all the windows and make sure all shell are pointing to other directories. How can I find which process is preventing the umount?

3
  • 3
    I think you've got a typo here, I doubt that command returned "How do I find out which process is eating up my bandwidth?"... ;) any chance you could edit the question please?
    – 8128
    Nov 6, 2010 at 7:52
  • See also unix.stackexchange.com/questions/3109/…
    – pevik
    Aug 31, 2020 at 15:57
  • The answers given all seem fine for the basic case, but in this edge case, it doesn't work: If you mount a given thing (say, a storage device) to more than one mount point, then both lsof and fuser report all the processes using the device regardless of the mountpoint. You can't pinpoint which processes are only using the particular mount point you're trying to umount.
    – Pistos
    Mar 1, 2022 at 18:38

5 Answers 5

34

open a terminal:

fuser -c /media/KINGSTON

It will output something like this:

/media/KINGSTON/: 3106c 11086

This will give you the pid of the processes using this volume. The extra character at the end of pid will give some extra info. ( c in 3106c)

c - the process is using the file as its current working directory
m - the file is mapped with mmap
o - the process is using it as an open file
r - the file is the root directory of the process
t - the process is accessing the file as a text file
y - this file is the controlling terminal for the process

So to unmount just kill that pids and re-try the unmount

sudo kill -9 3106 11086
sudo umount /media/KINGSTON

Note: To find the exact application name of these pids you may use this command

cat /proc/<pid>/cmdline

For example : cat /proc/11086/cmdline

this will output something like below.

    evince^@/media/KINGSTON/Ubuntu-guide.pdf^@

Hope this will help

3
  • 2
    fuser -ck would also kill it. Nov 6, 2010 at 8:05
  • 3
    I would suggest killing them without the -9 option first, to give those applications the chance to cleanly shut down. And I would suggest using ps <pid> instead of editing files in /proc to see the command name and arguments. Nov 6, 2010 at 14:55
  • I follow your procedure to find the process, it is Thunar--deamon. There are no extra character giving extra info. I have not kill it yet, I am worring about the impact it could have on other thing running. Nov 6, 2010 at 18:53
8

The most useful tool is lsof Install lsof. It shows what files are in used by what processes. If /media/KINGSTON is a mount point (the device name would also work), the following command shows all files that are in use on this mount point:

lsof /media/KINGSTON

If you run this command as an ordinary user, it will only show your own processes¹. Run sudo lsof /media/KINGSTON to see all users' processes.

The output from lsof looks like this:

COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
zsh4    31421 gilles  cwd    DIR    8,1     4096 130498 /var/tmp
zsh4    31421 gilles  txt    REG    8,1   550804 821292 /bin/zsh4
zsh4    31421 gilles  mem    REG    8,1    55176 821326 /usr/lib/zsh/4.3.10/zsh/complist.so
zsh4    31421 gilles   12r   REG    8,1   175224 822276 /usr/share/zsh/functions/Completion.zwc

The COMMAND column shows the name of the program executable and the PID column shows the process ID. The NAME column shows the file name; you might see (deleted) if the file was deleted while open (when a file is deleted, it no longer has a name, but it still exists until the last process using it closes the file). USER should be self-explanatory. The other columns don't matter here except perhaps FD, which shows how the file is used by the process:

  • cwd: current working directory
  • txt: the program executable²
  • mem: a memory-mapped file (here, think of it as an open file)
  • a number: an actual open file; a subsequent letter indicates the opening mode, such as r for reading and w for writing

There is no mechanical way to locate the window where a file is open (this is in fact not technically meaningful: if a process has several windows, a file is not particularly associated with one window or another), nor even any simple way of identifying a process's window (and of course a process doesn't have to have any windows). But usually the command name and file name are enough to locate the offender and close the file properly.

If you can't close the file and just want to end it all, you can kill the process with kill 31421 (where 31421 is the process ID) or kill -HUP 31421 (“hang up”). If plain killing doesn't do the trick, kill with extreme prejudice: kill -KILL 31421.

There is a GUI for lsof, glsof, but it's not quite ready for prime time yet, and isn't packaged for Ubuntu so far.

¹ Lsof can list some information about other users's processes, but it doesn't detect the mount point so won't list them if you specify a mount point.
² Executable code is often called text in discussions of executable formats.

6

Meanwhile the fuser command has much improved. You can do the full job with a single command:

$ sudo fuser -ickv /"mountpoint"

Where:

  • parameter k kills the offending process,
  • while v shows in advance the process and its user
  • and i asks you for confirmation.

If some process resists, then try again with fuser -ickv -9 (or more generally with -SIGNAL) that kills the most stubborn ones.
But you will always find some "immortal" process...!

In this cases I lately learned to use

$ sudo umount --lazy --force <mountpoint>

as a last resource, that up to now worked for me every time.

2
  • I found the immortal process, my failed attempt to use vboxmanage. -_-
    – sudo
    Sep 8, 2017 at 0:04
  • 1
    that -i is SO important when it asks "Kill process 1 ? (y/N)" - systemd ...
    – CodeShane
    Nov 29, 2021 at 20:40
2

Also this can help:

lsof | grep \/media\/KINGSTON
2
  • 4
    There's no need to escape the slashes. Nov 6, 2010 at 14:56
  • When you're unsure, grep with quotes e.g. grep "media/KINGSTON"
    – Adam Matan
    Dec 16, 2010 at 13:55
0

Note! One other thing that keeps a mountpoint busy is a submount, which isn't a process so won't show up if you search via lsof or fuser. And yes, it should be obvious,but in this age of a long list of mounts due to docker and rebinds and etc, it can be easy to overlook that, for instance:

# mount | wc -l
39
# mount |grep usb
/dev/sde1 on /media/usb type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro)
/media/usb/boot/modloop-lts on /.modloop type squashfs (ro,relatime)

/media/usb cannot be unmounted because of the second mount. (example taken from a real-life alpine linux "diskless" system where I just spent around 10min trying to figure out why I couldn't unmount /media/usb)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .