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.
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.
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 – 2015-12-26T21:08:01.523Gave 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 – 2018-12-27T15:14:53.287