SSHFS: montare una risorsa remota sfruttando FUSE ed SSH: differenze tra le versioni

Versione attuale delle 19:01, 18 ago 2019

File System e dispositivi fisici

Generalità

Locali

Remoti

Strumenti

fdisk

SSH

Guide correlate

Versioni Compatibili

Debian 8 "jessie"
Debian 9 "stretch"
Debian 10 "buster"

Introduzione

Spesso può essere necessario lavorare direttamente su un filesystem remoto (si pensi, ad esempio, alla webroot di un sito o alla home del proprio portatile).

Sshfs permette di superare questo problema in un modo semplice e pulito: montando una directory mediante FUSE^[1], usando il protocollo SSH.

Installazione

Il pacchetto sshfs e le utility per gestire FUSE sono già presenti in Debian, quindi l'installazione si riduce ad un semplice:

# apt install sshfs

(da eseguirsi con privilegi di amministrazione)

Configurazione

Permettere l'esecuzione di sshfs ad altri utenti

A partire da Debian 8 (Jessie) non è necessario modificare niente, in quanto di default tutti gli utenti possono utilizzare il modulo fuse se è installato; né ha più alcuna importanza l'appartenenza al gruppo fuse, in precedenza richiesta.

Utilizzo e Test

L'utilizzo è semplice:

sshfs [user@]host:[dir] mountpoint [options]

anche se spesso si può semplicemente usare senza opzioni:

$ sshfs user@host:/dir/to/mount /mnt/sshdir

dove

user: è l'utente della macchina remota, se omesso verrà utilizzato l'username dell'utente che lancia il comando;
host: è l'indirizzo IP o l'URL a cui la macchina remota risponde;
/dir/to/mount: è il percorso assoluto della directory da montare, (è possibile anche utilizzare un percorso relativo a partire dalla directory home dell'utente: ./path/to/dir; o perfino tralasciare questo argomento, per indicare la home, ma sempre digitando :);
/mnt/sshdir: rappresenta il punto di mount; questa directory deve appartenere all'utente, che deve avervi accesso anche in scrittura;

per controllare la riuscita del comando, si può analizzare l'output del comando:

$ findmnt

Per quanto riguarda lo smontaggio (unmounting) il comando è il seguente:

$ fusermount -u /mnt/sshdir

per le opzioni consultare il file

$ man sshfs

tra le più comuni:

-p PORT equivalente a -o port=PORT
-C equivalente a -o compression=yes 
-F ssh_configfile specifica un file di configurazione alternativo
-1 equivalente a -o ssh_protocol=1

Si noti che per dichiarare opzioni di SSH è sufficiente digitare -o variabile_sshd=valore, ad esempio per specificare la propria chiave privata è sufficiente aggiungere -o IdentityFile=/percorso/chiave (ASSOLUTO!):

$ sshfs user@host:/dir/to/mount /mnt/sshdir -o IdentityFile=/percorso/chiave -p numero_porta

Se il mount avviene con successo è possibile usare il file-manager preferito per poter gestire in lettura e scrittura la nuova directory montata, che sia esso MC, dolphin, PCmanfm o altro.

Utenti e gruppi proprietari

Per impostazione predefinita sshfs adotta un'associazione "diretta" tra UID/GID della macchina remota e quella locale, il che significa per esempio che se il proprietario di un certo file sulla macchina remota è l'utente con UID 1002 anche in locale la proprietà del file sarà attribuita all'utente avente UID 1002. Potrebbero dunque sorgere problemi di permessi se su macchina remota e locale non sussiste un esatta corrispondenza utenti/UID e gruppi/GID. Un modo veloce per superare tale problema è specificare lo UID/GID durante il comando per montare le risorse remote, per esempio

# sshfs user@host:/dir/to/mount /mnt/sshdir -o idmap=user,uid=1001

fa sì che all'utenza usata per connettersi al server remoto sia associata in locale l'utenza avente UID 1001. Se si ha la necessità di fissare la corrispondenza di più utenze/gruppi è possibile creare degli appositi file di mappatura (si veda il manuale di sshfs).

Accesso ad altri utenti

Per permettere l'accesso del file system anche ad altri utenti, indipendentemente dai permessi associati ai file, è possibile mediante l'opzione: -o allow_other

Affinché abbia effetto però bisogna anche configurare fuse, ossia che /etc/fuse.conf contenga, non commentata, la riga user_allow_other, che di default è disabilitata per ragioni di sicurezza. Per maggiori informazioni si rimanda al manuale (man fuse).

È pertanto sconsigliato utilizzare tale impostazione, se si può fare altrimenti.

FAQ ed Errori Frequenti

failed to open `/dev/fuse`: No such file or directory

L'errore è dovuto alla mancanza del modulo del kernel relativo a fusefs. È necessario compilarlo come modulo o staticamente. Nei kernel pacchettizzati Debian è presente, ed è caricabile con un:

# modprobe fuse

mountpoint is not empty

Se si cerca di montare una risorsa in un mountpoint contenente già dei file, può apparire il seguente errore:

fusermount: mountpoint is not empty
fusermount: if you are sure this is safe, use the 'nonempty' mount option

Le soluzioni sono:

usare un mountpoint libero (consigliata)
appendere, dopo il comando sshfs l'opzione -o nonempty

Collegamenti esterni

[1] FUSE

Guida scritta da: MaXeR	Debianized 80%
Estesa da:
Verificata da: Wtf 16:58, 9 ott 2013 (CEST) mm.barabba HAL 9000 21:01, 18 ago 2019 (CEST)
Verificare ed estendere la guida \| Cos'è una guida Debianized

@@ Riga 1: / Riga 1: @@
-L'installazione dei driver proprietari Nvidia su Debian si pu� fare in due modi, e in entrambi i casi � molto semplice.
+{{File_System
+|precedente=Samba:_guida_estesa
+|successivo=Guida_alla_formattazione_dei_dischi_con_fdisk
+}}
+{{SSH
+|precedente=SFTP: SSH File Transfer Protocol
+}}
+{{Versioni compatibili|Jessie|Stretch|Buster}}
+== Introduzione ==
+Spesso può essere necessario lavorare direttamente su un filesystem remoto (si pensi, ad esempio, alla webroot di un sito o alla home del proprio portatile).
-Il primo metodo prevede di utilizzare l'installer automatico fornito da Nvidia: si tratta di uno script per la shell che tramite un menu ci guida nell'installazione. Questo metodo, per quanto semplice e funzionale, ha uno svantaggio: aggira il sistema di gestione dei pacchetti (APT nel caso di Debian, ma anche qualunque altro), con il risultato che questo non sapr� mai dell'esistenza del modulo e non potr� aiutarci nella gestione di eventuali dipendenze o conflitti con altri pacchetti.
+'''<code>Sshfs</code>''' permette di superare questo problema in un modo semplice e pulito: montando una directory mediante FUSE<sup>[[#Collegamenti esterni|[1]]]</sup>, usando il protocollo [[SSH]].
-Il secondo metodo utilizza un tool specifico di Debian: module-assistant. Module-assistant � un programma che permette di automatizzare la compilazione di molti moduli proprietari, e la creazione di pacchetti .deb contenenti i moduli compilati, per la successiva installazione tramite APT. Lo svantaggio di questo metodo � che i nuovi pacchetti per module-assistant arrivano sempre con qualche giorno di ritardo rispetto all'installer, come � ovvio che sia.
+== Installazione ==
+Il pacchetto <code>sshfs</code> e le utility per gestire FUSE sono già presenti in Debian, quindi l'installazione si riduce ad un semplice:
-{{Warningbox|Si raccomanda di usare <b>uno solo</b> dei due metodi proposti.}}
+<pre>
+# apt install sshfs
+</pre>
+(da eseguirsi con [[privilegi di amministrazione]])
-= Metodo 1: l'installer Nvidia =
+== Configurazione ==
-== Occorrente ==
+=== Permettere l'esecuzione di sshfs ad altri utenti ===
-Ecco di cosa abbiamo bisogno per l'installazione:
+A partire da Debian 8 ([[Jessie]]) non è necessario modificare niente, in quanto di default tutti gli utenti possono utilizzare il modulo <code>fuse</code> se è installato; né ha più alcuna importanza l'appartenenza al gruppo ''fuse'', in precedenza richiesta.
-* Headers del kernel che stiamo utilizzando (occhio alle subversion, per controllare si pu� usare <tt>uname -r</tt>) o, in alternativa, i sorgenti dello stesso kernel (gli headers fanno parte dei sorgenti, ed esistono come pacchetto indipendente solo ed esclusivamente per poter compilare moduli fuori dal kernel senza dover scaricare tutto il kernel)
-* Driver corretto per la nostra architettura scaricabile da [http://www.nvidia.com www.nvidia.com]
-<b>nota:</b> se avete compilato un kernel personalizzato, il pacchetto degli headers per il vostro kernel non esiste: dovete usare i sorgenti del kernel configurati.
+== Utilizzo e Test ==
+L'utilizzo è semplice:
-== Cosa fare ==
+ '''sshfs''' [user@]host''':'''[dir] mountpoint [options]
-Prima di tutto occorre chiudere X. Non basta fare logout, bisogna proprio killare il server grafico: se avete installato un desktop manager, per esempio kdm, andate in una console non grafica (per es. con <tt>Ctrl+Alt+F1</tt>), e usate, da root:
+anche se spesso si può semplicemente usare senza opzioni:
 <pre>
-# /etc/init.d/kdm stop
+$ sshfs user@host:/dir/to/mount /mnt/sshdir
 </pre>
+dove
+; <code>user</code>: è l'utente della macchina remota, se omesso verrà utilizzato l'username dell'utente che lancia il comando;
+; <code>host</code>: è l'indirizzo IP o l'URL a cui la macchina remota risponde;
+; <code>/dir/to/mount</code>: è il percorso assoluto della directory da montare, (è possibile anche utilizzare un percorso relativo a partire dalla directory home dell'utente: <code>''./path/to/dir''</code>; o perfino tralasciare questo argomento, per indicare la home, ma sempre digitando '''<code>:</code>''');
+; <code>/mnt/sshdir</code>: rappresenta il punto di mount; questa directory deve appartenere all'utente, che deve avervi accesso anche in scrittura;
-Ora, controllate (con <tt>ls -l</tt>) che il link <tt>/usr/src/linux</tt> punti agli headers del kernel in funzione o ai sorgenti, che per� <b>devono</b> essere configurati esattamente come il nostro kernel corrente.
+per controllare la riuscita del comando, si può analizzare l'output del comando:
-Per fare un esempio supponiamo di aver installato il .deb dei sorgenti, e di doverli quindi configurare:
 <pre>
-$ cd /usr/src
+$ findmnt
-$ tar xvfj linux-source-xxx
-$ cd linux-source-xxx
-$ cp /boot/config-`uname -r` .config
-$ make oldconfig
 </pre>
-dopo di che siamo pronti per avviare l'installazione.
+Per quanto riguarda lo smontaggio (unmounting) il comando è il seguente:
-{{Warningbox|Potreste aver gi� installato un driver NVIDIA, in questo caso:
-#Se lo avete installato voi, allora questa guida non vi server perche sapete gi� come fare :)
-#Se ve lo ha installato un'altra persona, allora potete tranquillamente dire all'installer di sovrascriverlo se state installando una versione piu aggiornata.}}
-Per avviare l'installazione dobbiamo spostarci nella directory dove abbiamo salvato il driver nvidia e dare il comando:
-<pre># sh NVIDIA-*</pre>
-dove <tt>NVIDIA-*</tt> � il nome del driver che abbiamo scaricato.
-<b>Aggiornamento:</b> con X.org 7.0 � cambiata la locazione dei driver del server grafico, ed � necessario dire all'installer dove deve mettere i driver, pena il non funzionamento dei driver stessi, e anche il probabile malfunzionamento delle applicazioni che usano OpenGL. Il comando per l'installazione diventa:
-<pre># sh NVIDIA-* --x-module-path=/usr/lib/xorg/modules/</pre>
-Una volta avviato l'installer comparir� un menu interattivo che ci guider� nell'installazione, dove dovremo rispondere alle domande dicendo che vogliamo installare il driver.
-Il nuovo installer permette l'aggiornamento automatico di <tt>xorg.conf</tt>. Potete farlo anche a mano, semplicemente editando il file <tt>/etc/X11/xorg.conf</tt> come indicato nella sezione successiva.
-Dopo aver installato il driver per il kernel pu� essere utile installare il tool grafico per configurarlo:
 <pre>
-# aptitude install nvidia-settings
+$ fusermount -u /mnt/sshdir
 </pre>
-ricordate che molte delle impostazioni che potete modificare con <tt>nvidia-settings</tt> necessitano del riavvio della sessione per avere effetto.
-In fine possiamo far ripartire il server grafico, sempre nell'ipotesi che usiate kdm:
+per le opzioni consultare il file
 <pre>
-# /etc/init.d/kdm start
+$ man sshfs
 </pre>
+tra le più comuni:
+ '''-p''' ''PORT'' equivalente a <code>-o port=PORT</code>
+ '''-C''' equivalente a <code>-o compression=yes</code>
+ '''-F''' ''ssh_configfile'' specifica un file di configurazione alternativo
+ '''-1''' equivalente a <code>-o ssh_protocol=1</code>
-= Metodo 2: module-assistant =
+Si noti che per dichiarare opzioni di SSH è sufficiente digitare <code>'''-o''' ''variabile_sshd'''''='''''valore''</code>, ad esempio per specificare la propria chiave privata è sufficiente aggiungere <code>-o IdentityFile=/percorso/chiave</code> (ASSOLUTO!):
-== Occorrente ==
+<pre>$ sshfs user@host:/dir/to/mount /mnt/sshdir -o IdentityFile=/percorso/chiave -p numero_porta</pre>
-Per usare questo motodo � sufficiente una connessione ad internet, oltre, ovviamente, a module-assistant: se non l'abbiamo:
-<pre># aptitude install module-assistant</pre>
-== Cosa fare ==
+Se il mount avviene con successo è possibile usare il file-manager preferito per poter gestire in lettura e scrittura la nuova directory montata, che sia esso MC, dolphin, PCmanfm o altro.
-Come per l'altro metodo, bisogna fermare il server grafico, e poi non dobbiamo fare altro che lanciare module-assistant:
-<pre># m-a</pre>
-il quale ci mostra un menu grafico tramite il quale dobbiamo, nell'ordine:
+=== Utenti e gruppi proprietari ===
-* aggiornare la lista dei pacchetti disponibili
-* preparare il sistema per la compilazione
-* selezionare il modulo da compilare dalla lista fornita
-* compilare
-* installare il pacchetto ottenuto
-il tutto senza uscire da module-assistant.
+Per impostazione predefinita sshfs adotta un'associazione "diretta" tra [[UID]]/[[GID]] della macchina remota e quella locale, il che significa per esempio che se il proprietario di un certo file sulla macchina remota è l'utente con UID 1002 anche in locale la proprietà del file sarà attribuita all'utente avente UID 1002. Potrebbero dunque sorgere problemi di permessi se su macchina remota e locale non sussiste un esatta corrispondenza utenti/UID e gruppi/GID. Un modo veloce per superare tale problema è specificare lo UID/GID durante il comando per montare le risorse remote, per esempio
-nota: module-assistant si occupa automaticamente di installare un compilatore se non l'avete, e anche gli headers del kernel. Se possedete gi� gli headers giusti, o anche l'intero kernel (che, ricordo, deve essere configurato esattamente come il vostro kernel), � sufficiente controllare di avere impostato il link simbolico <tt>/usr/src/linux</tt> in modo che punti agli headers o ai sorgenti:
+<pre># sshfs user@host:/dir/to/mount /mnt/sshdir -o idmap=user,uid=1001</pre>
-<pre>ln -s /usr/src/linux-headers-xxx /usr/src/linux</pre>
-Ora bisogna modificare xorg.conf, nella sezione "Device", in modo che nella riga "Driver" sia scritto <tt>'''nvidia'''</tt> (di solito al posto di <tt>'''nv'''</tt> o <tt>'''vesa'''</tt>), inoltre bisogna sostituire, nella sezione "Module", le righe
+fa sì che all'utenza usata per connettersi al server remoto sia associata in locale l'utenza avente UID 1001. Se si ha la necessità di fissare la corrispondenza di più utenze/gruppi è possibile creare degli appositi file di mappatura (si veda il manuale di sshfs).
-<pre>
-Load    "dri"
-Load    "GLcore"
-</pre>
-con la riga
-<pre>
-Load    "glx"
-</pre>
-dopo di che non resta che installare i driver per xfree/xorg (che sono sempre proprietari, ma non sono da compilare, e in Debian sono in un pacchetto a parte) e, volendo, anche il tool grafico per configurarli, e poi si pu� lanciare X:
+==== Accesso ad altri utenti ====
-<pre>
-# aptitude install nvidia-glx nvidia-settings
-# /etc/init.d/kdm start
-</pre>
+Per permettere l'accesso del file system anche ad altri utenti, indipendentemente dai permessi associati ai file, è possibile mediante l'opzione: <code>-o allow_other</code>
-= Verifica =
+Affinché abbia effetto però bisogna anche configurare '''fuse''', ossia che <code>/etc/fuse.conf</code> contenga, non commentata, la riga <code>user_allow_other</code>, che di default è disabilitata per ragioni di sicurezza. Per maggiori informazioni si rimanda al manuale (<code>man fuse</code>).
-Per verificare velocemente se tutto funziona potete usare glxgears, da lanciare in un terminale.
+È pertanto '''sconsigliato''' utilizzare tale impostazione, se si può fare altrimenti.
-Glxgears � un semplicissimo programma che produce in una finestra l'animazione di tre ruote dentate che girano, e nel frattempo conta quanti frame al secondo riesce a generare il vostro sistema. Non � pensato per effettuare un vero benchmark, ma � solo un test indicativo, e i suoi risultati dipendono vistosamente dal carico presente sulla CPU, quindi per ottenere indicazioni attendibili evitate di lanciarlo mentre la CPU sta facendo altre cose.
-= Opzioni utili =
-In <tt>xorg.conf</tt> ci sono alcune opzioni specifiche del driver nvidia che si posono inserire nella sezione "Device", per esempio se non vogliamo vedere il logo Nvidia ad ogni avvio possiamo inserire:
-<pre>
-Option "NoLogo" "1"
-</pre>
-invece per usare il codice AGP del driver proprietario invece di quello libero possiamo inserire:
-<pre>
-Option "NvAGP" "On"
-</pre>
-personalmente con questa opzione attivata riscontro con glxgears un aumento di prestazioni pari al 50%.
-In certi casi ci possono essere dei problemi nell'uso di un monitor esterno su di un laptop:  per ovviare all'inconveniente si pu� provare ad aggiungere
+== FAQ ed Errori Frequenti ==
+=== failed to open <code>/dev/fuse</code>: No such file or directory ===
+L'errore è dovuto alla mancanza del modulo del kernel relativo a ''fusefs''. È necessario compilarlo come modulo o staticamente. Nei kernel pacchettizzati Debian è presente, ed è caricabile con un:
 <pre>
-Option "UseEDID" "0"
+# modprobe fuse
 </pre>
-Ci sono molte altre opzioni possibili, che trovate elencate, su Debian, in <tt>/usr/share/doc/nvidia-glx/README.txt.gz</tt>.
+=== mountpoint is not empty ===
+Se si cerca di montare una risorsa in un [[mountpoint]] contenente già dei file, può apparire il seguente errore:
+<pre>fusermount: mountpoint is not empty
+fusermount: if you are sure this is safe, use the 'nonempty' mount option</pre>
+Le soluzioni sono:
+* usare un mountpoint libero (consigliata)
+* appendere, dopo il comando <code>''sshfs''</code> l'opzione <code>''-o nonempty''</code>
-----
+=== Collegamenti esterni ===
-Autore: [[Utente:Bedo|Bedo]]
+[1] [http://fuse.sourceforge.net/ FUSE]
-[[Categoria:Desktop]][[Categoria:Hardware]]
+{{Autori
+|Autore = [[Utente:MaXeR|MaXeR]]
+|Verificata_da =
+: [[Utente:Wtf|Wtf]] 16:58, 9 ott 2013 (CEST)
+: [[Utente:mm-barabba|mm.barabba]]
+: [[Utente:HAL 9000|HAL 9000]] 21:01, 18 ago 2019 (CEST)
+| Numero_revisori = 3
+}}
-Correzioni, metodo 2, verifica e opzioni utili aggiunti da [[Utente:tindal|tindal]]
+[[Categoria:Filesystem]]
+[[Categoria:Condivisione_risorse]]
+[[Categoria:Crittografia]]
+[[Categoria:SSH server e amministrazione remota]]

SSHFS: montare una risorsa remota sfruttando FUSE ed SSH: differenze tra le versioni

Versione attuale delle 19:01, 18 ago 2019

Indice

Introduzione

Installazione

Configurazione

Permettere l'esecuzione di sshfs ad altri utenti

Utilizzo e Test

Utenti e gruppi proprietari

Accesso ad altri utenti

FAQ ed Errori Frequenti

failed to open `/dev/fuse`: No such file or directory

mountpoint is not empty

Collegamenti esterni

Menu di navigazione

SSHFS: montare una risorsa remota sfruttando FUSE ed SSH: differenze tra le versioni

Versione attuale delle 19:01, 18 ago 2019

Introduzione

Installazione

Configurazione

Permettere l'esecuzione di sshfs ad altri utenti

Utilizzo e Test

Utenti e gruppi proprietari

Accesso ad altri utenti

FAQ ed Errori Frequenti

failed to open /dev/fuse: No such file or directory

mountpoint is not empty

Collegamenti esterni

Menu di navigazione

Ricerca

failed to open `/dev/fuse`: No such file or directory