sshfs и gedit (не сохраняются файлы)

[axxxdv]

Здравствуйте!

Монтирую ssh в каталог командой: sshfs user@server.ru:/ /home/user/server/ -o uid=1000,gid=1000,allow_other
Монтирование происходит гладко и все вроде бы нормально, если бы не один нюанс. При открытии из каталога ~/server/ файлов на редактирование при помощи gedit (например txt файл) не могу потом его сохранить - gedit пишет: Could not save the file /home/user/server/111.txt. (You do not have the permissions necessary to save the file. Please check that you typed the location correctly and try again.). Примечательно то, что если я открываю файл на редактирование другими редакторами (например openoffice, vi или редактор mc), то все прекрасно сохраняется.
И еще, открытый с помощью редактора gedit файл можно сохранить как... (save as...) под другим именем, а вот просто сохранить (save) не прокатывает.
Помогите разобраться в данной проблеме. Система - Ubuntu 9.04.

[sash-kan]

uid=1000,gid=1000

для чего эти параметры? судя по параметру allow_other, вы, видимо, пытаетесь редактировать файлы от имени разных локальных пользователей?
если монтировать без всех этих опций, результат в gedit аналогичный?
этими редакторами вы изменяете один и тот же файл?
все ли редакторы пытаются создать резервную копию перед сохранением, или только gedit? если в gedit отключить опцию создания р.к., поведение его не меняется?

[axxxdv]

для чего эти параметры? судя по параметру allow_other, вы, видимо, пытаетесь редактировать файлы от имени разных локальных пользователей?
если монтировать без всех этих опций, результат в gedit аналогичный?

Монтирование без этих параметров - результат аналогичный.

этими редакторами вы изменяете один и тот же файл?

Да, редактирую один и тот же файл.

все ли редакторы пытаются создать резервную копию перед сохранением, или только gedit? если в gedit отключить опцию создания р.к., поведение его не меняется?

Отключение в Gedit опции создания резервной копии ничего не дает.

[sash-kan]

google://gedit+sshfs
в весь убунтовский фпейм по этому поводу не вникал, но, вроде бы, один из работающих объездных путей вокруг бага — опция sshfs-а idmap=user