Nautilus gets confused after an SFTP transfer from a remote hotspot

Support and Help
1

Ubuntu 24.04.2 LTS.

I frequently connect to a remote device that has its own WiFi hotspot. I do this for a couple of purposes:

  1. to transfer files from the remote to this computer
  2. to run via VNC something on the remote device

To do #1, I have been using Nautilus → Other Locations → Enter Server Address, then click the connect button. Of course, the computer must at that point in time have been connected to the remote Hotspot, not to my home network.

Once the connection is made, if, in Nautilus, I try to open my home directory, to copy files to a subdirectory of home, after copying the files, Nautilus is sometimes but not always unable to display the contents of my home directory. This is very annoying and I’d like to understand it. Even if my computer is connected to the remote hotspot that should not prevent the home directory from being displayed.

2

What you are seeing is a quirk of Nautilus, not a problem with your /home
folder.

When you click Other Locations - Connect, Nautilus mounts the remote
hotspot with the gvfs SSH backend.
While that mount is active Nautilus keeps a single worker thread busy
talking to the remote machine. If the hotspot is slow—or drops for a
second every other tab that still belongs to that Nautilus window can
stall while it waits for the remote I/O to finish. It looks as if
Home is missing, but it’s just the UI waiting on a network timeout.

Three quick ways around it

Unmount the hotspot as soon as the copy is done
Click the little :eject_button: icon next to the remote entry in the sidebar, or run

gio mount -u "ssh://user@192.168.x.x/"

The moment the mount is gone Nautilus snaps back to normal.

Open a second Nautilus window for /home before you connect.
The hang is per-window; a fresh window stays responsive.

Use sshfs instead of Connect to server

mkdir -p ~/remote
sshfs user@192.168.4.1:/ ~/remote

Copy files to ~/remote in Nautilus (or the terminal), then

fusermount -u ~/remote

sshfs runs in its own process, so Nautilus never blocks.

Nothing is happening to your home directory Nautilus is just waiting on the
slow remote mount. Unmount, use a new window, or switch to sshfs and the
problem disappears.

3

Thank you @thingizkhan. I’ve tried that unmounting of the hotspot. Sometimes it worked, sometimes it didn’t. I don’t think I did this right after the copy was done. so that may be why.

The second nautilus window idea sounds good.

Your third suggestion is unclear to me. Do the sshfs and fusermount commands have to be entered every time I want to transfer files? I don’t suppose it can be made permanent since the computer is only occasionally connected to the hotspot.

Yes, the hotspot connection can be slow.

4

Another idea would be to use FileZilla. This ancient software did the job but was less convenient than Nautilus so I stopped using it.

Is this considered a “bug” in Nautilus, or is it inherent in the system with no good fix?

5

Glad the second-window idea helps.
Here’s a bit more detail on sshfs:

How sshfs works

sshfs user@host:/ ~/remote mounts the remote machine at ~/remote.
It’s just like plugging in a USB stick the folder appears instantly.
fusermount -u ~/remote (or click the :eject_button: icon in Files) unmounts it.

Nothing persists after you unmount, so you run those two commands only when you actually need the connection.

Making it less to type

Create the mount point once

mkdir -p ~/remote

Make a tiny helper script

echo 'sshfs user@192.168.4.1:/ ~/remote' > ~/mount-remote.sh
echo 'fusermount -u ~/remote'            > ~/unmount-remote.sh
chmod +x ~/mount-remote.sh ~/unmount-remote.sh

Now you just:

Connect to the hotspot Wi-Fi
~/mount-remote.sh → copy your files in Nautilus under Home - remote
~/unmount-remote.sh when you’re done

Optional fstab entry (mounts only when you ask):

Add to /etc/fstab:

user@192.168.4.1:/  /home/youruser/remote  fuse.sshfs  noauto,user,_netdev,IdentityFile=/home/youruser/.ssh/id_rsa  0  0

Then you can mount with mount ~/remote and unmount with umount ~/remote.

Because sshfs runs in its own process, Nautilus windows never freeze even if the hotspot is slow or drops out at worst the mounted folder shows an I/O error while the rest of Files stays responsive.

6

It’s not really a bugjust a limitation of Nautilus’ design. One remote mount = one worker thread; if that thread stalls, the whole window stalls. External tools like FileZilla or sshfs run in their own processes, so they stay responsive (and leave Nautilus alone). So:

Nautilus: convenient, but can freeze while the hotspot is busy.
FileZilla / sshfs: a bit more setup, but no freezes.

Pick whichever trade-off feels better; there’s no hidden fix inside Nautilus yet.

7

Thanks. I think I’m going to try the sshfs way. My remote device does not use port 22 for the sftp. What would be the syntax in sshfs to indicate this and what would be the syntax is fstab?

8

One-off command

# example: SFTP runs on port 2222 instead of 22
sshfs -o port=2222 user@192.168.4.1:/ ~/remote

-o port=2222 (or -p 2222 on some builds) passes the port to the underlying ssh command.

Update your helper scripts:

echo 'sshfs -o port=2222 user@192.168.4.1:/ ~/remote' > ~/mount-remote.sh

fstab line

user@192.168.4.1:/  /home/youruser/remote  fuse.sshfs  noauto,user,_netdev,port=2222  0  0

Mount: mount ~/remote
Unmount: umount ~/remote

(You can add other options—IdentityFile, reconnect, etc.—comma-separated in the same field.)

That’s all: add port=your_port (or -p your_port) and sshfs will connect to the non-default SFTP port every time.

9

+1 for fstab. You can then access the files as if they were local. SSHFS is very cool, secure too. If you use SSH keys then you won’t be pestered for credentials