Nfs-kernel-server: condividere risorse tra macchine GNU/Linux

Versioni Compatibili Debian 5 "lenny" Debian 6 "squeeze" Debian 7 "wheezy" ERRORE: utilizzare "unstable_2024" come parametro al posto di " Sid "! Vedi qui.

Introduzione

NFS è l'acronimo di Network Filesystem, ovvero un filesystem utilizzato per montare cartelle remote sul proprio filesystem locale (o meglio per condividere in una LAN filesystem presenti su un server). L'utente in sintesi mette a disposizione una o più risorse (ovvero una directory del proprio file system) presenti su una delle sue macchine e le altre vi possono accedere come fosse una directory del proprio file system. In poche parole NFS permette di impostare un sistema di condivisioni simili a quello di Windows, o meglio, è Windows che ha "copiato" NFS per realizzare il suo sistema di condivisione.

Al di là di quest'aspetto 'estetico' il vantaggio principale consiste nel poter accedere alle risorse remote come se fossero risorse locali, cosa non possibile se si utilizzano protocolli come ftp/sftp o http (che sono alcuni dei protocolli sfruttati dalla funzione "Risorse --> Connetti al server" di GNOME). In sintesi è possibile manipolare file e directory sfruttando tutte le possibilità che un normale file system offre. A titolo d'esempio si cita la condivisione di calendari in Thunderbird; come noto è impossibile condvidere un calendario e/o una rubrica tramite protocollo sftp, mentre risulta possibile usando ftp/http anche se l'operazione risulta macchinosa ed in ogni caso le credenziali sono trasmesse in chiaro. Usando NFS invece l'operazione non presenta differenze rispetto al caso in cui il calendario fosse stato salvato in una posizione realmente presente sul disco rigido della propria macchina.

Sia chiaro che ogni macchina può simultaneamente condividere alcune risorse che accedere a quelle presenti su altre macchine.

Nel seguito si vedrà come configurare sia la macchina che condivide le risorse (server) sia quelle che dovranno accedervi (client), tuttavia risulta opportuno esporre prima alcune considerazioni sulla sicurezza.

Sicurezza

Nel caso di una piccola rete domestica/aziendale il discorso sicurezza lascia il tempo che trova, dato che di norma in questi casi hanno accesso alle macchine solo persone fidate. Se però così non fosse è bene essere consapevoli che la condivisione NFS non abbinata ad un sistema di autenticazione centralizzato, come kerberos o ldap, è causa di gravi vulnerabilità.

Con i vari protocolli di rete come ftp, sftp, ecc. è infatti necessario effettuare un'autenticazione presso il server ospitante le risorse (che poi queste credenziali siano trasmesse in chiaro o cifrate è un altro paio di maniche), mentre con NFS non viene fatta alcuna autenticazione "diretta". Una volta definite le risorse da esportare l'accesso a queste è regolato in base all'UID dell'utente; poiché gli UID degli utenti di base sono assegnati in modo crescente a partire da uno stesso numero (cioè 1000, almeno per debian e derivati), a meno che un utente non decida di cambiarli sua sponte, è evidente come l'accesso alle stesse sia tutt'altro che sicuro. In realtà è possibile restringere l'accesso alle stesse in base all'indirizzo IP (in lenny man portmap, man exports per tutti), tuttavia questo accorgimento potrebbe non essere adeguato e/o sufficiente. Poiché su ogni macchina almeno un utente deve esistere, è chiaro per quanto detto che tutte le macchine hanno almeno un utente con lo stesso UID (a meno di modifiche fatte appositamente), cioè quello creato in fase d'installazione. Il risultato è che i vari utenti della rete potrebbero avere accesso a risorse cui non dovrebbero o che comunque non gli interessano, oppure non avere accesso alle risorse che gli servono, ecc. Basta infatti che l'UID dell'utente con cui ci si è autenticati sul computer 'A' coincida con uno di quelli associati ai nomi_utente del PC 'B'.

Esempio: due utenti possiedono entrambi due computer con sistema linux e decidono di mettere in rete le rispettive macchine per condividere alcune cartelle. L'utente 'A', che possiede il computer 'A', durante l'installazione di linux ha scelto come nome_utente 'tizio', mentre l'utente B proprietario del computer 'B' ha scelto come nome utente 'caio'. Di norma perché l'utente 'A' possa accedere alle risorse su 'B' è necessario che l'utente 'B' crei un utenza apposita sul PC 'B' e che poi comunichi nome utente e password all'utente 'A'. Col filesystem NFS il controllo dell'accesso alle varie risorse non viene fatto su una coppia di credenziali "nome_utente+password", ma solo sugli UID degli utenti; poiché sia 'tizio' che 'caio' sono stati i primi utenti creati rispettivamente sui PC 'A' e 'B' è evidente che dovranno avere anche lo stesso UID, avendo già detto che linux associa di base UID=1000 al primo utente creato. Il risultato finale nella migliore delle ipotesi è che l'utente 'A' acceda alle sole risorse scelte da 'B' con i privilegi di 'B' invece che di 'A' (cioè quelli attribuiti da 'B' ad 'A') e viceversa. Nel peggiore dei casi, poiché quando si condivide una cartella vengono automaticamente condivise tutte le sotto cartelle, l'utente 'A' avrà accesso con i privilegi di 'B' (e viceversa) a cartelle cui normalmente non avrebbe dovuto avere accesso, il che può essere più o meno grave a seconda della sensibilità dei dati in esse contenute.

Come già detto inizialmente questo problema è normalmente puramente teorico, poiché nella maggior parte delle piccole LAN private l'accesso alla rete ed ai PC che la compongono è possibile solo a persone di fiducia e/o in ogni caso le risorse condivise non contegono dati particolarmente sensibili. Se però così non fosse, l'utente sarebbe costretto ad implementare o un sistema di autenticazione come kerberos/ldap oppure a RINUNCIARE all'uso di NFS.

Si noti che se su un computer non sono presenti un utenza ed un gruppo aventi il medesimo nome di quelli presenti sulla macchina che esporta le risorse, allora visualizzando le proprietà di file e cartelle attraverso nautilus sulla macchina client verranno indicati come proprietario e gruppo nouser e nogroup. Accedendo invece dal server alle medesime risorse i nomi di proprietario e gruppo risulteranno corretti anche per file e cartelle creati dall'utente remoto.

Impostazioni lato server

Installazione

Installare i pacchetti necessari:

Lenny

# apt-get install nfs-kernel-server portmap

Squeeze e successive

# apt-get install nfs-kernel-server

Configurazione

Lenny

Convenzione IP della macchina server: 192.168.1.10; directory da condividere: /media/storage

Ora editare col vostro editor preferito (gedit, kate, vim, ...) il file /etc/exports ed aggiungere la seguente riga:

/media/storage      192.168.1.0/24(rw,sync,no_subtree_check)

Nota:

• 192.168.1.0/24 indica l'abilitazione a tutte le macchine della rete 192.168.1
  • se si vuole abilitare una o determinate macchine basta specificarne l'IP
• rw indica che tutti hanno i permessi di lettura e scrittura
  • se si vogliono dare solo i permessi di lettura, sostituire rw con ro
• /media/storage è la directory del nostro filesystem che vogliamo condividere

Completare dando ai vari client i permessi per l'accesso alla macchina server: editare il file /etc/hosts.allow ed inserire

portmap: 192.168.1

Come si capisce, in questo modo si da il permesso di accedere a tutta la LAN; se si vogliono delle restrizioni agire di conseguenza inserendo l'indirizzo specifico del/i client.

Ora lanciamo il demone e rendiamo disponibile la directory condivisa:

# /etc/init.d/nfs-kernel-server start 
# exportfs -a

Squeeze e successive

Editare il file /etc/default/nfs-common ed assicurarsi che le righe contenti le variabili NEED_IDMAPD= e NEED_GSSD= appaiano così:

NEED_IDMAPD=yes
NEED_GSSD=no

Editare il file /etc/default/nfs-kernel-server ed assicurarsi che la riga contente la variabile NEED_SVCGSSD= appaia così:

NEED_SVCGSSD=no

A questo punto è possibile definire le condivisioni editando il file /etc/exports, ogni riga del quale descrive una directory. Ad esempio inserendo le seguenti righe:

/home       192.168.1.0/24(rw,fsid=0,no_subtree_check,crossmnt,sync)
/home/altro 192.168.1.0/24(rw,no_subtree_check,sync)

Si condivide la cartella /home e la sua sottocartella /home. La dicitura 192.168.1.0/24 serve a restringere l'accesso alla risorsa /home alle sole richieste provenienti dagli indirizzi IP che vanno da 192.168.1.1 a 192.168.1.254. Una richiesta che per esempio dovesse provenire da 192.168.2.15 sarebbe rifiutata. Tra ( ) si indicano le opzioni:

• rw: abilità la cartella in lettura e scrittura, ammesso comunque che l'utente abbia il permesso di scrivere su quella cartella; indicando ro si limita la possibilità di scrivere anche per quegli utenti che se non accedessero da remoto avrebbero di norma il permesso di scrivere.
• fsid=0: identifica la cartella come radice per il filesystem da esportare. Una sola cartella può avere valore di fsid pari a 0.
• no_subtree_check: velocizza l'accesso alle risorse a scapito di un minimo aumento del rischio sicurezza.
• sync: impone sincronia tra client e server. L'alternativa è async, ma è meglio evitarla poiché in caso di crash o eventi imprevisti aumenta la probabilità di causare danni al filesystem.
• crossmnt: questa opzione serve in teoria solo se si sono rimontate delle directory (si veda la successiva sottosezione dedicata al rimontaggio delle cartelle), tuttavia è possibile che omettendola si noti un crollo della velocità di trasferimento (per esempio fino a 150-200 kB/s) nel trasferire grossi file da un client al server.

ATTENZIONE Dalla versione 4 di NFS tutte le risorse da esportare devono essere contenute dentro una medesima directory cui dovrà essere attribuito fsid=0, in caso contrario è necessario rimontarle tutte prima in un'altra cartella e poi esportare questa, si veda più avanti.

Per rendere operative le modifiche al file /etc/exports eseguire:

# /etc/init.d/nfs-kernel-server restart

In caso di ulteriori problemi a visualizzare il contenuto delle cartelle provare a riavviare server e client.

RIMONTARE LE DIRECTORY

È possibile rimontare una o più cartelle in una seconda posizione col risultato che il contenuto delle cartelle risulta accessibile da due differenti posizioni (quella originale e quella dove si rimonta). Per far ciò è prima necessario creare il punto di mount, per esempio:

# mkdir -p /export/utente
# mkdir -p /export/altro

Supponendo di voler rimontare le cartelle /home/utente e /altro rispettivamente in /export/utente e /export/altro:

# mount --bind /home/utente /export/utente
# mount --bind /altro       /export/altro

Per evitare di dover ridigitare ad ogni riavvio i precedenti comandi basta aggiungere le seguenti due righe al file /etc/fstab:

/home/utente /export/utente none bind 0 0
/altro       /export/altro none bind 0 0

A questo punto per esportare la cartella /export non rimane che editare il file etc/exports

/export        192.168.1.0/24(rw,fsid=0,no_subtree_check,sync,crossmnt)
/export/utente 192.168.1.0/24(rw,no_subtree_check,sync)
/export/altro  192.168.1.0/24(rw,no_subtree_check,sync)

Da notare l'aggiunta dell'opzione crossmnt, che non deve essere omessa pena l'impossibilità di vedere il contenuto delle sottocartelle di export sulle macchine client. Quest'opzione DEVE ESSERE assegnata solo alla cartella cui viene attribuito fsid=0.
Stando al manuale l'opzione nohide ha un effetto molto simile a quello di crossmnt, con la differenza che quest'opzione NON DEVE ESSERE assegnata alla cartella cui viene attribuito fsid=0, ma solo alle sotto directory (in caso contrario l'export delle risorse fallisce), ovvero restando al soprastante esempio:

/export        192.168.1.0/24(rw,fsid=0,no_subtree_check,sync)
/export/utente 192.168.1.0/24(rw,no_subtree_check,sync,nohide)
/export/altro  192.168.1.0/24(rw,no_subtree_check,sync,nohide)

Sottolineo che per quanto riguarda la mia personale esperienza questo secondo metodo è risultato inadeguato, poiché nel caso di trasferimento di grossi file (>1GB) da client a server ho notato un sistematico crollo della velocità di trasferimento (170 kB/s circa, tipicamente dopo aver superato la soglia di 1,1-2,5 GB trasferiti). Nel trasferimento da server a client le due soluzioni mi risultano invece equivalenti.

Impostazioni lato client

Installazione

Lenny

Installare i pacchetti necessari:

# apt-get install nfs-common portmap

Squeeze e successive

Controllare che sia presente il pacchetto nfs-common, in caso contrario installarlo:

# apt-get install nfs-common

Configurazione

Una volta definite le risorse da condividere è possibile caricarle su un altro PC in modo permanente (statico) o su richiesta (dinamico). Il primo approccio è caratterizzato da un consumo di banda prolungato nel tempo, in quanto client e server devono costantemente scambiare informazioni (anche se non si utilizzano direttamente le risorse condivise), nel secondo invece il consumo di banda avviene solo quando si ha un effettivo accesso alle risorse. Nel caso di una LAN è ragionevole supporre che la banda non sia un problema, ma nel caso di condivisioni attraverso internet il discorso potrebbe cambiare. In generale se l'accesso alle risorse remote non è frequente è più logico utilizzare l'approccio dinamico.

Lenny

Creare la dirctory dove si vuol montare la directory condivisa, esempio: /media/condivisa

# mkdir /media/condivisa

editare il file /etc/fstab ed inserire

192.168.1.10:/media/storage /media/condivisa nfs user,rw,auto,hard  0   0

Nota:

• 192.168.1.10:/media/storage sono l'indirizzo e la directory del server
  • aggiungere tante entry quante sono le directory condivise
• /media/xxx directory raccomandata per montare le risorse
• /media/condivisa è la directory dove sarà montata la risorsa
• nfs è il tipo di file system
• user permette a qualsiasi utente di montare,anche manualmente,la risorsa
• rw sono i permessi di lettura e scrittura
  • modificare in ro se si desideramo solo permessi di lettura
• auto la risorsa viene montata automaticamente
  • modificare in noauto se si vuole montare la partizione manualmente

Editare il file /etc/hosts.allow ed aggiungere

portmap: 192.168.1.10

Ora avviare il demone e montare la partizione:

# /etc/init.d/nfs-common start
# mount -a

Squeeze e successive

Sia che si voglia caricare le risorse remote in modo statico che dinamico, La prima cosa da fare è assicurarsi che sul PC client sia installato il pacchetto nfs-common, in caso contrario installarlo. Editare il file /etc/default/nfs-common ed assicurarsi che la riga contente la variabile NEED_IDMAPD= appaia così:

NEED_IDMAPD=yes

Fatto ciò l'utente deve decidere se montare le risorse in modo statico o dinamico, NON È POSSIBILE adottare entrambe le soluzioni contemporaneamente.

IMPORTANTE: si noti che sul PC cliente se si decide di montare le risorse remote sotto la cartella /home/nome_utente allora tutte le cartelle compariranno anche sul desktop, proprio come se fosse stato collegato un disco esterno o una chiavetta USB. È possibile aggirare il problema creando la cartella in un'altra posizione e poi creando un collegamento simbolico alla stessa nella cartella utente.

METODO STATICO

Per montare staticamente una risorsa il comando da usare è il solito mount, infatti questo comando supporta una valanga di protocolli e filesystem, tra cui appunto NFS. Prima di montare le risorse remote è necessario creare il punto di mount locale, si supponga per esempio di voler montare le suddette risorse in /home/nfs (si sconsiglia di montare le risorse direttamente in cartelle già esistenti che contengono già altri file/cartelle, come /home o peggio /), ergo restando all'esempio:

# mkdir /home/nfs

Fatto ciò è possibile montare le risorse remote digitando da terminale:

# mount -t nfs4 -o _netdev,hard,intr indirizzo_server:/ /home/nfs

Dove con indirizzo_server si identifica il server con le risorse condivise; può essere nella forma di un IP (es.: 192.168.5.92) oppure di un alias (es.: mioserver, in tal caso come sempre si presuppone che il computer client sia in grado di risolvere correttamente l'alias). Si noti che si è scritto indirizzo_server:/ e non indirizzo_server:/home poiché nel file /etc/exports del server la cartella /home è stata definita come radice (si ricorda che saranno esportate automaticamente anche tutte le sotto cartelle della cartella indicata col comando mount). A questo punto sarà sufficiente esplorare la cartella /home/nfs per vedere le risorse esportate. Per smontare le risorse remote è sufficiente digitare:

# umount /home/nfs

Se si desidera caricare automaticamente le risorse remote all'avvio del PC, evitando così di dover ridigitare ogni volta il precedente comando, è sufficiente editare il file /etc/fstab aggiungendo in coda la seguente riga:

indirizzo_server:/ /home/nfs nfs _netdev,auto,hard,intr 0 0

NOTA Per il solo /etc/fstab l'indicazione come filesystem della dicitura nfs4 invece di nfs è deprecata.

Dove _netdev e auto sono due opzioni che impongono rispettivamente di aspettare che i dispositivi di rete siano stati caricati e di caricare automanticamente le risorse remote presenti su indirizzo_server.

Qualora l'utente non voglia caricare automaticamente le risorse all'avvio, ma contemporaneamente desideri poter montare (ed esplorare) le risorse con un semplice click del mouse, è possibile creare nel menù un lanciatore che richiami uno script di questo tipo:

#!/bin/bash
if [ -f /home/nfs/test ]; then
	gnome-terminal --window-with-profile=nome_profilo -e "echo 'Risorse remote già caricate!'"
else
	gnome-terminal -e "su -c 'mount -t nfs4 -o _netdev,hard,intr server:/ /home/nfs'"
	nautilus /home/nfs
fi

/home/nfs/test è un file qualsiasi che deve essere incluso nelle risorse remote da montare, può benissimo essere un semplice file di testo vuoto. In pratica lo script verifica l'esistenza del file test ed agisce di conseguenza. Come facilmente intuibile il file di test esiste per la macchina client solo se le risorse remote sono già state montate, quindi se la condizione è vera allora non è necessario montare nuovamente le risorse. In caso contrario provvede a montare le risorse (che di norma è un operazione che richiede privilegi di root) e quindi a mostrare tramite nautilus la cartella contenente le risorse appena montate. L'opzione --window-with-profile=nome_profilo è un artificio per impedire che la finestra del terminale si chiuda immediatamente dopo aver stampato a video il messaggio d'avviso; si richiede infatti a tal proposito di creare preventivamente un profilo del terminale in cui si sia specificato nelle preferenze di non chiudere il terminale dopo aver concluso l'esecuzione di un comando: dalla seconda scheda "Titolo e comando" selezionare "Mantieni aperto il terminale" per la voce "Quando il comando termina:". La finestra deve essere chiusa manualmente dall'utente, in modo del tutto normale.

Se non si desidera creare un lanciatore, ma eseguire direttamente lo script da terminale, allora lo script diviene:

#!/bin/bash
if [ -f /home/nfs/test ]; then
	echo "Risorse remote già caricate!"
else
	su mount -t nfs4 -o _netdev,hard,intr server:/ /home/nfs
	nautilus /home/nfs
fi

METODO DINAMICO

NOTA BENE: qualora si decida di abbandonare il metodo statico per quello dinamico è evidente che prima cosa è necessario smontare tutte le risorse montate staticamente che si intende gestire dinamicamente, e poi eliminare (o commentare) la riga eventualmente aggiunta al file /etc/fstab.

Per usare questo metodo è necessario il pacchetto autofs, pertanto se non installato procedere alla sua installazione:

apt-get install autofs5

Se l'utente desidera cambiare le impostazioni di base, come il tempo trascorso il quale il sistema smonta automaticamente le risorse, può farlo editando il file /etc/default/autofs.

A questo punto è necessario modificare con un editor il file auto.master

# gedit /etc/auto.master

aggiungendo in coda una riga del tipo /home/nfs /etc/auto.nfs. Questa riga dice che le risorse remote specificate nel file /etc/auto.nfs (naturalmente l'utente è liberissimo di scegliere un altro nome al posto di auto.nfs, basta essere coerenti nel seguito) andranno montante all'interno della cartella /home/nfs (che deve esistere! Autofs non crea il punto di mount). Come già scritto nel caso statico si sconsiglia di montare le risorse direttamente in cartelle già esistenti che contengono già altri file/cartelle, come /home o peggio /. È possibile definire più tipi di risorse remote inserendo più righe, il punto è che per ognuna è necessario indicare il punto di mount e il file contenente le relative istruzioni. A questo punto per quanto detto l'utente deve creare il suo file auto.nfs (o come è stato chiamato) usando il suo editor di testo preferito, ad esempio:

# gedit /etc/auto.nfs

che ovviamente apparirà vuoto essendo appena stato creato dall'utente. Inserire la seguente riga:

nome_arbitrario -fstype=nfs4,hard,intr indirizzo_server:/

Quanto appena scritto viene definito in gergo indirect map. Osservando la riga si nota subito essere composta da tre parti:

1. Key: in questo esempio è nome_arbitrario, a sottolineare che trattasi di una parola qualsiasi a scelta dell'utente. È il nome della sottocartella di /home/nfs/ in cui compariranno le risorse remote. Si badi bene che diversamente da quanto fatto in precedenza, la suddetta cartella viene creata al momento da autofs, quindi l'utente NON deve creare tale sottocartella in anticipo.
2. Options: banalmente la sezione delle opzioni, in questo caso sono tre cioè -fstype=nfs4, hard e intr. È naturalmente possibile specificare ulteriori opzioni (si veda il manuale di mount), basta separarle con una virgola.
3. Location: definisce il percorso per caricare le risorse remote. In quest'esempio è indirizzo_server:/ (si ricordi che / non indica la radice del filesystem del server, ma la cartella definita come radice in /etc/exports sul server, cioè /home restando all'esempio), che come già ripetuto può essere sia un IP che un alias.

Prima di rendere operativo automount assicurarsi di aver smontato eventuali risorse statiche relative al server per cui abbiamo configurato auto.nfs. Fatto ciò digitare:

# /etc/init.d/autofs reload

Un modo per testare se le risorse remote vengono montate correttamente è digitare da terminale:

$ ls /home/nfs/nome_arbitrario

Se il comando restituisce l'elenco di file e cartelle contenute nella cartella /home del server significa che l'operazione di automount è andata a buon fine. Le risorse remote rimangono montate di base fino a 10 minuti dall'ultimo accesso alle stesse (si veda il parametro timeo del file /etc/default/autofs).
Nota Bene: digitare ls /home/nfs/ non mostra nulla poiché il comando non è sufficiente ad innescare l'automount delle risorse remote, quindi viene mostrato il contenuto della sola cartella nfs che è vuota per costruzione (o meglio dovrebbe essere tale, visto che come già detto è sconsigliato montare risorse in una cartella contenente file e sotto cartelle). Per innescare l'automount serve proprio la parola chiave (la key) indicata nel file /etc/auto.nfs, cioè nome_arbitrario. Per lo stesso motivo in nautilus facendo click sulla cartella /home/nfs non apparirà nulla, bisogna invece cliccare su "vai --> posizione" e digitare /home/nfs/nome_arbitrario seguito da invio; in realtà anche questo non è detto che funzioni, in tal caso è d'obbligo l'uso del terminale digitando per esempio:

$ cd /home/nfs/nome_arbitrario

Fatto ciò le risorse risulteranno visibile anche in nautilus. Volendo è anche possibile creare un lanciatore cui associare miniscript per innescare automaticamente il montaggio delle cartelle remote in nautilus:

#!/bin/bash
gnome-terminal -e "ls /home/nfs/nome_arbitrario"
nautilus /home/nfs/nome_arbitrario

Possibili Problemi

Inconveniente 1

Tra i problemi tipici c'è quello di non riuscire a montare le risorse remote. Una prima verifica banale è quella di assicurarsi che la cartella dove devono essere montate le risorse remote sia indicata correttamente (per esempio /home/nfs è DIVERSO da /home/NFS). Una seconda causa potrebbe essere dovuta al numero della porta che NFS sceglie casualmente, infatti se il numero della porta è maggiore di 1024 scatta un errore di sicurezza; in tal caso è sufficiente aggiungere alle opzioni indicate nel file /etc/exports anche insecure, ad esempio:

/home       192.168.1.0/24(rw,fsid=0,no_subtree_check,sync,insecure)
/home/altro 192.168.1.0/24(rw,no_subtree_check,sync,insecure)

Un altro motivo potrebbe essere costituito dal set di permessi delle cartelle esportate; provare ad impostare temporaneamente i loro permessi su 777. Se il problema è risolto provare a reimpostare i permessi sul vecchio schema e vedere se l'errore si ripropone.

Inconveniente 2

Nel caso il server sia spento e sulla macchina client sia presente un collegamento simbolico alle risorse esterne, creato per esempio con un comando del tipo:

# ln -s /home/nfs/nome_arbitrario /home/nome_utente/nome_arbitrario

è probabile che si noti un ritardo di circa 2 minuti all'avvio di gnome (nel caso di caricamento automatico all'avvio) ed ogni volta che si lancia nautilus per visualizzare una qualche cartella. La semplice presenza del collegamento simbolico è infatti sufficiente ad innescare una richiesta di caricamento per le risorse remote, con la conseguenza che essendo il server spento queste falliscano inevitabilmente. Di base nfs è impostato per ripetere la richiesta di caricamento risorse dopo 2 minuti, ecco dunque da dove nascerebbero il ritardo sistematico. In tal caso la soluzione più semplice è rinunciare ai collegamenti simbolici verso le risorse remote caricate tramite nfs, altrimenti è possibile ridurre tale ritardo specificando nelle opzioni di mount (o di fstab o di auto.nfs, ecc.) retry=X, dove X è il nuovo numero di minuti (si noti che l'opzione retrans è utile solo nel caso si usi l'opzione soft e non hard). Può anche capitare che uno o più processi legati a nfs rimangano in sospeso nonostante il server sia normalmente funzionante; in tal caso se si sono specificate le opzioni hard,intr dovrebbe essere possibile uccidere i relativi processi con kill -9 pid, in caso contrario è probabile che non ci sia altra soluzione che riavviare brutalmente la macchina client. Altre problematiche sono descritte al punto 7 di questa pagina.

Inconveniente 3

Potrebbe capitare che trasferendo grossi file il server si congeli obbligando ad un riavvio forzato, in tal caso potrebbe essere utile specificare sulla macchina client le opzioni rsize (influenza le operazioni di scrittura sulla macchina client) e wsize (influenza le operazioni di scrittura sulla macchina server) indicando valori non troppo grandi, per esempio:

• Caso statico: mount -t nfs4 -o _netdev,rsize=4096,wsize=4096,hard,intr indirizzo_server:/ /home/NFS

• Caso statico, file /etc/fstab aggiungere (o modificare quella già esistente): indirizzo_server:/ /home/NFS nfs4 _netdev,auto,rsize=4096,wsize=4096,hard,intr 0 0

• Caso dinamico, file /etc/auto.nfs aggiungere (o modificare quella già esistente) nome_arbitrario -fstype=nfs4,_netdev,rsize=4096,wsize=4096,hard,intr indirizzo_server:/

A tal proposito potrebbe essere utile leggere questo.

Inconveniente 4

Potrebbe anche capitare nel caso di NFSv4 che la macchina client veda crollare drasticamente a poche centinaia di kb/s la velocità di trasferimento dati quando si va a scrivere sulla macchina server grossi file. In tal caso controllare in primis di usare l'opzione crossmnt invece di nohide (si riveda la sezione dedicata al rimontaggio delle cartelle), se anche questo non funziona provare ad aggiungere nel file exports le opzioni async e no_wdelay ad ogni cartella da esportare. Un'altra possibilità è provare ad usare il protocollo UDP invece di TCP, si tratta di aggiungere l'opzione proto=UDP al comando mount (trattasi cioè di un opzione lato client). Se anche questo non dovesse funzionare provare a guardare questa pagina (si tratta di ricompilare il kernel, sempre che poi sia proprio questo il problema).

Prestazioni

È possibile migliorare le prestazioni affinando i valori dei vari parametri, ed è argomento tutt'altro che ridotto, come dimostrato qui e qui.
I primi parametri da controllare sono tuttavia rsize e wsize, che di base valgono 8192 per NFSv2-NFSv3 e 32768 per NFSv4. Stando al manuale tali valori devono essere multipli interi di 1024 e compresi tra un minimo di 4096 byte e 1048576 byte.

Esempio 1

• Cavo rete sstp cat.6, L = 50 m;
• Server: Debian Wheezy, AMD Sempron 145 2,8 GHz, scheda di rete GBit integrata, HD 2,5" sata II 5400 rpm ext4, DDr2 2 GB 667 Mhz ram;
• Client: Debian Wheezy, Intel Core Duo 2 3 GHz, scheda di rete GBit integrata, HD 3,5" sata II 5400-7200 rpm (caviar green) ext4, DDr2 3 GB 1066 Mhz ram;
• File trasferito: video '.mkv' da 8 GB.
  
• NFSv4: rsize=wsize=65536,sync,TCP,no_subtree_check,hard,intr;
  • Velocità media trasferimento Server --> Client: 49,8 MB/s circa
  • Velocità media trasferimento Client --> Server: 72,8 MB/s circa
    
• SFTP;
  • Velocità media trasferimento Server --> Client: 22,8 MB/s circa
  • Velocità media trasferimento Client --> Server: 26,3 MB/s circa

Esempio 2

• Come esempio 1 salvo ove diversamente specificato;
• Server: Debian Squeeze, AMD Athlon (slot A) 650 MHz, scheda di rete GBit PCI, HD 3,5" ATA100 5400 rpm ext4 lvm2, DIMM 364 MB ram 100 Hz;
  
• NFSv4: rsize=wsize=8192,sync,TCP,no_subtree_check,hard,intr;
  • Velocità media trasferimento: 15 MB/s circa
    
• SFTP;
  • Velocità media trasferimento: 5,5 MB/s circa
    

Riferimenti esterni

Manuali:
man nfs, nfs
man portmap, portmap
man 5 autofs, autofs(5)
man 5 auto.master, auto.master(5)
man mount, mount(8).

Pagine web:

• Sourceforge, pagina ufficiale.
• linux-nfs.
• linux-tutorial.
• fsid spiegato.
• prestazioni di rete, come migliorarle.
  
• Network File Systems, definizione wikipedia.

Suggerimento Per favore se modifichi questa guida aggiungi nel box "NOTE" sottostante "Estesa da: mio_nome_utente", se invece l'hai semplicemente consultata, ma ne hai verificato personalmente la correttezza aggiungi sempre nello stesso box "Verificata da: mio_nome_utente". In questo modo aiuti la comunità a tenere traccia della maturità della guida.

NOTE Autore: xtow Esteso da Wtf 17:13, 5 giu 2011 (CEST)