Монтирование с помощью sshfs и права на запись файлов

Я пытаюсь примонтировать удаленный каталог через sshfs, но файлы в нем не доступны для записи. У меня закончились идеи и способы отладки. Есть ли что-то, что я должен проверить на удаленном сервере?

Я использую Xubuntu 14.04. Я монтирую удаленный каталог на Ubuntu 14.04.

local $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty

Я изменил файл /etc/fuse.conf

local $ sudo cat /etc/fuse.conf
# /etc/fuse.conf - Configuration file for Filesystem in Userspace (FUSE)

# Set the maximum number of FUSE mounts allowed to non-root users.
# The default is 1000.
#mount_max = 1000

# Allow non-root users to specify the allow_other or allow_root mount options.
user_allow_other

И мой пользователь находится в группе fuse

local $ sudo grep fuse /etc/group
fuse:x:105:MY_LOACL_USERNAME

И я монтирую удаленный каталог с помощью (пробовал с/без комбинаций sudo, default_permissions, allow_other):

local $sudo sshfs -o allow_other,default_permissions -o IdentityFile=/path/to/ssh_key  REMOTE_USERNAME@REMOTE_HOST:/remote/dir/path/  /mnt/LOCAL_DIR_NAME/

Пользователь REMOTE_USERNAME имеет права на запись в каталог/файлы (на удаленном сервере).

Я пробовал вышеуказанную команду без sudo, default_permissions, и в каждом случае я получаю:

local $ ls -al /mnt/LOCAL_DIR_NAME/a_file
-rw-rw-r-- 1 699 699 1513 Aug 12 16:08 /mnt/LOCAL_DIR_NAME/a_file
local $ test -w /mnt/LOCAL_DIR_NAME/a_file && echo "Writable" || echo "Not Writable"
Not Writable

Уточнение 0

В ответ на комментарий user3188445:

$ whoami
LOCAL_USER
$ cd
$ mkdir test_mnt
$ sshfs -o allow_other,default_permissions -o IdentityFile=/path/to/ssh_key  REMOTE_USERNAME@REMOTE_HOST:/remote/dir/path/ test_mnt/

$ ls test_mnt/
Я вижу содержимое каталога

$ ls -al test_mnt/
total 216
drwxr-xr-x  1 699 699  4096 Aug 12 16:42 .
drwxr----- 58 LOCAL_USER LOCAL_USER  4096 Aug 17 15:46 ..
-rw-r--r--  1 699 699  2557 Jul 30 16:48 sample_file
drwxr-xr-x  1 699 699  4096 Aug 11 17:25 sample_dir


$ touch test_mnt/new_file 
touch: невозможно создать ‘test_mnt/new_file’: Permission denied

# дополнительная информация: подключение к удаленному хосту через SSH и проверка прав на файлы
$ ssh REMOTE_USERNAME@REMOTE_HOST
# на удаленном хосте
$ ls -al /remote/dir/path/
lrwxrwxrwx 1 root root 18 Jul 30 13:48 /remote/dir/path/ -> /srv/path/path/path/
$ cd /remote/dir/path/
$ ls -al
total 216
drwxr-xr-x 26 REMOTE_USERNAME  REMOTE_USERNAME   4096 Aug 12 13:42 .
drwxr-xr-x  4 root root  4096 Jul 30 14:37 ..
-rw-r--r--  1 REMOTE_USERNAME  REMOTE_USERNAME   2557 Jul 30 13:48 sample_file
drwxr-xr-x  2 REMOTE_USERNAME  REMOTE_USERNAME   4096 Aug 11 14:25 sample_dir

Вопрос был решен в списке рассылки по Linux; я публикую перевод ответа здесь для полноты картины.

Решение

Решение состоит в том, чтобы не использовать оба параметра default_permissions и allow_other при монтировании (что я не пробовал в своих исходных экспериментах).

Объяснение

Проблема, похоже, довольно проста. Когда вы используете опцию default_permissions в fusermount, тогда проверка прав fuse монтирования осуществляется ядром, а не fuse.

Это означает, что uid/gid REMOTE_USER не сопоставлены с LOCAL_USER (sshfs.c IDMAP_NONE). Это работает так же, как обычная nfs fs без сопоставления.

Поэтому логично запрещать доступ, если номера uid/gid не совпадают.

Если у вас есть опция allow_other, то этот каталог доступен для записи только локальному пользователю с uid 699, если он существует.

Из man странички fuse:

'default_permissions'

   По умолчанию FUSE не проверяет разрешения на доступ к файлам, 
   файловая система свободна реализовать свою политику доступа или 
   передать это подлежащему механизму доступа к файлам (например, в 
   случае сетевых файловых систем). Эта опция включает проверку 
   разрешений, ограничивая доступ на основе режима файла. Обычно она 
   полезна в сочетании с опцией 'allow_other'.

'allow_other'

   Эта опция отменяет меру безопасности, ограничивающую доступ к 
   файлам для пользователя, монтирующего файловую систему. Эта 
   опция по умолчанию доступна только для root, но это 
   ограничение может быть снято с помощью конфигурационной 
   опции (на уровне пользователя).

Не запускайте sshfs с sudo. Если вы это сделаете, ssh будет считать, что файловая система принадлежит root. Запустите это от себя, тогда вы сможете записывать файлы.

Уточнение

При запуске без sudo вам нужно монтировать в своем собственном каталоге, так как вы, скорее всего, не можете записывать в /mnt. Вот пример того, как использовать sshfs, после добавления user_allow_other в /etc/fuse.conf:

$ cd                      # убедитесь, что вы находитесь в домашнем каталоге
$ mkdir mnt               # создайте пустой каталог
$ sshfs server.com: mnt   # монтируйте мой домашний каталог на server.com в ./mnt
$ ls mnt
[содержимое домашнего каталога на сервере]
$ touch mnt/new_file      # нет проблем с созданием нового файла
$ fusermount -u mnt       # размонтируйте файловую систему
$ rmdir mnt

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

Еще одна причина ошибок “permission denied”: удаленный пользователь не имеет разрешения на доступ к файлам.

Это может быть очевидным в ретроспективе, но стоит проверить:

• Предполагая, что удаленные и локальные пользователи имеют одно и то же имя (например, вы запустили sshfs remote_machine:/ ~/my_sshfs_mounts/ без явного указания имени пользователя), войдите с помощью ssh remote_machine
• Можете ли вы читать и записывать в нужном каталоге?
• Если да: проверьте другие ответы для устранения проблем с разрешениями SSHFS.
• Если нет: Отлично, вы нашли (или ту самую) причину проблемы! Теперь вам нужно разрешить пользователю, под которым вы сейчас вошли через SSH, читать и записывать файлы на удаленной машине.

В моем случае имена удаленных и локальных пользователей были идентичны, но их идентификаторы (ID) отличались (1000 против 1001). Вы можете проверить это, запустив id. Я пытался получить доступ к файлам, принадлежащим пользователю 1000, под пользователем 1001.

Я исправил это, установив идентификатор удаленного пользователя и идентификатор его группы с 1001 на 1000. Допустим, пользователь называется “me”. Следующие шаги в основном вдохновлены этим ответом:

1. ssh root@remote_machine (возможно, установите PermitRootLogin yes в /etc/ssh/sshd_config)
2. Измените ID пользователя: usermod -u 1000 me (возможно, kill любые процессы, запущенные в данный момент как пользователь “me”)
3. Измените ID группы “me”: groupmod -g 1000 me
4. Измените владельца файлов с пользователя 1001 на 1000: find / -uid 1001 -exec chown -h 1000 {} +
5. Измените членство в группе файлов с группы 1001 на 1000: find / -gid 1001 -exec chgrp -h 1000 {} +

После перезагрузки удаленной машины команда sshfs remote_machine:/ ~/my_sshfs_mounts/ теперь работает.

Если вы создали каталог монтирования в вашем домашнем каталоге, предполагая, что только вы будете его использовать, тогда запустите команду sshfs без sudo. Таким образом, у вас будут необходимые разрешения на каталог монтирования. Это должно помочь.
Пример команды: “sshfs -o reconnect, follow_symlinks <user@sshIp:<remote_dir>> <mount_dir>”

Все другие ответы не помогли. Вот что сработало для меня:

sshfs REMOTE_USERNAME@REMOTE_HOST:/remote/dir/path/ local_mnt/path -o umask=003  -o <OTHER_OPTIONS>

Эта опция важна: umask=003

Установите это значение в зависимости от того, какие права вы хотите предоставить соответствующему локальному пользователю/группе локального каталога/файла. Здесь 003 означает: 774 (что равно: 777 – 003).
Это позволяет пользователю и группе читать, записывать и выполнять файлы в каталоге, а другим — только читать их. Это также применительно к файлам, которые будут создаваться в будущем.
Больше информации здесь: Ubuntu: страницы справочника fuse