Nfs-kernel-server: possibili problemi e prestazioni: differenze tra le versioni

← Differenza precedente

Nfs-kernel-server: possibili problemi e prestazioni (visualizza wikitesto)

Versione delle 10:51, 17 gen 2013

7 230 byte aggiunti , 17 gen 2013

→‎...in automatico all'avvio

Wtf

2 894

contributi

@@ Riga 1: / Riga 1: @@
 {{NFS}}
-= Troubleshooting =
+= Diagnostica =
+== Comandi utili ==
+Determinare le versioni di protocollo ammesse dal server ''mio_server'':
+<pre># rpcinfo -p mio_server</pre>
+Un output del seguente tipo dimostra che tutti i protocolli sono abilitati:
+<pre>
+    2   tcp   2049  nfs
+    3   tcp   2049  nfs
+    4   tcp   2049  nfs
+    2   udp   2049  nfs
+    3   udp   2049  nfs
+    4   udp   2049  nfs
+    1   udp  39543  mountd
+    1   tcp  57880  mountd
+    2   udp  55276  mountd
+    2   tcp  37396  mountd
+    3   udp  43230  mountd
+    3   tcp  59453  mountd
+</pre>
+''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.<br/>
+<br/>
+Visualizzare le risorse montate sul client in uso tramite protocolli v2-v3:
+<pre># mount -l -t nfs</pre>
+Visualizzare le risorse montate sul client in uso tramite protocollo v4:
+<pre># mount -l -t nfs4</pre>
+Entrambi i suddetti comandi permettono quindi di accertarsi che una certa risorsa oltre che essere effettivamente montata utilizzi anche la versione di protocollo desiderata.<br/>
+<br/>
+Visualizzare le risorse esportate dal server ''mio_server'':
+<pre># showmount -e mio_server</pre>
+Visualizzare le proprietà del collegamento col/i server NFS (compresa la versione del protocollo in uso):
+<pre># nfsstat -m</pre>
+== Errori ==
 === Le risorse remote non vengono caricate... ===
@@ Riga 6: / Riga 40: @@
 ==== ...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 <code>/home/nfs</code> è DIVERSO  da <code>/home/NFS</code>). 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 <code>/etc/exports</code> anche ''insecure'', ad  esempio:
+Una prima verifica banale è quella di assicurarsi che la  cartella dove devono essere montate le risorse remote sia indicata correttamente (per esempio <code>/home/nfs</code> è DIVERSO  da <code>/home/NFS</code>). 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 <code>/etc/exports</code> anche ''insecure'', ad  esempio (nfsv4):
 <pre>
@@ Riga 17: / Riga 51: @@
 ==== ...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 <code>/etc/fstab/</code> sia presente l'opzione ''_netdev'', se assente, aggiungerla e provare a riavviare.<br />
+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 <code>/etc/fstab/</code> sia presente l'opzione ''_netdev'', se assente, aggiungerla e provare a riavviare. In caso contrario provare ad aggiungere alle predette opzioni della risorsa anche <code>auto</code>, quindi riavviare. A questo punto eseguire:
-Qualora il problema persista controllare il file <code>/var/log/syslog</code> alla ricerca di un messaggio come il seguente:<br />
+<pre># mount -a</pre>
+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
+<code>/var/log/syslog</code> alla ricerca di un messaggio come il seguente:<br />
 ''if-up.d/mountnfs[eth0]: if-up.d/mountnfs[eth0]: lock /var/run/network/mountnfs exist, not mounting''<br />
-In caso affermativo digitare:
+===== Il messaggio compare =====
+Digitare:
 <pre># ls -ahl /var/run/network/mountnfs</pre>
 Se la cartella è vuota, a meno dei soliti <code>.</code> e <code>..</code>, eliminarla:
@@ Riga 27: / Riga 65: @@
 <pre># mv /var/run/network/mountnfs /var/run/network/nome_a_caso</pre>
 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 <code>fstab</code>.<br>
+Nel primo caso se si usa uno strumento grafico come <code>network-manager</code>, il primo tentativo da fare è provare a configurare le interfacce di rete tramite <code>/etc/network/interfaces</code>, quindi riavviare.<br>
+Se il problema persiste si hanno ancora alcune opzioni:
+* Aggiungere alla riga di fstab relativa alla risorsa samba l'opzione <code>auto</code> ed inserire nello script <code>/etc/rc.local</code> il comando <code>mount -a</code>. 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 <code>fstab</code>; si noti in tal senso che lo strumento grafico <code>wicd</code> permette di associare script a particolari eventi.
+* Sostituire il caricamento automatico all'avvio tramite fstab con l'utilizzo di <code>autofs</code>, 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 <code>/etc/exports</code>. Se è effettivamente tutto giusto allora potrebbe essere un problema di [[#Mappatura utenti non corretta | mappatura utenti non corretta]].
 === Avvio lento dei client con server spento ===
@@ Riga 53: / Riga 103: @@
 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  <code>crossmnt</code> invece di  <code>nohide</code> (si riveda la sezione dedicata al  rimontaggio delle cartelle), se anche questo non funziona provare ad  aggiungere nel file <code>exports</code> le opzioni  <code>async</code> e <code>no_wdelay</code> ad  ogni cartella da esportare. Un'altra possibilità è provare ad usare il  protocollo UDP invece di TCP, si tratta di aggiungere l'opzione  <code>proto=UDP</code> al comando  <code>mount</code> (trattasi cioè di un opzione lato  client). Se anche questo non dovesse funzionare provare a guardare   [https://bugs.launchpad.net/ubuntu/+source/linux/+bug/585657 questa  pagina] (si tratta di ricompilare il kernel, sempre che poi sia proprio  questo il problema).
+=== Problemi di UID e GID ===
+{{Box|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.<br />
+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.<br />
+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 <code>/etc/default/nfs-common</code> del client risulti essere impostato <code>NEED_IDMAPD=yes</code> (scrivere yes minuscolo per sicurezza). Se così non fosse modificare tale file e riavviare nfs-common:
+<pre>/etc/init.d/nfs-common restart</pre>
+==== nobody:nogroup (nfsv4) ====
+Assicurarsi che i file <code>/etc/idmapd.conf</code> 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 [[Nfs-kernel-server: configurazione lato server#idmapd.conf | sezione]] nella pagina di configurazione del server.<br/>
+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 <code>nobody:nogroup</code>.
+=== 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 [http://www.tldp.org/HOWTO/NFS-HOWTO/troubleshooting.html questa pagina]
 = Prestazioni =
@@ Riga 61: / Riga 141: @@
 === Esempio 1 ===
-* Cavo rete sstp cat.6, L = '''50''' m;
+* 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;
@@ Riga 80: / Riga 160: @@
 * SFTP;
 ** Velocità media trasferimento: 5,5 MB/s circa
+[[Categoria:Condivisione_risorse]]
+[[Categoria:NFS]]