O sshfs não está sendo montado automaticamente na inicialização, apesar da configuração do / etc / fstab


24

Configurando alguma estação de trabalho Ubuntu (13.04), estou tentando ter um sistema de arquivos remoto montado (sobre ssh).

A configuração atual

  • Criei o usuário someuser e o adicionei ao grupo de fusíveis

  • Minha entrada do fstab tem a seguinte redação:

    sshfs#someuser@remote.com:/remote_dir  /media/remote_dir/   fuse    auto,_netdev,port=22,user,allow_other,noatime,follow_symlinks,IdentityFile=/home/someuser/.ssh/id_rsa,reconnect     0       0
    

do meu entendimento:

  • auto : está pedindo explicitamente que o fs remoto seja montado na inicialização
  • _netdev : aguarde a interface ser ativada antes de tentar montar
  • usuário : permite que qualquer usuário solicite a montagem desse local remoto específico (inútil na perspectiva do usuário root montá-lo automaticamente na inicialização)
  • allow_other : permitirá que qualquer usuário (no grupo de fusíveis?) acesse o fs montado
  • IdentityFile : aponta para a chave privada emparelhada com a chave pública adicionada na /home/someuser/.ssh/authorized_key da máquina remota.
  • reconectar : Não tenho certeza ... Tentará reconectar se a conexão for perdida?

O problema

  • Na inicialização, faço logon com algum usuário , inicializo um terminal e / media / remote_dir está vazio.

  • Mas do mesmo usuário (ou root), eu posso montá-lo apenas digitando:

    mount sshfs#someuser@remote.com:/remote_dir
    

    Também é montado automaticamente quando eu clico em remote_dir em um navegador de arquivos.

Alguma pista sobre o que poderia estar faltando?


Já entendeu isso? Estou enfrentando o mesmo problema em uma máquina Ubuntu 14.04 de 64 bits.
glibdud

Vendo a popularidade desta pergunta, comparada ao número de respostas, desisti da abordagem fstab. Decidi morder a bala e aprender a usar o Automount, abordando o problema geral. Da minha experiência, foi "a escolha certa". Uma boa introdução ao Automount pode ser encontrada no wiki do Ubuntu .
Ad N

Respostas:


18

Eu experimentei exatamente o mesmo problema depois de atualizar do Oneiric (onde o automount funcionou bem) para o Precise.

O que resolveu o problema para mim foi adicionar a opção delay_connect . Além disso, já uso a opção "solução alternativa = renomear", desde tempos oníricos. Não tenho certeza se ainda é necessário hoje, mas pelo menos não parece doer.

Minha linha completa do / etc / fstab é:

sshfs#user@host:/remote/dir /local/dir fuse delay_connect,idmap=user,uid=1000,gid=1000,umask=0,allow_other,_netdev,workaround=rename 0 0

Obviamente, você precisaria adaptar os IDs de usuário / grupo ao seu próprio ambiente.


1
Trabalhou para mim sem solução alternativa = renomear onde não funcionava antes. Então, minha única alteração foi adicionar a opção delay_connect, que definitivamente ajudou aqui! Obrigado por isso. Só estou querendo saber por que _netdev não é suficiente aqui ...
Nicolas

1
Isso funciona perfeitamente para mim também. @ Nicolas, acredito que o _netdevproblema seja explicado na resposta de Tony. A rede pode estar funcionando, mas ainda não consegue resolver o host. Obviamente, o uso de um endereço IP resolveria isso, mas quem quer endereços IP no fstab?
Auspex

Pelo que vale a pena, de alguma forma, quando copio e colo isso no átomo, ele pega caracteres invisíveis que o quebram. Eu tinha que remover aqueles
Jonathan

4
Ele monta bem, mas então eu recebo: ls / backup: Erro de entrada / saída
Jonathan

Adicionar 'delay_connect, workaround = rename' funcionou para mim no Arch Linux. Obrigado!
aSystemOverload

1

Também para complementar todos os comentários anteriores,

  1. Certifique-se de permitir que usuários não raiz especifiquem a allow_otheropção de montagem em/etc/fuse.conf

  2. Certifique-se de usar cada montagem sshfs pelo menos uma vez manualmente enquanto root, para que a assinatura do host seja adicionada ao ~/.ssh/known_hostsarquivo.

    sshfs [user]@[host]:[remote_path] [local_path] -o allow_other,IdentityFile=[path_to_id_rsa]
    

A opção allow_other mount expõe um bug de segurança não resolvido no kernel do Linux: se a opção default_permissions mount NÃO for usada junto com allow_other, os resultados da primeira verificação de permissão realizada pelo sistema de arquivos para uma entrada de diretório serão reutilizados para acessos subseqüentes. desde que o inode da entrada acessada esteja presente no cache do kernel - mesmo que as permissões tenham sido alteradas e mesmo se o acesso subsequente for feito por um usuário diferente.
MountainX para Monica Cellio

0

teve o mesmo problema, acho que você precisa que o auto seja automático. não deve montar na inicialização, deve montar quando o eth estiver ativo


6
Eu acho que o "montar apenas quando pronta para a rede" já está perguntou usando _netdev, e mudando com o noautotornaria incapaz de montar na inicialização (somente explicitamente ao usar a montagem de comando)
Anúncio N

0

Se você for montá-lo a partir de um servidor DNS autoritativo /etc/fstabe o nome do host do seu servidor SFTP remoto for fornecido por esse servidor DNS, você certamente não poderá se conectar porque o nome do host ainda não pode ser resolvido. O servidor DNS precisa estar em execução ao tentar montar ou você precisa encontrar um método alternativo para obter o endereço IP do servidor remoto.

Se for esse o caso, você pode escolher qualquer uma das seguintes soluções:

  • Adicione a delay_connectopção para permitir que a sequência de inicialização continue e após a sequência de inicialização ter iniciado o servidor DNS, ele se conectará.
  • Adicione o nome do host do servidor SFTP remoto ao /etc/hostsarquivo local com o endereço IP apropriado.
  • Use o endereço IP do seu servidor SFTP remoto em fstabvez do nome do host.

Você pode expandir a delay_connectopção? Para onde é adicionado? Edite sua pergunta para incluir mais informações.
AJefferiss

Você o adiciona na lista de opções fstab: sshfs # user @ host: / remote / mnt / local fusível delay_connect, uid = 1000, gid = 100, umask = 0, allow_other 0 0
Tony
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.