Não é possível montar nada em um diretório local específico usando sshfs

2

Eu uso sshfs para montar um diretório remoto localmente. Eu uso o Xubuntu 16.04 dentro de uma máquina virtual do VirtualBox. Ontem, enquanto tudo estava montado, salvei o estado da máquina virtual e fechei; Eu recarreguei o estado salvo esta manhã. Acredito que o fato de eu usar uma VM não é realmente relevante para resolver o problema (já que aconteceu uma vez antes e consegui consertar, não consigo lembrar como), mas estou adicionando para explicar como a corrupção pode ter acontecido.

Agora nada será montado no diretório local que estava em uso, o comando nunca retornará. Eu posso ter qualquer diretório do servidor remoto montado em outros diretórios na minha máquina local, mas nada vai montar no que eu estava usando ontem. Eu reiniciei a máquina Xubuntu e desliguei-a completamente, sem sucesso. Eu também reiniciei o servidor remoto. Eu posso SSH no servidor remoto também.

Certifiquei-me de que nada esteja montado no diretório problemático ( fusermount -u problematic_directory e sudo umount -l problematic_directory ).

A tabela a seguir resume a situação ( original_dir é o diretório que eu normalmente montei; arbitrary_dir é qualquer outro diretório):

LOCAL             REMOTE            WORKS
original_dir  <-- original_dir      NO
arbitrary_dir <-- original_dir      YES
original_dir  <-- arbitrary_dir     NO
arbitrary_dir <-- arbitrary_dir     YES

Isso aponta para algo que está sendo configurado incorretamente em minha máquina local, já que o remoto não parece se importar com qual dos diretórios eu montei.

Não há informações sobre original_dir em /proc/mounts e eu deletei e criei novamente o diretório (vazio), mas nada mudou.

Eu também removi sshfs e openssh-client e reinstalei, sem sorte.

A saída da execução do comando no modo de depuração:

$ sshfs -o debug,sshfs_debug,loglevel=debug,idmap=user me@remoteip:/home/me/project-share /home/me/project-share/
SSHFS version 2.5
FUSE library version: 2.9.4
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-2> <me@remoteip> <-s> <sftp>

Ele fica assim para sempre.

A saída de uma montagem bem-sucedida é assim:

$ sshfs -o debug,sshfs_debug,loglevel=debug,idmap=user me@remoteip:/home/me/project-share /home/me/another-dir/
SSHFS version 2.5
FUSE library version: 2.9.4
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-2> <me@remoteip> <-s> <sftp>
debug1: Reading configuration data /home/me/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to remoteip [remoteip] port 22.
debug1: Connection established.
debug1: identity file /home/me/.ssh/id_rsa type 1
...
debug1: Offering RSA public key: /home/me/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug1: Authentication succeeded (publickey).
Authenticated to remoteip ([remoteip]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending subsystem: sftp
Server version: 3
Extension: [email protected] <1>
...

Infelizmente, não posso usar outro ponto de montagem localmente, pois preciso ter o mesmo caminho para os diretórios locais e remotos e não posso alterar o caminho do diretório remoto.

EDITAR: Encontrei uma solução alternativa: monte o diretório remoto em outro diretório e crie original_dir como um link simbólico:

$ mkdir ~/original_dir_mnt_point
$ sshfs -o idmap=user me@REMOTE_IP:~/original_dir ~/original_dir_mnt_point/
$ ln -s ~/original_dir_mnt_point/ ~/original-dir

Isso só funcionará, no entanto, se o symlink não for criado no momento em que invocarmos sshfs , então o symlink precisa ser recriado para cada re-montagem. Eu ainda quero corrigir isso corretamente.

    
por user2891462 07.07.2017 / 09:59

1 resposta

0

Arquivos ou pastas compartilhados precisam de drivers extras "A opção de imagem de CD Inserir adições de convidado" é uma maneira de evitar que a máquina virtual bloqueie as transferências de arquivos.

    
por Ian Croasdell 08.07.2017 / 13:18