41

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

sshfs -o allow_root [email protected]: ./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
  • 680
  • 2
  • 9
  • 15

7 Answers7

61

I think you want a lazy unmount:

sudo umount -l example
Chris
  • 1,819
  • 3
  • 14
  • 11
  • 2
    I think your suggestion is incorrect. According to the manual page lazy umount `Detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem *as soon as it is not busy* anymore`. So it will not resolve the original issue. Agreed with @Gilles, `lsof` should help here. –  Sep 24 '13 at 06:50
  • 5
    Actually, this worked for me. lsof could not find any open files but `umount -l` worked. – gerrit Aug 21 '14 at 14:34
  • Yep, worked for me, too. My sshfs was hanging because the connection was lost, so I first used `pkill -9 sshfs`, but then the mountpoint was still not unmountable, so I had to use `sudo umount -l`. – mxmlnkn Mar 18 '20 at 07:14
18

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'
  • 69,786
  • 21
  • 137
  • 178
  • Strangely lsof didn't show a gvfsd-archive process, which was left over from having opened (and closed?) an archive file from a file manager GUI. So, also check `ps aux | grep gvfsd-archive`. – alexei Dec 26 '15 at 21:08
  • Gave warnings that lstat cannot execute and that the information may be incomplete, and didn't list the culprit. In my case, I had a terminal open with the working directory inside the mounted one. – Jānis Elmeris Dec 27 '18 at 15:14
  • The singular process listed in `lsof` hangs on a large file operation and cannot be instructed to close the file. How can I force unmount so the program can continue and not lose data? – Mark Jeronimus Nov 09 '22 at 17:48
  • @MarkJeronimus If you're not willing to kill the program, an alternative is to first save anything you want to save in other programs that are accessing the same filesystem, then force the issue from the other side by killing the sshfs process. Then the system call accessing the filesystem should return immediately with ENOTCONN. – Gilles 'SO- stop being evil' Nov 09 '22 at 19:23
8

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
  • 180
  • 1
  • 3
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,429
  • 13
  • 19
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,047
  • 7
  • 7
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
  • 3
1

On OS X try :

diskutil unmount force /mount/point
ReaperSoon
  • 111
  • 2