[Intrepid] Connecting to SSH server with Nautilus. Can't transfer file because "free space: 0 bytes" (gvfs bug ?)

[arekkusu]

I have got problem transferring file to an SSH server using Nautilus. (running Ubuntu 8.10)

I've testing the folowing on two ssh server.

Connecting to the server in the following way:
Place > Connect to server > "Service type" = "SSH"

Once I am logged in to the server (entered the password / public key authentication...)
I get a nautilus window for exemple: "/home/user/.gvfs/sftp on 192.168.1.x/"

I can transfer file from the server to my computer fine but I can't copy anyhing to the server. I get the following error:
"There is not enough space on the destination. Try to remove files to make space."
Note that in the nautilus status bar I've got "Free space: 0 bytes"

There actually is enough place on the server and permission are ok too. I can even created a file on the server and then fill it up with text without a problem.

As a matter of fact I can transfer the same file to to same directory just fine if I use the following method:

-Use nautilus to manually access "sftp://user@192.168.1.x/"
Then the file copy fine. I noticed there is not "Free space: " in the status when using this second method to access the server.

Hope my explanation was clear enough.
Seem like a pretty annoying bug to me. Hope this hasn't already been reported... well I didn't manage to find a bug with the same issue.

[Florens Verschelde (fvsch)]

Confirming this bug. When nothing is mounted (FTP or SFTP), the /home/$USER/.gvfs/ folder says "Free space: 0 bytes". When accessing any folder in that folder, Nautilus still thinks there is 0 bytes available.

Accessing FTP or SFTP filesystems using the ftp:// or sftp:// protocols in Nautilus works fine. Nautilus won't consider the files as local (which is correct), won't try to count the content of folders if the option is for local files only (option is ignored when using the /home/.../.gvfs/... path), etc. File copy works fine.

When a nautilus window is available, using the bookmarks from there will use the ftp:// or sftp// protocols. When using the bookmarks from the Gnome shortcuts menu, you will get a path with /home/$USER/.gvfs/...

[Thiago Teixeira (tvst)]

I'm having the same problem. It seems that Nautilus now tries to work around this issue by redirecting you to the "sftp://hostname" equivalent of the "~/.gvfs/sftp on hostname" address.

For example:
1) connect to some ssh server on Nautilus
2) type "~/.gvfs/sftp on hostname" on the location bar
3) press Ctrl+L to show the address and notice that the location bar changed to "sftp://hostname"

The problem is that this solution creates inconsistencies, as it breaks your bookmarks in gvfs-unaware programs.

Try this, for example:
1) connect to some ssh server on Nautilus
2) bookmark "~/.gvfs/sftp on hostname" by dragging it to the places sidebar
3) open Firefox, click on File > Save Page As
4) notice that your new bookmark is not on the file browser!!

As a work-around, I created a symbolic link to my "~/.gvfs/sftp on hostname" folder, and bookmarked *that* instead. But then, while this works just fine on Firefox, it does not on Nautilus. Instead, when I try to copy a file to the symbolic link, Nautilus acts as originally described in this bug report, saying "There is not enough space on the destination. Try to remove files to make space."

[Pedro Villavicencio (pedro)]

Thanks for the report, that's working fine for me on Jaunty, could you give it a try there? May you also run /usr/lib/gvfs/gvfsd -r on a command line and copy the information that's going to be throw there when accessing the ssh server? thanks in advance.

[Thiago Teixeira (tvst)]

Pedro, as I wrote on my previous comment, on Jaunty it seems that Nautilus redirects any "~/.gvfs/hostname" address to "sftp://hostname", which bypasses the "0 bytes" problem but creates other issues. Maybe I should just create a new bug report for the new issues...

[Sebastien Bacher (seb128)]

closing the bug since that's not an issue in jaunty