I mounted a remote directory using sshfs and I can't save files using gedit, while saving same file using vi works. Changin permission to o-r (640) allows gedit to save files OK. Is there a way to change sshfs connection to make gedit work without chmodding every file?

(I use -o uid=id -u -o gid=id -g, so that remote files seem to be owned by me)

$ touch test.txt 
[!] test.txt appears

$ vi test.txt 
[!] :wq -> saves just FINE

$ gedit test.txt 
[!] opens fine, but upon save shows "You do not have the 
[!] permissions necessary to save the file" error - 

$ vi test.txt 
[!] edit, :wq -> again saves just FINE!

$ ls -l test.txt
-rw-r--r-- ..... test.txt

[!] Now the tricky part:

$ chmod o-r test.txt
-rw-r----- ..... test.txt  <-- removed 'read' perm. from 'others'
$ gedit test.txt 
# WORKS! Saves just fine!

Why removing read permission from others allows gedit to save? (while vi and the rest doesn't have that problem?)

Is there a way to change sshfs connection string to allow me to edit all files directly on server, without having to chmod o-r them?

5 Answers 5


-o workaround=rename solved my problem


The workaround on gedit 2.30.4/Ubuntu 11.04 seems to be enabling the "Create a backup copy..." in Preferences, not disabling it. At least for me, this worked without having to modify any permissions.

This also works in Debian sid with gedit 3.4.2

  • 1
    It's decidedly an odd workaround, but it definitely works. Commented Mar 8, 2013 at 11:07

-o allow_other might do something for you...seems like someone had a similar problem here: http://ubuntuforums.org/showthread.php?t=873199

  • It asks for /etc/fuse.conf, but I don't want to run sshfs via sudo. -o workaround=rename seems to have solved my problem, any particular reason why -o allow_other is better than workaround=rename ?
    – Slava N
    Commented Nov 18, 2010 at 14:38
  • Tried -o allow_other - didn't help.
    – Slava N
    Commented Nov 18, 2010 at 14:46
  • -o allow_other is a sshfs option
    – josinalvo
    Commented Jul 31, 2012 at 14:15

Append -o allow_other to the end of your mount instruction.

[EDIT] This is a known issue, I found a bug report at https://bugs.launchpad.net/gedit/+bug/34813 .

Also found that you can work around the bug from within gedit (at least) by disabling the Create a backup copy of files before saving option, in Edit->Preferences->Editor.

The issue (according to the gedit guys) is a samba/cifs bug, and was first logged (in Ubuntu) in 2006.

  • Tried. Didn't help. workaround=rename helped
    – Slava N
    Commented Nov 18, 2010 at 14:46
  • Yes, I noticed your other comment. I've been trying to duplicate your 'issue', and can't. I always manage to save the file using gedit. So I'm wondering what the file permissions are on the actual server of the directory you're trying to write into? I'm trying to understand WHY removing the read permission for others works, not just the workaround.
    – finley
    Commented Nov 18, 2010 at 14:57
  • With plain sshfs server-side permissions are -rw-r--r-- (644 I guess). 644 won't allow to save file, .goutstreamer-... file appears and isn't removed while saving. If I change perms to 640 - saves fine and .gout... file doesn't appear. I guess gedit saves data to .gout.. file, then renames it and 644 somehow prevents rename.
    – Slava N
    Commented Nov 18, 2010 at 15:10
  • by .gout.. files I mean something like .goutputstream-W7PGMV
    – Slava N
    Commented Nov 18, 2010 at 15:12
  • Oh, sorry, you need to have -o uid="id -u" -o gid="id -g" (change double quotes to backticks) in sshfs for chmod 640 to work. (Without -o uid, -o gid, changing perms to 640 doesn't do anything - gedit still can't save)
    – Slava N
    Commented Nov 18, 2010 at 15:15
sshfs -o allow_other,default_permissions -o IdentityFile=/path/to/ssh_key  REMOTE_USERNAME@REMOTE_HOST:/remote/dir/path/ test_mnt/

Adding default_permissions does the trick!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .