GNOME Bugzilla – Bug 773766
nautilus "jails" user to his homedir on a remote system
Last modified: 2019-12-19 13:49:29 UTC
I connect with nautilus to a remote host via "sftp://user@host/". On the first connect, I can start browsing the remote file system starting at "/". However, as soon I click on the "Mount-Symbol" in the Side panel or close the window and reopen it, nautilus changed directory to my remote home dir and there is visible way available to browse back to "/" or any file or directory higher that the home dir. The remote server has no restrictions or "ChrootDirectory" configured. GNOME nautilus 3.22.1 I filed it under "general" because i'm not sure if this is code bug or a design issue.
Gnah, correction: "There is _NO_ visible way available to browse back to "/" or any file or directory higher that the home dir." Sorry for the fuzz, it's pretty late here.
I don't understand, what is the "home dir" special about in the remote server? We connect, afaik, to the address you provided, not something else like your "home" directory in the remote. Afaik we don't have notion about any home directory in a remote.
Carlos, see: https://developer.gnome.org/gio/stable/GMount.html#g-mount-get-default-location GVfs suggests home dir as a default location for e.g. sftp shares, but it differs from g_mount_get_root...
It is true that it is hard to access root folder over UI for such shares...
Try: 1/ sudo service sshd start 2/ connect to sftp://localhost/ 3/ nautilus shows your home dir
Ooh I see, thanks Ondrej for the clarification. Why should we connect to the default one instead of the address the user typed (which is most probably the root) then?
It is same as "ssh localhost". It connects to your device and sets pwd to your homedir, but you can also change it to root. ssh doesn't allow specify path when connecting. User wants usually see the home directory in most cases, because it is place, where he has its files and has full permissions for them...
okay... that sounds like something we don't take care about from Nautilus UI pov. On the other hand I don't have a good solution for this either.
(In reply to Carlos Soriano from comment #8) > okay... that sounds like something we don't take care about from Nautilus UI > pov. On the other hand I don't have a good solution for this either. This issue actually breaks following workflow: 1. On remote server you have external drive mounted to /mnt. 2. gvfs-mount ssh://server/mnt (or via nautilus "Connect to Server" input box under "Other Locations" 3. Select file on remote under /mnt and copy (for later pasting) 4. You navigate to you home directory and select "paste" 5. You end up with 0 byte file
This is probably an unrelated bug in GVfs. It might be a permission issue, however, in such case, it should return an error instead of the empty file. Does "gvfs-copy ssh://server/mnt/file ssh://server/home/user/file" work? Does "scp user@server:/mnt/file user@server:/home/user/file" work? Please file a new bug for "gvfs" product and "sftp backend" component if needed...
Oops, was a bit unclear at point 4: > This issue actually breaks following workflow: > > 1. On remote server you have external drive mounted to /mnt. > 2. gvfs-mount ssh://server/mnt (or via nautilus "Connect to Server" input > box under "Other Locations" > 3. Select file on remote under /mnt and copy (for later pasting) > 4. You navigate to you home directory and select "paste" Navigate to your local home directory, select paste in Nautilus, > 5. You end up with 0 byte file Command line usage of gvfs-copy works fine: gvfs-copy ssh://server/mnt/file ./
*** This bug has been marked as a duplicate of bug 697461 ***