Failure to Save to SSHFS volumes

[BenWoosley]

When editing a document on a volume mounted using SSHFS
http://fuse.sourceforge.net/sshfs.html

the file fails to save, presenting a bar under the toolbar which says:
"Could not save the file <file path>. You do not have the permissions necessary to save the file. Please, check that you typed the location correctly and try again."

Additionally, the buttons on the toolbar actually disappear and are replaced by solid yellow. Strange...

[BenWoosley (ben-woosley)]

Screenshot here: http://ben.woosley.name/bugs/ubuntu/gedit-sshfs.png

[Dennis Kaarsemaker (dennis)]

On do, 2006-03-23 at 01:50 +0000, BenWoosley wrote:
> When editing a document on a volume mounted using SSHFS
> http://fuse.sourceforge.net/sshfs.html
>
> the file fails to save, presenting a bar under the toolbar which says:
> "Could not save the file <file path>. You do not have the permissions
> necessary to save the file. Please, check that you typed the location
> correctly and try again."

Did you mount the sshfs share as root?

> Additionally, the buttons on the toolbar actually disappear and are
> replaced by solid yellow. Strange...

That's another bug, which is solved already.

[BenWoosley (ben-woosley)]

>That's another bug, which is solved already.
It is indeed

>Did you mount the sshfs share as root?
No. With each restart I must run:
`sudo mknod /dev/fuse c 10 229`
`sudo chmod o+rw /dev/fuse`
then I can mount the volume as myself:
`sshfs <email address hidden>: /media/that/`

As of now, the gedit allows me to save successfully once, then on the second save it fails... The permissions are the same, but
Before editing successfully:
-rw-r--r-- 1 1103 users 6064 2006-03-26 15:07 README
After editing, now uneditable. It shows the message:
-rw-r--r-- 1 1103 users 6089 2006-03-30 17:24 README
-rw-r--r-- 1 1103 users 6064 2006-03-26 15:07 README~

[Dennis Kaarsemaker (dennis)]

No. You should add fuse to /etc/modules and add yourself to the fuse
group, as documented in the fuse documentation.

[Dennis Kaarsemaker (dennis)]

User error, so rejecting.

 status Rejected

[BenWoosley (ben-woosley)]

> You should add fuse to /etc/modules
This removed the need to `mknod /dev/fuse` and `chmod o+rw /dev/fuse`. Thanks for that.

> You should ... add yourself to the fuse group
That isn't the problem, it had been done already
<me>@<mine>:~$ groups <me>
<me> : <me> adm dialout cdrom floppy audio dip video plugdev lpadmin scanner admin fuse

> as documented in the fuse documentation.
These aren't mentioned in either the fuse or sshfs sites:
http://fuse.sourceforge.net/
http://fuse.sourceforge.net/sshfs.html
I did find them in a forum posting:
http://www.ubuntuforums.org/showthread.php?t=103860
But you can hardly call that "the documentation"

Anyway, the problem still exists. On the first save, things work out fine, on the second save to a file with identical ownership and permissions, the edit fails. Further, nano edits it just fine. I continue to believe this is a gedit issue...

[BenWoosley (ben-woosley)]

Eclipse also has no problem w/ the sshfs files that are giving gedit trouble. Just so you understand my thinking here, it's these 2 cases (nano and eclipse), which lead me to believe that it isn't fuse or user error.

[Dennis Kaarsemaker (dennis)]

Interesting - Are you sure the sshfs share is still mounted? I've
repeatedly have similar issues due to malfunctioning SSH servers.

 status Unconfirmed

[BenWoosley (ben-woosley)]

Yeah the share is still mounted, based on the fact I can edit it before and after getting the error in gedit.

[Dennis Kaarsemaker (dennis)]

Can you please mount it in debug mode (sshfs -d) and see whether this
gives useful information?

[BenWoosley (ben-woosley)]

Here's the debug output. I mounted the drive, opened /myfolder/README in gedit without the use of nautilus, edited the file, saved the file successfully, then edited and saved again, this time unsuccessfully. The following milestones are marked in the log:

2: Logged in and mounted
9: Opened in gedit
34: First edit made successfully
53: Second edit fails

The points of interest are 22-25 and 46-47
In the first case, README~ is not found, and README is renamed to README~, then the gedit temp file is renamed to README.
In the second case, README~ is found, then it tries to rename README to README~, which fails with:
" unique: 47, error: -1 (Operation not permitted), outsize: 16",
the error gedit is seeing.

[Dennis Kaarsemaker (dennis)]

Looks like an sshfs bug to me, I'll investigate this.

[Daniel Holbach (dholbach)]

Dennis, did you have any look with that?

[Dennis Kaarsemaker (dennis)]

On wo, 2006-08-02 at 10:13 +0000, Daniel Holbach wrote:
> Dennis, did you have any look with that?

RENAME /myfolder/README -> /myfolder/README~
   unique: 47, error: -1 (Operation not permitted), outsize: 16

sshfs doesn't allow one to rename files to existing files. Normal sftp
also doesn't allow this:

sftp> rename foo bar
Couldn't rename file "/home/dennis/foo" to "/home/dennis/bar": Failure

I'm not sure where exactly the bug in sshfs is, but I think it's not a
bug but specified as such in the ssh protocol. gedit should not fail
saving if a backup can't be created imho so the bug is back at gedit.
--
Dennis K.

Time is an illusion, lunchtime doubly so.

[mszeredi (miklos)]

There's an sshfs option '-oworkaround=rename' which works around this sftp misfeature, although the resulting rename operation will no longer be atomic as required by POSIX.

[Sebastien Bacher (seb128)]

looks somewhat similar to http://bugzilla.gnome.org/show_bug.cgi?id=336738 upstream

[Tim Butler (timbutler)]

Marked this as a duplicate of the problem described in Ubuntu Bug #34813 as it is linked to the problem upstream. The renaming of open files appears to be the same bug and only affects gedit.

[Jonathan Dodson (jbdodson)]

I get this same problem in Gutsy with sshfs and gedit. I can save fine in VIM but GEdit thinks there is a permissions problem. Save works fine once, after that it fails due to permission issues(that is not the case permissions are fine).

[reech (r-mcmillan)]

Can confirm this on Hardy and gedit /sshfs - sometimes first edit saves however subsequent edits fail.

[Arno Teigseth (arno-teigseth)]

This is also an issue in Ibex; I know there are related bugs but this one is labeled especifically SSHFS.

The problem is as explained above that on sshfs you cannot rename a file "A.txt" to "A.txt~" if "A.txt~" already exists. Even if the target filesystem can.

To me this is not gedit specific - all similar operations give the same error:

arno@arno-laptop:~/jobbpc/var/www/dir$ mv stats.php stats.php~
mv: cannot move `stats.php' to `stats.php~': Operation not permitted

...while it works just fine if you mount with the rename workaround option to sshfs, like mszeredi says above:
https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/36091/comments/15

What worries me is that sshfs isn't able to do this kind of renaming even when the target filesystem is ext3. On my system it's all linux, and I mount the remote ext3 system on a local ext3 tree via sshfs. OK maybe the tree isnt ext3 but the filesystems are. Then from a user standpoint I was puzzled that I couldn't do normal ext3 operations. Until I found this bug :)

[Sean G (sean-gilbertson)]

Note that there is a preference in Gedit that fixes this issue (Edit > Preferences > Editor > Create a backup copy of files before saving).

Solution documented here: http://blog.linuxtoday.com/blog/2009/05/gedit-wont-save.html