Questa è la sezione delle FAQ. È basata su una vecchia FAQ di NFS di Alan Cox.
Se si verificano problemi montando un filesystem, verificate se il vostro problema è descritto nella sezione "Elenco di verifica di mount".
Ciò è causato da un bug in alcune vecchie versioni di nfsd. È stato corretto a partire da nfs-server2.2beta16
can't register with portmap: system error on send
Probabilmente state usando un sistema basato sulla distribuzione Caldera. C'è un bug negli script rc. Contattate Caldera per ottenere la versione corretta.
Il fatto è che nfsd tiene una cache dei file aperti per motivi di prestazioni (ricordate, gira in un ambiente utente). Mentre nfsd ha un file aperto (come nel caso di una scrittura), il kernel non ne consente l'esecuzione. Le versioni di nfsd più recenti di spring 95 rilasciano i file aperti dopo qualche secondo, versioni più vecchie possono impiegare anni...
Il default per il server NFS di Linux è di montare i filesystem
in sola lettura. Leggete le sezioni "Mountd e nsfd" ed "Esportare
filesystem" in questo HOWTO e fate riferimento alle pagine man di exports e nfsd. Avrete bisogno di modificare
/etc/exports.
Su versioni più vecchie di Linux occorre lanciare il server NFS con
rsize=1024,wsize=1024.
Allora semplicemente non fatelo. Questo non si verifica con i kernel 2.0 e 2.2. Per quanto mi ricordo non dovrebbero esserci problemi nemmeno con la versione 1.2.
Al momento no.
Accertatevi che l'utente sia in 8 gruppi o meno. Server più vecchi lo richiedono.
Non smontate server NFS quando riavviate. Ignorateli, non
causano problemi se non li si smonta. Il comando è umount -avt nonfs.
Normalmente NFS scrive i dati in modo sincrono (è possibile disabilitare questa modalità lo si desidera, ma si rischia di perdere dei dati). Funzionano peggio i kernel derivati da BSD, che tendono a non essere in grado di lavorare in piccoli blocchi, quindi quando si scrivono 4K di dati da una macchina Linux in pacchetti da 1K, BSD fa questo:
lettura di una pagina da 4K
modifica di 1K
scrittura di 4K sul disco fisico
lettura di una pagina da 4K
modifica di 1K
scrittura di 4K sul disco fisico
ecc..
Il protocollo NFS usa pacchetti UDP frammentati. Il kernel ha un
limite sulla quantità di frammenti di pacchetti incompleti di cui
può disporre prima di eliminare i pacchetti. Nella versione 2.2
il protocollo è adattabile in runtime attraverso il filesystem /proc:
/proc/sys/net/ipv4/ipfrag_high_thresh e
ipfrag_low_thresh. Nella versione 2.0 queste sono le costanti di runtime
definite in .../linux/net/ipv4/ip_fragment.c,
IPFRAG_HIGH_THRESH e IPFRAG_LOW_THRESH. Il
significato di questi valori è costituito dal fatto che quando
l'occupazione della memoria dei frammenti UDP non assemblati
raggiunge il limite ``ipfrag_high_thresh'' in
byte (256K per default in 2.2.3 e 2.0.36) viene ridotta a
``ipfrag_low_tresh'' improvvisamente. Questa operazione viene
effettuata eliminando i frammenti. È simile alla perdita di
pacchetti e se il limite più elevato viene raggiunto, le
prestazioni del server calano notevolmente.
256K è sufficiente per un numero pari a 30 client. Se ne avete 60, raddoppiatelo. E raddoppiate anche il limite inferiore.
Knfsd indica che viene implementata la versione 3 di NFS. Ma questo non avviene.
Esiste un'opzione per evitare che annunci questa versione. Usatela.
Oppure potete immettere "vers=2" nell'elenco di opzioni di montaggio sui client.
mount: 1831-011 access denied for server:/dir
mount: 1831-008 giving up on:
server:/dir
The file access permissions do not allow the specified action.
AIX 4.2 ha utilizzato porte riservate (<1024) per NFS. AIX 4.2.1 e 4.3 non sono limitati a porte riservate. Inoltre, AIX 4.2.1 e 4.3 cercano di effettuare il montaggio mediante NFS3, quindi NFS/TCP, infine NFS/UDP.
L'aggiunta di
nfso -o nfs_use_reserved_ports=1
alla fine di rc.tcpip forzerà l'utilizzo di porte riservate.
(Questo suggerimento è stato fornito da Brian Gorka)