Gedit won't save to SSHFS mount, cured
carla@studio:~# aptitude install sshfs
carla@studio:~# su
carla@studio:~$ mkdir sshfs-xena
Of course you may name your SSHFS directory whatever you want. When I need files from Xena I use this command:
$ sshfs xena:/home/carla sshfs-xena/
Now I have access to my entire home directory on Xena from Studio, and I don't have to worry about having multiple copies floating around because they stay on Xena. You can do this with any remote directory you have permission to access. Unmount with this command:
$ umount sshf-xena
sshfs is faster than using something like ssh -Y, VNC, or FreeNX because your applications are local and not run over the network. It's similar to using NFS or Samba except it's easier to set up and it's on-demand.
Now getting back to gedit. gedit was driving me nuts by refusing to save any documents to an SSHFS mount, telling me I didn't have permission. Ha. It's my PC and I danged well don't need anyone's permission. You should be able to freely edit, copy, and move files around your SSHFS mount just as freely and easily as your local files. Much Web-searching did not turn up any answers. I could save a file that had been changed once if I gave it a different name. But then gedit wouldn't save any more changes to the new file. Finally I figured out that disabling "Create a backup copy of files before saving" cured it. (Edit--preferences--editor.)
So there you go, one more weird little software bug identified and a workaround established.
0 TrackBacks
Listed below are links to blogs that reference this entry: Gedit won't save to SSHFS mount, cured.
TrackBack URL for this entry: https://swarm.jupitermedia.com/mt-tb.cgi/8067
Did you think to check the perms on the Directory? The backup that gedit wanted to create would need Directory write access, not just file access. Yes, I've been burned by this also in SAMBA enviroment.
An Ubuntu bug gets fixed. This should be front page news. I really mean that. I'm not being facetious. Once in a blue moon something wrong with Ubuntu is repaired.
It was never a permissions error, which I already said. And the bug did not get fixed. Instead I found a workaround. It might be a gedit bug so it's premature to blame Ubuntu.
It's more likely to be an sshfs bug since gedit doesn't know and shouldn't have to know if it saves a file to a local filesystem or to a remote filesystem or whether that filesystem is sshfs or ext2/3/4
IIRC using "sshfs .... -o workaround=rename" cures it too.
Can you find a workaround for sshfs not allowing you to delete non-empty directories on the share?
Sorry, delete non-empty folders from Nautilus, it works from the command line of course...
Here's a funny thing, this time with SMB, not SSH, and with RHEL5:
Bug 237064: gedit cannot understand smb://server/share/filename.
Untouched since it was reported on 2007-04-19 02:49 EDT.
Dare I say this... Tramp in Emacs 23. I've been editing files on three different remote systems all day from one Emacs session. (Now, let us have ourselves an enlightening conversation about the relative advantages of various text editors, or maybe not.)
How about using "sshfs -o idmap=user " ?
It will translate the remote user's permissions on the remote directory as the local user's permissions on the local directry.
By this I mean: when the user carla@studio tries to create a new file on the local directory, sshfs will use carla@xena's permissions to write to the remote directory and sucessfully create the new file (which carla@studio can't).
Or something like that.
The only way I've found to delete non empty dirs with Nautilus under sshfs is to move them to the trash and then empty the trash...
Thanks all for the great workarounds for this annoying problem. Especially the workaround=rename and idmap=user options -- each alone works perfectly without forcing me to change my gedit configuration.
-Keith