Nfs-kernel-server: possibili problemi e prestazioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
NFS

Sommario

Spazio Kernel
  1. Lato server
  2. Lato client

Diagnostica

Comandi utili

Determinare le versioni di protocollo ammesse dal server mio_server: 

# rpcinfo -p mio_server

Un output del seguente tipo dimostra che tutti i protocolli sono abilitati: 

100003    2   tcp   2049  nfs
100003    3   tcp   2049  nfs
100003    4   tcp   2049  nfs
100003    2   udp   2049  nfs
100003    3   udp   2049  nfs
100003    4   udp   2049  nfs
100005    1   udp  39543  mountd
100005    1   tcp  57880  mountd
100005    2   udp  55276  mountd
100005    2   tcp  37396  mountd
100005    3   udp  43230  mountd
100005    3   tcp  59453  mountd

rpc.mountd è in sintesi il demone che si occupa di esportare le risorse da condividere per i protocolli v1, v2 e v3. Se nel precedente elenco non dovessero comparire le righe relative a mountd per una certa versione del protocollo, è possibile che non si riesca ad accedere alle risorse condivise usando la relativa versione del protocollo di NFS.

Visualizzare le risorse montate sul client in uso tramite protocolli v2-v3: 

# mount -l -t nfs

Visualizzare le risorse montate sul client in uso tramite protocollo v4: 

# mount -l -t nfs4

Entrambi i suddetti comandi permettono quindi di accertarsi che una certa risorsa oltre che essere effettivamente montata utilizzi anche la versione di protocollo desiderata.

Visualizzare le risorse esportate dal server mio_server: 

# showmount -e mio_server

Visualizzare le proprietà del collegamento col/i server NFS (compresa la versione del protocollo in uso): 

# nfsstat -m

Errori

Le risorse remote non vengono caricate...

...nemmeno manualmente con mount

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 (nfsv4): 

/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.

...in automatico all'avvio

Se le risorse remote non vengono automaticamente caricate all'avvio, ma è comunque possibile caricarle manualmente, assicurarsi in primis che nella riga dedicata al caricamento delle risorse remote in /etc/fstab/ sia presente l'opzione _netdev, se assente, aggiungerla e provare a riavviare. In caso contrario provare ad aggiungere alle predette opzioni della risorsa anche auto, quindi riavviare. A questo punto eseguire: 

# mount -a

Se la risorsa remota viene caricata correttamente il problema riguarda molto probabilmente la sequenza di operazioni all'avvio. Per prima cosa si controlli il file /var/log/syslog alla ricerca di un messaggio come il seguente:
if-up.d/mountnfs[eth0]: if-up.d/mountnfs[eth0]: lock /var/run/network/mountnfs exist, not mounting

Il messaggio compare

Digitare: 

# ls -ahl /var/run/network/mountnfs

Se la cartella è vuota, a meno dei soliti . e .., eliminarla: 

# rm -R /var/run/network/mountnfs

Altrimenti limitarsi a rinominarla, per esempio digitando: 

# mv /var/run/network/mountnfs /var/run/network/nome_a_caso

A questo punto riavviando le risorse dovrebbero venir automaticamente caricate all'avvio.

Il messaggio non compare

Il problema potrebbe essere di tipo temporale, ovvero il sistema tenta di montare la risorsa remota prima che l'interfaccia di rete sia correttamente configurata, altrimenti è probabile che ci sia un qualche errore nella relativa riga di fstab.
Nel primo caso se si usa uno strumento grafico come network-manager, il primo tentativo da fare è provare a configurare le interfacce di rete tramite /etc/network/interfaces, quindi riavviare.
Se il problema persiste si hanno ancora alcune opzioni:

  • Aggiungere alla riga di fstab relativa alla risorsa samba l'opzione auto ed inserire nello script /etc/rc.local il comando mount -a. Val la pena notare che non si tratta di una soluzione, ma di un brutale trucco per aggirare il problema (anche se generalmente efficace).
  • Uso di uno script personalizzato che provveda al montaggio delle risorse invece di fstab; si noti in tal senso che lo strumento grafico wicd permette di associare script a particolari eventi.
  • Sostituire il caricamento automatico all'avvio tramite fstab con l'utilizzo di autofs, uno strumento che permette il caricamento dinamico delle risorse remote su imput dell'utente.

Accesso in sola lettura o nessun accesso

La prima cosa da fare è verificare di aver definito correttamente i giusti permessi lato server, sia direttamente sulle directory condivise sia nel file /etc/exports. Se è effettivamente tutto giusto allora potrebbe essere un problema di mappatura utenti non corretta.

Avvio lento dei client con server spento

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.

Il server si congela durante il trasferimento di grossi file

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.

Crollo della velocità di trasferimento dati

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).

Problemi di UID e GID

Info.png Nota
  • Per prima cosa smontare sempre le eventuali risorse remote montate, solo dopo procedere.
  • Ricordare poi che nel caso del server potrebbe essere necessario riavviare nfs-kernel-server dopo aver riavviato nfs-common.


Mappatura utenti non corretta

È possibile che pur avendo configurato correttamente server e client l'accesso alle risorse non sia completo come invece ci si aspetterebbe. Una tipica causa è una scorretta mappatura degli utenti tra client e server, ovvero un diverso valore di UID per lo stesso utente tra server e client; si sottolinea che questa situazione non può evidentemente verificarsi in quelle reti dove l'autenticazione degli utenti è centralizzata tramite controller di dominio.
Come già detto nella sezione sicurezza della pagina principale i permessi unix degli utenti sono attribuiti esclusivamente tramite il loro UID, pertanto se pur avendo gli stessi utenti su server e client questi sono stati creati in ordine differente si avrà appunto una discrepanza tra UID del client e del server. Questo potrebbe comportare che per il server l'utente Caio ha UID=1000, mentre per il client ha UID=1001; in tal caso quando Caio dalla sua macchina client accede alle risorse del server non gli vengono attribuiti i permessi unix di Caio, ma quelli dell'utente che sul server ha UID=1001. Evidentemente se si è impostata una risorsa per consentire l'accesso in lettura e scrittura solo a Caio, quest'ultimo si vedrà negato il permesso di scrittura quando accede alle risorse tramite NFS, proprio perché non gli vengono attribuiti i permessi unix di Caio.
In tale circostanza quindi l'utente o permette l'accesso in scrittura a tutti, oppure deve cambiare sul client (o sul server) l'UID dell'utenza desiderata in modo che il valore sia il medesimo per entrambi.

4294967294:4294967294 (nfsv4)

Se dal lato client si ottiene il valore 4294967294 (che significa "-1" sui sistemi a 64 bit) come GID/UID di file e/o cartelle remote allora molto probabilmente esiste un problema di mappatura utenti tra client e server. Nel caso si utilizzi il protocollo v4 assicurarsi che nel file /etc/default/nfs-common del client risulti essere impostato NEED_IDMAPD=yes (scrivere yes minuscolo per sicurezza). Se così non fosse modificare tale file e riavviare nfs-common: 

/etc/init.d/nfs-common restart

nobody:nogroup (nfsv4)

Assicurarsi che i file /etc/idmapd.conf del server e dei client siano coerenti tra loro, in particolare assicurarsi che la voce Domain sia la medesima per tutte le macchine. Si riveda la relativa sezione nella pagina di configurazione del server.
Si noti infine che anche se i gruppi e gli utenti figurano tutti come nogroup e nobody questo non significa a priori che gli utenti non siano stati mappati correttamente, ovvero è tranquillamente possibile che ogni utente abbia accesso alle risorse condivise con i permessi corretti pur vedendo (lato client) utente e gruppo sempre come nobody:nogroup.

mount.nfs: access denied by server while mounting

Assicurarsi che sul server la cartella da montare abbia i permessi corretti, in particolare nel caso di nfsv4 accertarsi che i permessi della cartella definita come radice siano almeno 755, ovvero che sia accessibile in lettura a chiunque.

Altro

Si provi questa pagina

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

  • LAN Gigabit, 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
Estratto da "https://guide.debianizzati.org/index.php?title=Nfs-kernel-server:_possibili_problemi_e_prestazioni&oldid=31701"