Owner changed after saving file

Thank you for your bug report. What version of Ubuntu do you use and how do you access the sftp location? gedit has not been ported to use gvfs in hardy so it's clear clear the bug is there

I'm using the current development branch (gvfs: 0.1.11svn20080307-0ubuntu1). I've accesed the sftp location with nautilus. I'll try it again after gedit is ported to gvfs...

could you describe the steps you use to trigger the issue?

1. Nautilus -> ctrl+L -> ssh://<email address hidden>
2. Right click some text file or drag it into gedit, that has an other owner than root
3. edit and save it
4. check the file permissions (i did that in a terminal - btw I just saw that it's not possible to change the file permissions in the "file properties" dialog)

not confirming, gedit refuses to store the changes when trying, could you describe easy steps to trigger the bug?

For me this is still working....

On the server I've created a simple text file with vim and chowned to chr:chr:

-rw-r--r-- 1 chr chr 6 Mar 25 08:29 test.txt

Then I logged in with nautilus: Nautilus -> ctrl+L -> ssh://<email address hidden>
right clicked "Open with text editor", added some new text and saved. The result is:

-rw-r--r-- 1 root root 9 Mar 25 08:34 test.txt

May someone else confirm this bug? thanks.

Similiar to this? https://bugs.launchpad.net/ubuntu/+bug/227808

Confirming this bug:
Created a file on the server as user1, then opened the file via nautilus/ssh and gedit as user2. After saving the file, the file belonged to user2. In this scenario, the group was not changed - but when I used root as user2 (like the OP) both user and group were changed to root.

Another thing regarding Sebastien's comment: I get an "not sufficient permissions" error messages when trying to save the file as user2 if the _directory_ containing the file is not writeable for user2. It seems that gedit tries to create a new file that then has the logged in user as its owner.
It's maybe still the same issue as http://bugzilla.gnome.org/show_bug.cgi?id=360400 - gedit is not yet using gvfs, right? Maybe the problem will persist until then...

so about 18 months later this bug still hasn't been fixed? This could lead to serious trouble if you are editing config files on a server through gedit like I was doing. Files can become unreadable to some programs.

steps to reproduce in 9.10:

1. open ssh connection in nautilus
2. open text file with other owner then current logged in user (but group write perms) in gedit
3. save.

I couldn't find another text editor that understood the gnome sftp URI, so it might be a nautilus/gvfs problem

regards

forgot to mention i'm on 9.10

I have same issue (my groupmates are getting their nerves ripped) with 9.10 and 10.04 alpha 3.

I open file trough ssh (Connect to server...) with permissions like owner.team 775 (server is ubuntu 8.04) and i open file for edit to gedit. After i save it permissions has changed to nick.nick.

i am having this problem as well. this almost sounds like a papercut to me... unfortunately it's probably too late to get this fixed in time for lucid?

in the mean time (a few more years?) users could try using sshfs to mount remote files but that isn't always a good solution

this also affects Kate 3.5.1 on Ubuntu 10.10 saving files via sftp on a Ubuntu 10.04 server

Also affects geany.

I can confirm this bug is still present on Ubuntu 11.04. I have maximum updates. Please fix within next decade.

Running Ubuntu Desktop LTS 64bit, fully patched and I can confirm this issue. It is a pain. Please, please fix!

I am running Ubuntu 11.10 desktop 64 bit, the server is 11.10 64 bit, all updates installed, and this problem still exists. Steps to reproduce:

1. Create a file on the server (eg: /tmp/test.txt).
2. chown usr1:grp1 /tmp/test.txt
3. Open Nautilus on desktop.
4. Press CTRL+L (address bar appears).
5. Enter sftp://server.ip.address/tmp/
6. Double click test.txt to open it with gEdit.
7. Enter some text.
8. Save the file.

The result is the group is not preserved, and will change to user1:[user1's group].

I performed the same test on Windows using WinSCP 4.x, and the result is the group permissions are preserved (<-- expected behaviour).

Please fix this as many of us consider this to be a very useful feature (dare I say a 'killer feature' in Linux).

Still the same bug on 12.04.
It is very critical.

Same bug, 12.04 . FYI, same problem existed with jEdit, but only when its "Save-twice" option was set. It would upload file to a temporary name, and once complete, then replace remote server's file with temporary upload. Perhaps the temp file had both owner and group set to ssh login. When instead save-twice feature disabled, original file's owner and group are preserved.

Confirmed for 13.04 as well.

When logged into an SFTP share as root, if I edit a file by another user and hit save the file's permissions get reset to root:root.

This is a very big problem editing web-pages or configuration files which might been specific ownerships and not be world-readable since they then can't be loaded.

problem still exists:
using ubuntu 12.04 and gftp: editing a .htm file with initially rights 644 , editing > then saving locally > actualize the directory > transfering the file to server > rights "automatically" changed to 600, so i have to manually re-change every time to 644 !
gedit: obsolete > now i like using leaftab.

Problem still exists 14.04 LTS over SSHFS

Problem is still present in 17.10. It's almost certainly a GVFS issue, since I'm seeing it with multiple editors (when editing files in a directory mounted over SSH in Nautilus). Editors tested include: Gedit, Atom, VSCode.

Bug still exist on :

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Codename: bionic

Tested with editor:

$ LANG=C; apt-cache policy sublime-text
sublime-text:
  Installed: 3207
  Candidate: 3207
  Version table:
 *** 3207 500
        500 http://download.sublimetext.com apt/stable/ Packages
        100 /var/lib/dpkg/status

16 years since first report... unbelievable...

Since GNOME bugzilla is retired, I have created issue in new GNOME Gitlab, please vote it up, by clicking "Thumb up" - maybe GNOME team will fix it:

https://gitlab.gnome.org/GNOME/gvfs/issues/418