Monte com sshfs e grave as permissões de arquivo

Question

Eu tentei sshfs montar um dir remoto, mas os arquivos montados não são graváveis. Eu fiquei sem ideias ou maneiras de depurar isso. Existe alguma coisa que eu deveria verificar no servidor remoto?

Estou em um Xubuntu 14.04. Eu montei o dir remoto de um 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

Eu mudei o /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

E meu usuário está no grupo de fusíveis

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

E eu montei o diretório remoto com (tentei com / sem combinações de 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/

O REMOTE_USERNAME tem permissões de gravação para o diretório / arquivos (no servidor remoto).

Eu tentei o comando acima sem sudo, default_permissions e, em todos os casos, recebo:

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

Esclarecimento 0

Em resposta ao comentário de 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/
I see the contents of the dir correctly

$ 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: cannot touch ‘test_mnt/new_file’: Permission denied

# extra info: SSH to the remote host and check file permissions
$ ssh REMOTE_USERNAME@REMOTE_HOST
# on 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

    

Answer 1

A pergunta foi respondida em uma lista de discussão do linux ; Eu postei uma resposta traduzida aqui para completar.

Solução

A solução não é usar as opções default_permissions e allow_other (que eu não tentei nos meus experimentos originais).

Explicação

O problema parece ser bem simples. Quando você dá a opção default_permissions no fusermount, então o controle de permissão do fusível da montagem do fusível é tratado pelo kernel e não pelo fusível . Isso significa que o uid / gid de REMOTE_USER não está mapeado para o LOCAL_USER (sshfs.c IDMAP_NONE). Funciona da mesma forma que um simples nfs fs sem mapeamento.

Portanto, faz sentido proibir o acesso, se os números uid / gid não corresponderem.

Se você tiver a opção allow_other , então este diretório é gravável apenas pelo usuário local com o uid 699, se existir.

Do homem do fusível:

'default_permissions'

   By default FUSE doesn't check file access permissions, the
   filesystem is free to implement its access policy or leave it to
   the underlying file access mechanism (e.g. in case of network
   filesystems).  This option enables permission checking, restricting
   access based on file mode.  It is usually useful together with the
   'allow_other' mount option.

'allow_other'

   This option overrides the security measure restricting file access
   to the user mounting the filesystem.  This option is by default only
   allowed to root, but this restriction can be removed with a
   (userspace) configuration option.

    

Answer 2

Não execute o sshfs com o sudo. Se você fizer isso, o ssh considerará que o sistema de arquivos pertence à raiz. Corra como você mesmo, então você poderá escrever nos arquivos.

esclarecimento

Quando rodando sem sudo, você precisa montar em seu próprio diretório, já que você provavelmente não pode gravar em / mnt. Então, aqui está um exemplo de como usar o sshfs depois de adicionar user_allow_other ao /etc/fuse.conf:

$ cd                      # make sure you are in home directory
$ mkdir mnt               # create empty directory
$ sshfs server.com: mnt   # mount my home directory on server.com on ./mnt
$ ls mnt
[contents of home directory on server]
$ touch mnt/new_file      # no problem creating a new file
$ fusermount -u mnt       # unmount file system
$ rmdir mnt

    

Answer 3

Uma possível razão para isso - uma que eu tive sucesso - foi que eu não tinha mais espaço livre no disco que montei.