Nautilus opens files over SSH as read-only when not owner.

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 229270, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.

Please remove the duplicate tag. Bug 229270 has been fixed recently (using Jaunty), but the gedit-over-SSH issue has not been resolved: if the user doesn't match directly, gedit opens the file as read-only though write permissions are assured.
Happens to nautilus too: unable to create a new file/folder in folders of which the user doesn't match directly, but write permissions are certainly available.

I can confirm this. I am on current Jaunty. Nautilus displays the remote permissions correctly in the properties dialog using uid and gid. However, despite the fact my user does have permission to write to directory, nautilus has grayed out "cut", "copy", "paste", "Create Folder", and "Create Document" both from the right click menu and the file/edit menu at the top. However, I can still drag and drop a file fine and I can also edit an existing file with gedit fine.

Here are the permissions on the server (the user I connect with is a member of the "docshare" group)
server$ ls -ld /docshare/
drwxrwsr-x 2 root docshare 4096 2009-03-29 17:09 /docshare/

I can also recreate the gedit behavior described by maleadt. If a file is owned by user "foo" and I connect with user "bar", yet "bar" has group permissions to edit the file, gedit will not let me save.

the jaunty version has fixes for ownership issue, the bug should be sent to bugzilla.gnome.org if somebody still get a buggy behaviour there

not confirming the issue on jaunty:
- go to your user directory
- create a test directory
- chmod it 775 and change the owner to somebody else
- browser ssh://localhost to this directory
- the actions are available there

the gedit issue seems to be http://bugzilla.gnome.org/show_bug.cgi?id=567926

Ubuntu 9.04 (x64) / Nautilus 2.26.2

Hi there, I don't think this is a gedit issue; Nautilus seems to ignore group permissions when browsing sftp.

To recreate; create a new file in your home dir and chmod 0070 (group has full access, owner & other have no access).

rwales@ophelia:~$ touch ~/test.txt
rwales@ophelia:~$ chmod 0070 ~/test.txt
rwales@ophelia:~$ ls -l ~/test.txt
----rwx--- 1 rwales rwales 0 2009-04-24 14:54 /home/rwales/test.txt
rwales@ophelia:~$

Now use Nautilus to browse sftp://localhost/home/rwales, you will see the test.txt file displays 'no read' and 'no write' emblems and gedit will refuse to open the file, citing insufficient permissions.

Strangely though, group read and write privileges are acknowledged in the properties dialog > permissions tab and I *can* rename the file in Nautilus.

Hope this helps.

I'm having this problem too. The permissions are correct, because I'm able to drag & drop a folder to the ssh remote location, however, Nautilus doesn't allow me to do any action directly from its menus, neither the thumbnails are generated for remote images (I have active thumbnails for remote folders and with the needed size limit set, so it's not a configuration issue).

What information is missing to get this bug fixed?

From Jaunty I have this problem at well.

SSH to a remote system
touch newfile
chmod g+rw newfile
chown otheruser newfile
now 'connect to server' via sftp and open the file in gedit

Notice that even though you have the right to modify because of group perms.. Gedit says no.

The upstream bug (http://bugzilla.gnome.org/show_bug.cgi?id=567120) seems to indicate that http://git.gnome.org/cgit/gvfs/commit/?id=4e49395240190526e fixes this.

The upstream commit that Watson found does indeed fix the issue on my system. I am learning the patch system and making a debdiff for all. :)

Here is the patch to make all good in the world. Just toss it in the debian/patches directory and echo "99_sftp_group_perm_check.patch" >> debian/patches/series and volla!

and now, the debdiff~

the new version is in karmic now

thank you for your work there, could you follow the sru procedure and add a testcase to the bug?

thank you for your work there, could you follow the sru procedure and add a testcase to the bug?

it would also be useful if somebody tried using the karmic version now

would you please link me to an example test case?

My previous post is not acceptable?:

SSH to a remote system via terminal
touch newfile
chmod g+rw newfile
chown otheruser newfile
under the places menu, 'connect to server' via sftp and open the newfile in gedit

Notice that even though you have the right to modify because of group perms.. Gedit says no (before patch)
After patch Gedit allows you to save changes to the file.

those steps are clear indeed, could you update the bug description?

Thank you for your work, I've sponsored the upload now

Accepted gvfs into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

For me it is working now :)

don't change the status until the fix has been confirmed and copied by the sru team to official updates

could somebody else confirm that the change is working so the update can be moved to the official update?

The change is working here.

The names of the owner and group are not showed in the properties dialog, just the id, but I think that's a different bug report.

This bug was fixed in the package gvfs - 1.2.2-0ubuntu2

---------------
gvfs (1.2.2-0ubuntu2) jaunty-proposed; urgency=low

  * debian/patches/99_sftp_group_perm_check.patch:
    - fixes a failure to check group permissions on sftp hosts (lp: #312396)

 -- Dereck Wonnacott <email address hidden> Fri, 08 May 2009 14:37:21 -0400

How would I go about fixing this on Intrepid?

You will need to apply the patch I provided to the source code in intrepid.
It probably will need to be done by hand though, as the content of that file
very likely changed.

It is not too difficult, just ominous at first.
Get started by doing "sudo apt-get source gvfs".
Get help in #ubuntu-dev on irc.freenode.org

~Dereck

On Mon, Aug 31, 2009 at 5:55 PM, JT <email address hidden> wrote:

> How would I go about fixing this on Intrepid?
>
>