sshfs non si installa automaticamente all'avvio, nonostante la configurazione di / etc / fstab

Naviga le tue risposte
21

Configurando alcune workstation Ubuntu (13.04), sto provando a montare un filesystem remoto (su ssh).

La configurazione attuale

  • Ho creato l'utente someuser e l'ho aggiunto al gruppo fuse

  • La mia voce fstab si legge come: 

    sshfs#[email protected]:/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

dalla mia comprensione:

  • auto : chiede esplicitamente il montaggio del fs remoto all'avvio
  • _netdev : attendi che l'interfaccia sia attiva prima di provare a montare
  • utente : consente a qualsiasi utente di richiedere questa posizione remota specifica da montare (inutile nella prospettiva dell'utente root che la monta automaticamente all'avvio)
  • allow_other : consentirà a qualsiasi utente (nel gruppo dei fusibili?) di accedere ai file system montati
  • IdentityFile : punta alla chiave privata associata alla chiave pubblica aggiunta in /home/someuser/.ssh/authorized_key del computer remoto.
  • riconnetti : non sei sicuro ... tenterà di riconnettersi se la connessione viene persa?

Il problema

  • Al boot, accedo con someuser , accendo un terminale e / media / remote_dir è vuoto.

  • Ma dallo stesso utente (o dalla radice), posso montarlo semplicemente digitando: 

    mount sshfs#[email protected]:/remote_dir

    Viene anche montato automaticamente magicamente se faccio clic su remote_dir in un browser di file.

Qualche indizio su cosa potrebbe mancare?

    
posta Ad N 31.07.2013 - 15:16

4 risposte

13

Ho sperimentato lo stesso identico problema dopo l'aggiornamento da Oneiric (dove l'automount ha funzionato bene) a Precise.

Ciò che mi ha risolto il problema era l'aggiunta dell'opzione delay_connect . Inoltre, ho utilizzato l'opzione "workaround = rinomina" già prima, dal momento Oneiric. Non sono sicuro che sia ancora necessario oggi, ma almeno non sembra ferire.

La mia linea completa / etc / fstab è: 

sshfs#[email protected]:/remote/dir /local/dir fuse delay_connect,idmap=user,uid=1000,gid=1000,umask=0,allow_other,_netdev,workaround=rename 0 0

Ovviamente dovresti adattare gli ID utente / gruppo al tuo ambiente.

    
risposta data lbo 18.08.2013 - 17:56
0

ha avuto lo stesso problema, penso che tu abbia bisogno di auto per essere noauto. non dovrebbe montare all'avvio, dovrebbe montare quando eth è attivo

    
risposta data Piet Bijl 06.12.2013 - 09:21
0

Se devi montarlo da /etc/fstab di un server DNS autorevole e questo server DNS ti fornisce il nome host del tuo server SFTP remoto che sicuramente non potrai connettere perché il nome host non può essere risolto ancora. O il server DNS deve essere in esecuzione mentre si sta tentando di montare o si deve trovare un metodo alternativo per ottenere l'indirizzo IP del server remoto.

Se questo è il caso, puoi scegliere una delle seguenti soluzioni:

  • Aggiungi l'opzione delay_connect in modo che consenta alla sequenza di avvio di continuare e dopo che la sequenza di avvio ha avviato il server DNS che collegherà.
  • Aggiungi il nome host del tuo server SFTP remoto al tuo file /etc/hosts locale con l'indirizzo IP appropriato.
  • Utilizza l'indirizzo IP del tuo server SFTP remoto in fstab invece del nome host.
risposta data Tony 08.11.2015 - 01:26
0

Anche per completare tutti i commenti precedenti,

  1. Assicurati di consentire agli utenti non root di specificare l'opzione di montaggio allow_other in /etc/fuse.conf

  2. Assicurati di utilizzare ogni mount sshfs almeno una volta manualmente mentre root, in modo che la firma dell'host sia aggiunta al file ~/.ssh/known_hosts . 

    sshfs [user]@[host]:[remote_path] [local_path] -o allow_other,IdentityFile=[path_to_id_rsa]
risposta data Martin Brousseau 15.04.2017 - 03:24

Leggi altre domande sui tag

Cos'è Mir e perché è importante? La nuova tecnologia "FAST Factor Boot" di Seagate è compatibile con Ubuntu?