42

I mounted a remote file system using sshfs (version 2.8.4)

sshfs -o allow_root joeuser@example.com: ./example

but unmounting it fails

> fusermount -u example
umount: /home/joeuser/example: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

Any ideas as to what might be causing this error and how one might fix it?

ctuffli
  • 690

7 Answers7

66

I think you want a lazy unmount:

sudo umount -l example
Chris
  • 1,869
19

Some program is using a file in the filesystem you're trying to unmount. It could be a file opened for reading or writing, a current directory, or a few more obscure cases. It could even be due to a directory on the filesystem being a mount point.

To investigate, run lsof +f -- example. It will tell what the process(es) are using the filesystem. Make your own judgement as to whether to make them close files, kill them, or defer the unmount operation.

With a FUSE filesystem like SSHFS, you can kill the process that's providing the fileystem. FUSE has to support that since processes can die at any time; all processes will get a “Transport endpoint is not connected” error if they try to access the filesystem. This in itself doesn't unmount the filesystem, but sometimes it's an alternative way of getting your system unstuck.

Gilles 'SO- stop being evil'
  • 72,151
9

I just had this problem and could not kill -9 the process reading from the mounted filesystem. kill -9 did not work even after fusermount -zu /mount/point or umount -l /mount/point (which worked). The only thing that worked was pkill -9 sshfs.

ctn
  • 190
2

On OS X try :

diskutil unmount force /mount/point
ReaperSoon
  • 121
2

If you already ensured no process is still using the filesystem before trying "regular" umounting:

  • fuser -vm /mount/point and/or
  • lsof /mount/point to find them,
  • quit/kill/do_something_with_them so that they don't use /mount/point anymore,

Try:

  • pkill -KILL sshfs and then
  • fusermount -u /mount/point.

It helped me when I lost network connection and couldn't umount the unresponsive sshfs mount point.

A proactive solution

Also, if you want sshfs to automatically umount when network connection is lost, informing applications using sshfs of an I/O error (so that they don't get stuck infinitely), mount with:

  • sshfs -o ServerAliveInterval=15 remote-srv:/remote/dir /local/mountpoint

When no data is exchanged, your ssh client will check every 15 seconds if it can get a response from the server. If 3 checks fail, it will disconnect and umount.

Totor
  • 1,581
2

I often see "device busy" with sshfs when I have a terminal window open to a directory on the sshfs share. Exiting the terminal or changing directories to a local share then running fusermount -u solves my problems.

CJ Travis
  • 1,077
2

Running Ubuntu, man fusermount tells about a -z option, which is documented as “lazy unmount”. It seems to be related, but needs a confirmation, which is given by this other man page: fusermount (man.he.net), which says “lazy unmount (works even if resource is still busy)”. One must use it with the -u, the -z option alone, will produce an error. I tried the -z option, and can confirm it do the trick, but this precisely too much looks like a trick: what does it do exactly? Make it be unmounted automatically as soon as the directory is not busy any‑more? I don't know, not documented, so unsafe.

So here is another option, more verbose, but safer: tries to unmount until it successes, as many time as needed, in a loop.

echo -n "Unmounting...";
fusermount -u -q "$MOUNT_POINT";
OK="$?";

while [ "$OK" != "0" ]
do
   sleep 1;
   echo -n ".";
   fusermount -u -q "$MOUNT_POINT";
   OK="$?";
done

echo;

There is a minimal progress feedback, so that one know what's going on and don't believe it's hanged.

This option is acceptable from a shell script; for command line interaction, the use of the -z option is more handy, but one must probably be aware the man page does not document it and there may be doubt about what it exactly do.

Hibou57
  • 129