Feedback about FUSE mounts

Question

One of Vifm's best features is its ability to transfer files to/from a server over SSH. Having my local filesystem in one pane and the remote filesystem in the other pane is very handy.

When I 'open' a file like raspberry_pi.ssh containing pi@192.168.1.100:/home/pi/ I land in /home/pi on the server. Pressing h to go one directory up, I would expect to find myself in /home/ (still on the server), but instead I return to my local system. Is this to be expected?

Bookmarks always bring me to a directory on my local system, even if that directory exists on the remote system.

Following a symbolic link on the remote system leads to that directory on my local system (if a directory with the same name exists; otherwise, it errors out). This was pretty confusing to me.

It looks like sometimes I can't suspend my laptop when I am using these FUSE mounts in Vifm. dmesg -T | grep Freez -A4 returned:
[Fri Oct 27 21:31:29 2023] Freezing user space processes failed after 20.008 seconds (11 tasks refusing to freeze, wq_busy=0): [Fri Oct 27 21:31:29 2023] task:vifm state:D stack:0 pid:668988 ppid:1 flags:0x00004006

Answer 1

When I 'open' a file like raspberry_pi.ssh containing pi@192.168.1.100:/home/pi/ I land in /home/pi on the server. Pressing h to go one directory up, I would expect to find myself in /home/ (still on the server), but instead I return to my local system. Is this to be expected?

Yes. It's a mount after all and you're mounting at a particular point. Above that point is your local FS.

Bookmarks always bring me to a directory on my local system, even if that directory exists on the remote system.

Mounting makes part of remote's file-system (FS) tree available at some mount point of the local FS tree. Remote's FS doesn't shadow local FS in any way, so that's expected.

Following a symbolic link on the remote system leads to that directory on my local system (if a directory with the same name exists; otherwise, it errors out). This was pretty confusing to me.

You might want to pass -o follow_symlinks to sshfs. That should present links as regular files and allow openning them on the remote. By default symbolic links are resolved on the host's side which doesn't really have any knowledge about what's on the remote.

It looks like sometimes I can't suspend my laptop when I am using these FUSE mounts in Vifm. dmesg -T | grep Freez -A4 returned:

[Fri Oct 27 21:31:29 2023] Freezing user space processes failed after 20.008 seconds (11 tasks refusing to freeze, wq_busy=0):
[Fri Oct 27 21:31:29 2023] task:vifm            state:D stack:0     pid:668988 ppid:1      flags:0x00004006

I don't really know about prerequisites for freezing, but given that kernel calls into FUSE that might give clients of FUSE some special status.

Comments

Thank you for the quick and clear replies. I wasn't really aware how these FUSE mounts work.

I can confirm that -o follow_symlinks works as expected. I can now mount the remote's home directory and I am still able to reach its root directory, by following a symbolic link in its home directory.

One more small thing I sometimes notice: when the connection to the remote machine is lost (e.g. it briefly loses its connection, or it is rebooted), it's impossible to mount that server's directory again by opening server.ssh once more. It returns the error FUSE UMOUNT ERROR Can't unmount /home/... It may be busy. Only restarting Vifm solves this issue. This might be expected behavior, I am not sure.

---

FUSE UMOUNT ERROR Can't unmount /home/... It may be busy.

That shouldn't happen on mounting. Sounds like you might be talking about leaving directory first to get to server.ssh file. You should be able to use :cd ~ or any other directory change command (e.g., marks) except for :cd .. or h which attempt to unmount FUSE.

I'll need to try it out, maybe it can be handled better.

---

I should have been more clear. This error is indeed only shown when I press h when I am inside /home/username/.local/share/vifm/fuse/003_server.ssh and the connection to the server is lost. I used to press h to try to get back to the directory containing my *.ssh files. If I navigate to that directory by using a mark, no error is indeed displayed.

The issue isn't really the error, but being unable to mount that server's directory again. When I open server.ssh once more, an empty directory is shown, while I know for a fact the connection to the server has been reestablished. Closing and restarting Vifm fixes this issue.

---

Right, Vifm doesn't know in this case that FUSE mount isn't working. That might be possible to check.