Create folder is greyed out on SFTP remote folders when UID/GID doesn't match

Bug #300017 reported by Octavio Alvarez
4
Affects Status Importance Assigned to Milestone
gvfs (Ubuntu)
Invalid
Low
Ubuntu Desktop Bugs

Bug Description

If you connect to a remote SFTP folder, the UID and GID is interpreted using the local users and groups database. This makes the "Create Folder" and "Create Document" options to be greyed out.

I'm aware of bugs like 229270 and 9252, but I am reporting this as a separate issue because it is not the same to display ownerships than to prevent the user from doing working.

If SFTP permissions are known to be misinterpreted, just don't make the Create Folder / Create Document / Paste menu items availability depend on those while the bug is being fixed.

I'm sure I do have correct permissions: if I log in to the SSH server and cd to the path, creating the folder through the shell works.

Revision history for this message
Dan Trevino (dantrevino) wrote :

Dolphin, the KDE file manager, seems to work as you would hope. So that may be an option for you. I would suggest that since this is an ssh/gvfs error, the "correct" behaviour is not to break nautilus.

Revision history for this message
Octavio Alvarez (alvarezp) wrote :

I fail to see how "enabling the menus unconditionally and showing an error if gvfs fails to create a folder after the user requested it" would lead to a nautilus breakage. More over, Nautilus is already broken by disallowing a permitted user to create a file or folder.

Looks to me that ssh is only guilty for not providing a way of detecting session permissions, and that's one part of the issue and should be addressed separately. Given this problem with ssh, constraining the user for creating any file or folder (or pasting) if he actually is allowed to do so sure is a Nautilus or gvfs bug.

I would expect this bug to be either left as new in case a fix is released by other means, or to be marked as triaged and wait for a developer that wants to pick it up, mark it as wontfix or redirected/reassigned to a more proper package. I'm resetting it to new, in the hope for a different action to be taken.

Revision history for this message
Octavio Alvarez (alvarezp) wrote :

Ok, so the interface allowed me to set it to new, but the server didn't.

I would appreciate this bug to be set back to new, in the hope for a different action to be taken.

Revision history for this message
Dan Trevino (dantrevino) wrote :

Reset to new, although this is actually a gvfs/ssh bug and sounds like a feature request for nautilus to ignore errors. If I'm understanding it correctly. If so, you are invited to post your idea in Ubuntu Brainstorm at https://brainstorm.ubuntu.com/ where it can be discussed, voted by the community and reviewed by developers. Thanks for taking the time to share your opinion!

Changed in nautilus:
status: Invalid → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

Changed in gvfs:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.