A detachable device like eSATA, USB drive can be abruptly removed (by simply pulling the plug).

If there are open file handles on a partition, then this partitions won't unmount, i.e. the Linux umount command will fail, even AFTER the drive is physically detached.

If the unmount fails, then on reattachment of the device, the mount will fail as well. So you have to find out which processes are using the drive and kill them or close all the handles. If you cannot do either, you will have to reboot the box to get your drive mounted. And I can definitely not kill the process using it.

I see no "force unmount" option, there is a -f option, but it is only for NFS.

This sounds very strange,doesn't Linux accommodate for this scenario where a user simply yanks a drive? Does anyone know how to handle this scenario gracefully in Linux?

Is there any way to find out what file handles are open on a particular partition/device or selectively flush and close all file handles only for a particular device?

Note: The lsof command is not available in the embedded Linux that I am using (busybox).

"fuser" is not available in my embedded linux.

I tried the lazy umount -l. However, it does not seem to consistently work. Say for e.g. I keep a file handle open (with "tail -f" on some file on the device). Then I detach a drive and then I do "umount -l" and it unmounts. And then I reattach the drive and try to mount it again on the same mount point, while the tail is still running. It does not consistently work. Sometimes it succeeds and sometimes it does not. This makes me uncomfortable using the lazy option what if it leaves the file system in inconsistent state. And also am not sure if this lazy option was meant to be used for such scenarios.

I cannot kill the process which has file handles open.

It seems if I have mounted the device on say /mnt/abc and if I disconnect the drive and then reconnect, Linux seems to re-attach the device's file system to the same mount point "/mnt/abc", without us doing any unmount or mount. And then the same old open file handles seems to start working after reattachment (atleast for file read operation). This is my observation. I am not sure if this is the expected behavior.. However, this also does not seem to be working consistently.

I had an open file handle for reading ("tail -f") which I left open, then I detached and reattached and then modified the file being tailed and I saw the "tail -f" output getting updated with the changes. However, if I try to modify a file after the device was gone( it gives error as expected) and then I reattach, the device's file system does not get properly re-attached to the same mount point. In case of a file write (while the device was not there) it does not seem to be working.

Is there any standard/consistent behavior that Linux follows when a drive is removed abruptly without closing all handles and properly unmounting all partitions ?

migrated from stackoverflow.com Sep 7 '11 at 11:14

This question came from our site for professional and enthusiast programmers.


You can write a bash script to scan all the file descriptors listed in /proc (assume you have that) and list/kill the processes.

/proc/$m/fd/$n is the n-th file descriptor for PID m presented as a symbolic link. busybox does have readlink support, so you should be able to automatic it.

Edit: Just to say this is essentially re-implementing lsof, but it's actually fairly simple.

  • Thanks for the response. But from the fd present in /proc/$m/fd can I find out which device or volume it belongs to. I need that, I need to close the fds of the detachable device(eSATA) ONLY on disconnection and not the others which may be a socket fd or file handle on internal device. – solidstate Sep 13 '11 at 10:11
  • Is there any reliable way to find out which fd/file handle (from the /proc) belongs to which device and volume ? – solidstate Sep 13 '11 at 11:54
  • Sorry about replying so late. A basic/(not so reliable) way to do this is to use readlink to get the path the fds are point to and compare them with the mount point listed by mount. E.g. something like if readlink $fd | grep ^$mount-point ; then .... fi – billc.cn Sep 16 '11 at 13:33
  • Thanks billc.cn. But why do you say it is "not so reliable", whats wrong with this approach. When could it give wrong results? – solidstate Sep 25 '11 at 4:10
  • 1
    I already checked this. If a file opened with a "tail -f" command is a symbolic link, and if you see the proc/<pid>/fd entry the fd will be pointing to the actual file not the link. So readlink <fd> will return the path to the actual file. And even if it doesnot I guess one can do readlink again,on the path returned, in a loop to get the target file. – solidstate Sep 26 '11 at 6:25

You can use lsof to list open files under a certain directory using lsof +D /path/to/mountpoint.

  • Thanks for the response. Actually lsof is not available in the embedded linux that I am using. lsof is not available in busybox. – solidstate Sep 7 '11 at 10:01
  • lsof simple trolls through the per-process proc/##/fd directories - you almost certainly have a /proc filesystem these days. So you can either port lsof or easily duplicate it's functionality. Chances are it's already available as an option in busybox which you merely have not enabled in your build. – Chris Stratton Jan 27 '14 at 19:45

Have you tried:

umount -l /path/to/mountpoint

fuser -km /path/to/mountpoint

Ok, so my previous suggestions didn't work out. I know it might be stupid, but have you actually tried:

umount -f /path/to/mountpoint

According to the Busybox documentation it should be the force unmount option (showing NFS as an example).

If that doesn't work, have you tried:

eject -s /dev/my-sata-or-usb-device

  • According to the OP, fuser is not available, and umount -l does not work consistently (see edits to question) – slhck Sep 7 '11 at 16:10
  • Weren't there when I posted, huh. Well, that kills my ideas. :( – Justin Pearce Sep 7 '11 at 16:15
  • thanks. eject is not available. umount -f does not work (even after the drive is physically disconnected and there's an open file handle - "tail -f") it says umount: cannot forcibly umount /mnt/abc: Device or resource busy – solidstate Sep 13 '11 at 10:04
  • I'm out of ideas, sorry. :( – Justin Pearce Sep 13 '11 at 14:48

A quick solution when you lack lsof would be find /proc/*/fd | xargs readlink | grep /mount_point replacing mount_point with the actual mount point. This is based on billc.cn answer above.

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.