2 894
contributi
Wtf (discussione | contributi) |
Wtf (discussione | contributi) |
||
(7 versioni intermedie di 2 utenti non mostrate) | |||
Riga 51: | Riga 51: | ||
==== ...in automatico all'avvio ==== | ==== ...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.< | 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: | ||
<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 /> | ''if-up.d/mountnfs[eth0]: if-up.d/mountnfs[eth0]: lock /var/run/network/mountnfs exist, not mounting''<br /> | ||
===== Il messaggio compare ===== | |||
Digitare: | |||
<pre># ls -ahl /var/run/network/mountnfs</pre> | <pre># ls -ahl /var/run/network/mountnfs</pre> | ||
Se la cartella è vuota, a meno dei soliti <code>.</code> e <code>..</code>, eliminarla: | Se la cartella è vuota, a meno dei soliti <code>.</code> e <code>..</code>, eliminarla: | ||
Riga 61: | Riga 65: | ||
<pre># mv /var/run/network/mountnfs /var/run/network/nome_a_caso</pre> | <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. | 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 === | === 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 | | 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 === | === Avvio lento dei client con server spento === | ||
Riga 101: | Riga 113: | ||
È 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 /> | È 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 | 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. | 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. | ||
Riga 113: | Riga 125: | ||
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/> | 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>. | 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 === | === Altro === | ||
Riga 125: | Riga 141: | ||
=== Esempio 1 === | === 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; | * 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; | * 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 144: | Riga 160: | ||
* SFTP; | * SFTP; | ||
** Velocità media trasferimento: 5,5 MB/s circa | ** Velocità media trasferimento: 5,5 MB/s circa | ||
[[Categoria:Condivisione_risorse]] | |||
[[Categoria:NFS]] |
contributi