LINUX.ORG.RU

Не могу отредактировать файл, открытый по SSHFS

 ,


1

2

Для монтирования диска удаленного сервера использую команду:

sshfs root@mysite.ru:/ /media/mysite -o reconnect -C -o workaround=all

И пытаюсь отредактировать файл программой kate. При открытии файла сразу появляется ошибка
Файл был удален с диска другой программой

Скриншот: http://i.piccy.info/i9/d4d3e3a880cace4d57d3409ce5e7123e/1485807454/71004/1112...

Вопрос: почему так происходит, как правильно монтировать удаленный диск чтобы работало локальное редактирование?

★★★★★

Ты же монтируешь рутом. А редактируешь ты кем? Какие права на файл? Какие права на каталог, куда пишешь?

imul ★★★★★ ()
Ответ на: комментарий от imul

Ты же монтируешь рутом. А редактируешь ты кем?

Я так понимаю тем, кем примонтировал, т.е. рутом. Рут в данном случае - это рут удаленного сервера. И при редактировании редактирование происходит от того пользователя, каким примонтировали. Или не так?

Права на каталог, которые видны на локальной машине после монтирования:

drwxr-xr-x 1 www-data www-data 4096 янв 30 23:12 controllers

Права на файл, которые видны на локальной машине после монтирования:
-rwxr--r-- 1 www-data www-data    38 янв 30 23:12 hello.php

Xintrea ★★★★★ ()
Ответ на: комментарий от Xintrea

Рут в данном случае - это рут удаленного сервера.

Там да. А команду sshfs ты от какого пользователя запускал?
В тот каталог ты можешь писать только пользователем www-data. Запусти sudo -u www-data kate и попробуй. Локально есть такой пользователь?

imul ★★★★★ ()
Ответ на: комментарий от imul

эмм, разве это поименно будет работать, а не по айди пользователя?

takino ★★★★ ()

sshfs root@mysite.ru:/ /media/mysite -o reconnect -C -o workaround=all

И пытаюсь отредактировать файл программой kate.

К чему такие сложности то. Используй кио.

ya-betmen ★★★★★ ()
Ответ на: комментарий от takino

Это я заготовил для следующего вопроса. PS: и кстати, локально будет показываться тот пользователь, чей id у файла удалённо. Если локально пользователя с таким id нет, то покажёт id, а не имя пользователя.

imul ★★★★★ ()
Последнее исправление: imul (всего исправлений: 2)
Ответ на: комментарий от imul

В тот каталог ты можешь писать только пользователем www-data. Запусти sudo -u www-data kate и попробуй. Локально есть такой пользователь?

Локально такой пользователь тоже есть.

Пытаюсь запустить:

$ sudo -u www-data kate hello.php
[sudo] password for xi:
Sorry, user xi is not allowed to execute '/usr/bin/kate hello.php' as www-data on pangolinux.workgroup.
Спрашивает пароль пользователя, под которым я залогинен локально. Я ввожу его и получаю вышеприведенную ошибку.

Но вообще мне нужно так примонтировать, чтобы я от текущего локального пользователя мог редактировать без всяких sudo и прочего гемора.

Xintrea ★★★★★ ()
Последнее исправление: Xintrea (всего исправлений: 1)
Ответ на: комментарий от Xintrea

Ну, это понятно. У www-data шелла локально нет. И это так и должно быть. Сделай права на каталог 770 и на файл 660 и помести пользователя xi в группу www-data. Ну, или рутом запускай редактор. Тогда точно сможешь редактировать, только надо будет для новых файлов овнера чинить.
А лучше rsync. Сначала копируй оттуда к себе, у себя редактируй и обратно заливай rsync. А совсем хорошо будет какой-нибудь git. Пушнул и спокоен. Ну, или как вариант локальному www-data дай шелл.

imul ★★★★★ ()
Последнее исправление: imul (всего исправлений: 1)
Ответ на: комментарий от imul

Сделай права на каталог 770 и на файл 660

Это самая странная рекомендация для рабочего сервера.

помести пользователя xi в группу www-data

Давно уже помещен, и при логине по SSH я могу редактировать файлы www-data.

Ну, или рутом запускай редактор.

Не могу, потому что не могу из-под рута запустить sshfs:

# sshfs root@webhamster.ru:/ /media/webhamster -o reconnect -C -o workaround=all
read: Connection reset by peer
- эта команда нормально отрабатывает только из под обычного пользователя xi.

А когда даю эту команду под пользователем xi, то потом не могу от рута зайти в примонтированный каталог:
# pwd
/media
# ls -l | grep webhamster
ls: невозможно получить доступ к webhamster: Отказано в доступе
d????????? ? ?    ?       ?            ? webhamster

Соответственно от рута не могу вообще редактировать.

Xintrea ★★★★★ ()
Ответ на: комментарий от imul

Ну, или как вариант локальному www-data дай шелл.

И постоянно запускать редактирование через sudo?

Я делаю навигацию по файлам через mc. И в нем должен иметь возможность нажать F4 и отредактировать файл через редактор, прописанный в $EDITOR.

Не буду же я каждый раз набирать команду редактирования с sudo вместо того чтоб нажать одну клавишу.

То есть, необходима такая команда монтирования, чтобы если написано в ней www-data, то система работает с удаленными файлами как www-data.

Кстати, у меня пользователь xi есть и локально и удаленно. И таже и локально и удаленно он включен в группу www-data, чтобы можно было редактировать файлы. Но при sshfs это пока вообще никак не помогает.

Xintrea ★★★★★ ()
Ответ на: комментарий от Xintrea

Это самая странная рекомендация для рабочего сервера.

Ну я бы назвал стремление редактировать файлы на рабочем сервере удалённо кэтом ещё более странным. Почему не локальную копию с деплоем?

mike@pet ~ $ ls -ld test
drwxr-xr-x. 2 mike mike 4096 янв 25 16:51 test
mike@pet ~ $ sshfs root@10.1.2.1:/ test
mike@pet ~ $ ls -ld test
dr-xr-xr-x. 1 root root 4096 дек 18 20:39 test
mike@pet ~ $ ls -ld test/var/www/html/status/
drwx------. 1 998 radvd 4096 янв 31 00:42 test/var/www/html/status/
mike@pet ~ $ ls -l test/var/www/html/status/index.html
-rw-------. 1 998 radvd 2266 янв 31 00:42 test/var/www/html/status/index.html
mike@pet ~ $ gedit test/var/www/html/status/index.html
mike@pet ~ $ ls -l test/var/www/html/status/index.html*
-rw-------. 1 998 radvd 2265 янв 31 00:43 test/var/www/html/status/index.html
-rw-------. 1 998 radvd 2266 янв 31 00:42 test/var/www/html/status/index.html~
mike@pet ~ $ diff -urN test/var/www/html/status/index.html test/var/www/html/status/index.html~
--- test/var/www/html/status/index.html 2017-01-31 00:43:27.000000000 +0300
+++ test/var/www/html/status/index.html~ 2017-01-31 00:42:21.000000000 +0300
@@ -23,4 +23,5 @@
<a class=RED href=018.html>Рамка 018, предупреждений: 6, ошибок: 2</a></br>
<a class=RED href=019.html>Рамка 019, предупреждений: 6, ошибок: 2</a></br>
<a class=RED href=020.html>Рамка 020, предупреждений: 6, ошибок: 2</a></br>
-</body></html>
+</body>
+</html>

Опробовал твой случай на редакторе gedit. У меня, как видишь, локального юзера нет и группа не совпадает. Но, отредактировать получилось. Видимо дело в kate.

imul ★★★★★ ()
Ответ на: комментарий от Xintrea

И постоянно запускать редактирование через sudo?

Я ошибся.
Попробуй в разных редакторах.
Может быть дело не в монтировании.

imul ★★★★★ ()
Ответ на: комментарий от imul

mike@pet ~ $ ls -l test/var/www/html/status/index.html*
-rw-------. 1 998 radvd 2265 янв 31 00:43 test/var/www/html/status/index.html
-rw-------. 1 998 radvd 2266 янв 31 00:42 test/var/www/html/status/index.html~
-rw-r--r--. 1 root root 12274 янв 31 01:02 test/var/www/html/status/index.html.odt

опеноффис тоже справился, катьку собирать не хочу.

imul ★★★★★ ()
Ответ на: комментарий от imul

Удивил вопрос про то,есть ли локально пользователь.

takino ★★★★ ()
Ответ на: комментарий от Xintrea

Соответственно от рута не могу вообще редактировать.
ls: невозможно получить доступ к webhamster: Отказано в доступе
d????????? ? ? ? ? ? webhamster

Час тупил пока в другой консоли под тем же пользователем не посмотрел.
А почему так? Смонтируешь под рутом - видно только под рутом.
Может знаешь (или кто знает) как смонтировать под рутом чтобы видно было всем. Хочу в fstab вставить.

hbars ★★★★★ ()

Странный топик. Для начала стоило бы проверить корректную работу этого кейса во всяких других редакторах. Если в них работает, это баг/особенность kate, и тогда уже можно более предметно разбираться.

Комментарии хороши: монтируешь не так, права не те... Мда.

Deleted ()
Ответ на: комментарий от Deleted

Почему все умные приходят к шапочному разбору?

imul ★★★★★ ()

А в этой директории ты из под своего пользователя файл создать можешь?
Помнится мне что вроде кате во время редактирования создает там же резервную копию файла. krusader так точно.

hbars ★★★★★ ()
Ответ на: комментарий от takino

Спасибо.

ps: вот дебил. В самом начале FUSE options же написано. :)

hbars ★★★★★ ()
Ответ на: комментарий от imul

Попробуй в разных редакторах.
Может быть дело не в монтировании.

Значит, монтирую из-под локального пользователя xi следующей командой:

sshfs xi@webhamster.ru:/ /media/webhamster -o reconnect -C -o workaround=all

Файл, который хочу отредактировать, имеет на примонтированном ресурсе права:
$ ls -l | grep sym
-rw-r--r-- 1 www-data www-data 1761 мар 31  2015 spt_findsym_10.sh

Локально и на удаленном сервере есть пользователь xi. Их идентификаторы (может это важно?) следующие:
Локально:
xi 500:500
www-data 33:33

На сервере:
xi 1000:1000
www-data 33:33

В kwrite и в kate показывается одна и та же ошибка, написана в топике.

Редактор vi показывает ошибку:
"spt_findsym_10.sh" E212: Can't open file for writing


Редактор micro показывает ошибку:
Permission denied. Do you want to save this file using sudo? (y,n)
[sudo] password for xi:
exit status 1


То есть, дело все-таки в монтировании а не в редакторе.

Xintrea ★★★★★ ()
Ответ на: комментарий от takino

Я попробовал примонтировать такой командой:

sshfs xi@webhamster.ru:/ /media/webhamster -o reconnect -C -o workaround=all -o uid=500 -o gid=500

Вот что пишут про добавленные опции:
       -o uid=N
              set file owner (number)

       -o gid=N
              set file group (number)

В результате у примонтированного диска файл стал иметь хозяина и группу xi:xi вместо www-data:www-data :
$ ls -l | grep sym
-rw-r--r-- 1 xi xi 1761 мар 31  2015 spt_findsym_10.sh

Но я все равно не могу отредактировать этот файл под локальным пользователем xi (у которого UID 500).

Еще нашел вот такой кусок доки:
       -o idmap=TYPE
              user/group ID mapping, possible types are:

               none   no translation of the ID space (default)

               user   only translate UID of connecting user

               file   translate UIDs/GIDs based upon the contents of uidfile  and gidfile

       -o uidfile=FILE
              file containing username:uid mappings for idmap=file

       -o gidfile=FILE
              file containing groupname:gid mappings for idmap=file

Но не могу понять, что тут на что мапится. Мне нужно замапить локального xi с UID 500 на удаленного xi с uid 1000. Как это сделать - понятьиз данного описания не могу.

Xintrea ★★★★★ ()
Ответ на: комментарий от Xintrea

-o через запятую.
to: All

sshfs pi@wifi-router.localnet:/ /home/files/pi -o reconnect,allow_other,sshfs_sync

После ввода пароля - все ок.
Через:
sshpass -p 'rasp' sshfs pi@wifi-router.localnet:/ /home/files/pi -o reconnect,allow_other,sshfs_sync

Не ок. И не ругается никак.
Скажу сразу. Никаких сертификатов не делал.
Нужно?

hbars ★★★★★ ()
Ответ на: комментарий от Xintrea

Я пока не могу что-то полезное сказать.

imul ★★★★★ ()

Я напрямую с sshfs напрямую не работал. Но вот как KDE Connect монтирует удаленную ФС:

remoteuser@192.168.1.7:/ on /home/kroz/.config/kdeconnect/759211521e45a691/kdeconnect_sftp/759211521e45a691 type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Монтирование происходит не под рутом. Удаленный пользователь (remoteuser) - его имя, у меня локально такого нет. Локальный uid/guid - моего текущего локального пользователя.

Пробуй, говори о результатах.

Kroz ★★★★★ ()
Последнее исправление: Kroz (всего исправлений: 2)

P. S. А если б юзал vim, можно было бы вообще без sshfs: Vim как sftp клиент
(Просто камень в твою сторону, незлобный такой. Знаю, что на vim ты всё равно не перейдешь).

Kroz ★★★★★ ()
Последнее исправление: Kroz (всего исправлений: 2)
Ответ на: комментарий от Kroz

То есть, у тебя есть на сервере удаленный пользователь remoteuser с идентификаторами 1000:1000.

Ты коннектишься через KDE Connect от локального пользователя с другим имененем и другими идентификаторами. Опции ты показал.

И ты можешь редактировать файлы пользователя www-data:www-data с правами -rw-r--r-- (644) ?

Я все правильно понял?

Xintrea ★★★★★ ()
Ответ на: комментарий от Xintrea

То есть, у тебя есть на сервере удаленный пользователь remoteuser с идентификаторами 1000:1000.

Нет
У меня есть удалённый пользователь remoteuser. Его id я не знаю.
У меня есть локальный пользователь с uid=1000, gid=1000

И ты можешь редактировать файлы пользователя www-data:www-data с правами -rw-r--r-- (644) ?

Проверил. Получается вот такая ерунда:

(Предупреждаю: удаленная система - Android телефон, так что могут быть нюансы)

Если посмотреть на удаленной системе, то файлы имеют user=root group=sdcard_r. Локально (на примонтированной фс) все файлы видятся как root:root с правами - либо 000, либо 700 (rwx------). Так что теоретически я не должен иметь права их редактировать.

Я смог отредактировать их с помощью vim

Я смог отредактировать их с помощью Midnight Commander'а (F4)

Но я не смог отредактировать их с помощью KDE'шного KWrite. Пишет, что «нет прав доступа или диск заполнен». Притом бекап и временные файлы KWrite успешно создал. Вангую, что он попытался поменять аттрибуты или какие-то еще метаданные.

Может как-то доберусь и попробую sshfs с нормальным другим компом через монтирование в консоли. Но, пока другого линуксового компа нет, так что чем богат.

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

В общем, все не так то просто оказалось. Пока нащупал следующее.

Использую команду монтирования:

sshfs xi@myhost.ru:/ /media/myhost -o reconnect,compression=yes,workaround=all,uid=500,gid=500
Где

xi - существующий удаленный пользователь с (id 1000:1000)

uid=500,gid=500 - идентификаторы существующего локального пользователя xi

Команда mount показывает такое состояние примонтированного диска:
xi@myhost.ru:/ on /media/myhost type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=500,group_id=500)

Все файлы и все директории примонтированного диска отображаются с пользователем xi, независимо от того, какой пользователь на самом деле:
Отображается при монтировании (/var/log):
$ ls -l | grep mail
-rw-r----- 1 xi xi         0 янв  2 06:25 mail.err
-rw-r----- 1 xi xi      7156 дек 27 14:10 mail.err.1
-rw-r----- 1 xi xi      2005 дек 25 06:10 mail.err.2.gz

На самом деле (/var/log):
$ ls -l | grep mail
-rw-r----- 1 root        adm          0 Jan  2 06:25 mail.err
-rw-r----- 1 root        adm       7156 Dec 27 14:10 mail.err.1
-rw-r----- 1 root        adm       2005 Dec 25 06:10 mail.err.2.gz

Если в ls добавить опцию -n, то на примонтированном диске всегда будет показываться владелец 500:500, (хотя на деле, в консоли SSH, будут другие идентификаторы владельца).

Получается, что работая с таким образом примонтированным диском, нельзя узнать какой владелец у файла.

* * *

Но и это еще не все. Я не знаю, баг это или фича, но происходит следующее. На удаленном сервере есть файл с реальным владельцем www-data:
-rw-r--r--  1 www-data www-data      0 Feb  5 16:29 abc.txt

Его невозможно изменить из-под удаленного пользователя xi. То есть, залогинившись по ssh как xi, данный файл можно только просматривать.

А вот на примонтированном ресурсе данный файл можно изменять! Я не знаю, как это происходит, но факт остается фактом. И после изменения меняется владелец:
-rw-r--r--  1 xi       xi            9 Feb  5 16:31 abc.txt

Почему так происходит - для меня загадка. Причем происходит это не со всеми файлами, а только с некоторыми.

По этому поводу у меня есть предположение, что права записи файла зависят не только от разрешений на файл, но и от разрешений на директорию. Современные редакторы (и vi/vim в том числе) очень хитрые: если они могут прочитать файл, они прочтут. А если после изменений надо сохранить файл, то они делают следующее:

- Если есть права на запись непосредственно у файла, файл будет записан и с изменениями. При этом владелец и режим файла не поменяется.
- Если нет прав на запись, редактор попробует удалить файл (а разрешение на удаление прописывается у директории, а не у файла), и создаст новый файл. При этом и владелец (и, возможно, режим) поменяется.
- Если права на файл не позволяют записать файл, и права на директорию не позволяют удалить и создать новый файл, то измененный файл сохранить не удастся.

К сожалению, это объяснение подходит только для примонтированного каталога. На прмаонтированном каталоге редактирование файла любым редактором (vi, micro, kwrite) файла с правами -rw-r--r--, реальным пользователем www-data:www-data, в каталоге с правами drwxrwxrwx, происходит именно по сценарию «старый удаляется, создается новый от пользвателя xi». Если каталог будет drwxr-xr-x, то конечно, такой метод не сработает.

Но при попытке редактирования в консоли через SSH соединение такого же файла, ни vi, ни micro не демонстрируют такое поведение, и файл изменить нельзя.

Казалось бы что плохого? Даже те файлы, которые невозможно изменить по SSH, меняются при доступе через монтирование. Ты хотел редактировать - вот пожалуйста, редактируй. Но проблем несколько:

1. Проблема в том, что при таком редактировании меняется владелец файла. И уследить за этим очень сложно: файл просто редактируется, настоящего владельца, как написано выше, не видно, пока редактируешь - вроде все хорошо. Проблемы начнутся позже, например если менялись файлы конфигов какого-нибудь веб-фремверка. Веб-сервер, например, не сможет работать с файлами, у которых владелец не www-data.

2. Возможность редактирования файла зависит от прав доступа к самому файлу и прав на директорию. Если файл невозможно отредактировать, то при монтировании невозможно оперативно переключиться на другого пользователя. Нужно перемонтироваться.

В общем, на деле все это выглядит весьма криво и неудобно.

Где теперь эти советчики, которые утверждали, что никто не редактирует файлы удаленно, а монтирует по sshfs и все работает какнада?

Xintrea ★★★★★ ()
Ответ на: комментарий от Xintrea

Но при попытке редактирования в консоли через SSH соединение такого же файла, ни vi, ни micro не демонстрируют такое поведение, и файл изменить нельзя.

Поэтому я очень сомневаюсь, что дело в редакторах.
Кроме того, проблема слишком серьезная, чтобы оставаться незамеченной.
Поверхностный гуглёж подкинул идеи попробовать опции -o idmap и/или -o default_permissions (обе описаны в man sshfs).

P. S. Сорри, не люблю быть в роли советчика-теоретика, но, правда, сейчас нет возможности самому поковыряться.

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

Я сейчас остановился на команде монтирования от рута:

sshfs root@mysite.ru:/ /media/mysite -o reconnect,compression=yes,workaround=all,uid=0,gid=0

Понятно, что несекьюрно, но хотя бы с меньшими проблемами происходит доступ к файлам.

Так вот, оказалось, что даже при монтировании рутом, все-таки Kwrite/Kate ведут себя неадекватно.

Редакторы vi и micro редактируют файлы и оставляют прежними и права и владельцев файлов (если права позволяли открыть и сохранить отредактированный файл).

А Kwrite/Kate в этих условиях меняют владельца на root, и устанавливают права 744. В настройках никаких опций, влияющих на такое поведение, не нашел. Так что даже изредка открывать ими файлы на прмонтированной системе - небезопасно.

Xintrea ★★★★★ ()
Последнее исправление: Xintrea (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.