Servizio file di rete. Come tutto cominciò

Il protocollo Network File Server (NFS) è uno standard aperto per fornire agli utenti l'accesso remoto ai file system. I suoi file system centralizzati semplificano l'esecuzione di attività quotidiane come backup o scansione antivirus e le partizioni del disco consolidate sono più facili da mantenere rispetto a molte piccole e distribuite.

Oltre a fornire funzionalità di archiviazione centralizzata, NFS si è dimostrato molto utile per altre applicazioni, inclusi thin client e senza disco, clustering di rete e middleware collaborativo.

Una migliore comprensione sia del protocollo stesso che dei dettagli della sua attuazione renderà più facile far fronte alle attività pratiche. Questo articolo si concentra su NFS ed è composto da due parti logiche: in primo luogo, descrive il protocollo stesso e gli obiettivi fissati durante il suo sviluppo, quindi l'implementazione di NFS su Solaris e UNIX.

DOVE TUTTO HA INIZIO CON...

NFS è stato sviluppato da Sun Microsystems ed è apparso su Internet nel 1989 come RFC 1094 con il titolo NFS (Network File System Protocol Specification). È interessante notare che la strategia di Novell all'epoca era quella di migliorare ulteriormente i servizi di file. Fino a poco tempo fa, prima che il movimento open source prendesse slancio, Sun non era ansiosa di rivelare i segreti delle sue soluzioni di rete, ma anche allora l'azienda ha compreso l'importanza dell'interoperabilità con altri sistemi.

RFC 1094 conteneva due specifiche originali. Al momento della sua pubblicazione, Sun stava già sviluppando la successiva, terza versione della specifica, definita nella specifica del protocollo RFC 1813 NFS versione 3. La versione 4 di questo protocollo è definita nel protocollo RFC 3010 NFS versione 4.

NFS è ampiamente utilizzato su tutti i tipi di host UNIX, reti Microsoft e Novell e soluzioni IBM come AS400 e OS/390. Sconosciuto al di fuori del regno della rete, NFS è forse il filesystem di rete indipendente dalla piattaforma più utilizzato.

IL PROFESSORE ERA UNIX

Sebbene NFS sia un sistema indipendente dalla piattaforma, UNIX è il suo antenato. In altre parole, la gerarchia dell'architettura ei metodi di accesso ai file, inclusa la struttura del file system, come identificare utenti e gruppi e come lavorare con i file, sono tutti molto simili al file system UNIX. Ad esempio, il file system NFS, essendo identico nella struttura al file system UNIX, è montato direttamente su di esso. Quando si lavora con NFS su altri sistemi operativi, le credenziali dell'utente e i permessi dei file vengono mappati.

NFS

NFS è progettato per l'uso in un'architettura client-server. Il client accede al file system esportato dal server NFS tramite un punto di montaggio sul client. Questo accesso è in genere trasparente per l'applicazione client.

A differenza di molti sistemi client/server, NFS utilizza le chiamate di procedura remota (RPC) per scambiare informazioni. Tipicamente, il client stabilisce una connessione a una porta predeterminata e quindi, in accordo con le specifiche del protocollo, invia una richiesta per eseguire un'azione specifica. Nel caso di una chiamata di procedura remota, il client crea una chiamata di procedura e poi la invia al server per l'esecuzione. Di seguito verrà presentata una descrizione dettagliata di NFS.

Ad esempio, supponiamo che un client abbia montato la directory usr2 sul filesystem root locale:

/root/usr2 / -> remote: /root/usr/

Se un'applicazione client necessita delle risorse di questa directory, invia semplicemente una richiesta al sistema operativo per essa e per il nome del file, e quest'ultimo concede l'accesso tramite il client NFS. Ad esempio, si consideri un semplice comando UNIX cd, che "non sa nulla" dei protocolli di rete. Squadra

Cd / root / usr2 /

posizionerà la directory di lavoro sul file system remoto, "senza nemmeno sapere" (l'utente non ha bisogno nemmeno di questo) che il file system è remoto.

Dopo aver ricevuto la richiesta, il server NFS verificherà che l'utente indicato abbia il diritto di eseguire l'azione richiesta e, in caso di risposta positiva, la eseguirà.

Avviciniamoci

Dal punto di vista di un client, il processo di montaggio di un file system remoto in locale utilizzando NFS prevede diversi passaggi. Come accennato, il client NFS emetterà una chiamata di procedura remota da eseguire sul server. Nota che su UNIX, il client è un singolo programma (comando mount), mentre il server è effettivamente implementato come diversi programmi con il seguente set minimo: port mapper, mount daemon e server NFS ...

Inizialmente, il comando di montaggio del client interagisce con il servizio di traduzione della porta del server, che ascolta le richieste sulla porta 111. La maggior parte delle implementazioni di montaggio del client supporta più versioni di NFS, il che aumenta la probabilità di trovare una versione del protocollo comune tra il client e il server. La ricerca viene effettuata partendo dalla versione più vecchia, quindi quando ne viene trovata una condivisa, diventerà automaticamente la versione più recente supportata dal client e dal server.

(Il materiale presentato è incentrato sulla terza versione di NFS, poiché è la più diffusa al momento. La quarta versione non è ancora supportata dalla maggior parte delle implementazioni.)

Il servizio di traduzione delle porte del server risponde alle richieste in base al protocollo e alla porta supportati su cui è in esecuzione il demone di montaggio. Il programma del client di montaggio si connette prima al daemon di montaggio del server e quindi esegue l'RPC del comando di montaggio su di esso. Se questa procedura ha esito positivo, l'applicazione client si connette al server NFS (porta 2049) e, utilizzando una delle 20 procedure remote definite in RFC 1813 ed elencate nella Tabella 1, ottiene l'accesso al file system remoto.

Il significato della maggior parte dei comandi è intuitivo e non crea difficoltà agli amministratori di sistema. L'elenco tcdump di seguito illustra il comando read generato dal comando UNIX cat per leggere un file denominato file-test:

10:30: 16.012010 eth0> 192.168.1.254. 3476097947>192.168.1.252.2049: 144 lookup fh 32.0 / 224145 "file-test" 10:30: 16.012010 eth0>192.168.1.254. 3476097947> 192.168.1.252.2049: 144 ricerca fh 32.0 / 224145 "file-test" 10: 30: 16.012729 eth0 192.168.1.254.3476097947: risposta ok 128 ricerca fh 32.0 / 224307 (DF) 10:30: 16.012729 eth0 192.168. 1.254.3476097947: risposta ok 128 lookup fh 32.0 / 224307 (DF) 10: 30: 16.013124 eth0>192.168.1.254. 3492875163>192.168.1.252.2049: 140 read fh 32.0 / 224307 4096 byte @ 0 10:30: 16.013124 eth0>192.168.1.254. 3492875163> 192.168.1.252.2049: 140 read fh 32.0 / 224307 4096 bytes @ 0 10: 30: 16.013650 eth0 192.168.1.254.3492875163: risposta ok 108 read (DF) 10: 30: 16.013650 eth0 192.168.1.254.3492875163 : risposta ok 108 leggi (DF)

NFS è stato tradizionalmente implementato su UDP. Tuttavia, alcune versioni di NFS supportano TCP (il supporto TCP è definito nelle specifiche del protocollo). Il vantaggio principale del TCP è un meccanismo di ritrasmissione più efficiente in reti inaffidabili. (Nel caso di UDP, se si verifica un errore, viene reinviato il messaggio RPC completo, costituito da diversi pacchetti UDP. Se è presente il protocollo TCP, viene reinviato solo il pezzo rotto.)

ACCESSO IN NFS

Le implementazioni NFS generalmente supportano quattro modi per garantire i diritti di accesso: tramite attributi utente/file, a livello di risorsa condivisa, a livello di nodo master e una combinazione di altri metodi di accesso.

Il primo metodo si basa sul sistema di autorizzazioni file integrato di UNIX per un singolo utente o gruppo. Per semplificare la manutenzione, le identità di utenti e gruppi dovrebbero essere coerenti in tutti i client e server NFS. La sicurezza deve essere considerata con attenzione: NFS può inavvertitamente concedere l'accesso a file non previsti quando sono stati creati.

L'accesso alle risorse condivise consente di limitare i diritti per consentire solo azioni specifiche, indipendentemente dalla proprietà dei file o dai privilegi UNIX. Ad esempio, l'utilizzo del file system NFS può essere limitato alla sola lettura. La maggior parte delle implementazioni NFS consente di limitare ulteriormente l'accesso alle risorse condivise a utenti e/o gruppi specifici. Ad esempio, il gruppo "Risorse umane" è autorizzato a visualizzare le informazioni e nient'altro.

L'accesso al nodo master consente solo il montaggio del filesystem su nodi specifici, il che è generalmente una buona idea poiché i filesystem possono essere facilmente creati su qualsiasi nodo compatibile con NFS.

L'accesso combinato combina semplicemente i tipi precedenti (ad esempio, l'accesso a livello di risorse condivise con l'accesso concesso a un utente specifico) o consente agli utenti di lavorare con NFS solo da un nodo specifico.

NFS IN STILE PINGUINO

Il materiale relativo a Linux presentato è basato su Red Hat 6.2 con un kernel 2.4.9 fornito con il pacchetto 0.1.6 nfs-utils. Ci sono versioni più recenti: al momento in cui scriviamo, l'aggiornamento più recente al pacchetto nfs-utils è 0.3.1. Può essere scaricato all'indirizzo:.

Il pacchetto nfs-utils contiene i seguenti binari: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount e statd.

Sfortunatamente, a volte il supporto NFS crea confusione per gli amministratori Linux, poiché la disponibilità di questa o quella funzionalità dipende direttamente dai numeri di versione sia del kernel che del pacchetto nfs-utils. Fortunatamente, la situazione in quest'area sta attualmente migliorando: gli ultimi kit di distribuzione includono le ultime versioni di entrambi. Per i rilasci precedenti, la Sezione 2.4 dell'NFS-HOWTO fornisce un elenco completo delle funzionalità di sistema disponibili per ogni combinazione di kernel e pacchetto nfs-utils. Gli sviluppatori mantengono la retrocompatibilità del pacchetto con le versioni precedenti con una forte attenzione alla sicurezza e alle correzioni di bug.

Il supporto NFS dovrebbe essere avviato al momento della compilazione del kernel. Se necessario, anche la funzionalità NFS versione 3 dovrebbe essere aggiunta al kernel.

Per le distribuzioni che supportano linuxconf, è facile configurare i servizi NFS sia per i client che per i server. Tuttavia, il modo rapido per installare NFS utilizzando linuxconf non fornisce informazioni su quali file sono stati creati o modificati, il che è molto importante che un amministratore sappia per comprendere la situazione in caso di errore del sistema. L'architettura NFS di Linux è vagamente correlata a BSD, quindi i file e i programmi di supporto necessari sono facili da trovare per gli amministratori con BSD, Sun OS 2.5 o versioni precedenti di NFS.

Il file /etc/exports, come nelle versioni precedenti di BSD, definisce i filesystem a cui i client NFS possono accedere. Inoltre, contiene una serie di funzionalità aggiuntive relative a problemi di gestione e sicurezza, offrendo all'amministratore un mezzo per la messa a punto. È un file di testo composto da voci, righe vuote o commentate (i commenti iniziano con un #).

Supponiamo di voler dare ai client l'accesso in sola lettura alla directory /home sul nodo Lefty. La seguente voce corrisponderà a questo in / etc / exports:

/ casa (ro)

Qui dobbiamo dire al sistema quali directory renderemo disponibili usando il demone di montaggio rpc.mountd:

# exportfs -r exportfs: nessun nome host specificato in / home (ro), digita * (ro) per evitare l'avviso #

Quando viene eseguito, il comando exportfs visualizza un avviso che / etc / exports non limita l'accesso a un particolare nodo e crea una voce corrispondente in / var / lib / nfs / etab da / etc / exports indicando quali risorse possono essere visualizzate con cat :

# cat / var / lib / nfs / etab / home (ro, async, wdelay, hide, secure, root_ squash, no_all_squash, subtree_check, secure_locks, mapping = identity, anonuid = -2, anongid = -2)

Altre opzioni, elencate in etab, includono le impostazioni predefinite utilizzate da NFS. I dettagli saranno descritti di seguito. Per concedere l'accesso alla directory /home, devono essere avviati i servizi NFS appropriati:

# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad

In qualsiasi momento dopo aver avviato il demone di montaggio (rpc.mountd), è possibile conoscere i singoli file disponibili per l'output guardando il contenuto del file /proc/fs/nfs/exports:

# cat / proc / fs / nfs / exports # Versione 1.0 # Path Client (Flags) # IP / home 192.168.1.252 (ro, root_squash, async, wdelay) # 192.168.1.252 #

Lo stesso può essere visualizzato utilizzando il comando showmount con il parametro -e:

# showmount -e Esporta elenco per mancini: / home (tutti) #

Eseguendo un po' prima di me, il comando showmount può essere utilizzato anche per identificare tutti i file system montati o, in altre parole, per scoprire quali nodi sono client NFS per il sistema che esegue il comando showmount. Il comando showmount -a elencherà tutti i punti di montaggio del client:

# showmount -a Tutti i punti di montaggio su lefty: 192.168.1.252:/home #

Come affermato in precedenza, la maggior parte delle implementazioni NFS supporta diverse versioni di questo protocollo. L'implementazione di Linux consente di limitare l'elenco delle versioni NFS da eseguire specificando l'opzione -N per il demone di montaggio. Ad esempio, per avviare la versione 3 di NFS e solo la versione 3, immettere il seguente comando:

# rpc.mountd -N 1 -N 2

Gli utenti più esigenti possono trovare scomodo che il demone NFS (rpc.nfsd) su Linux stia aspettando i pacchetti della versione 1 e della versione 2, sebbene ciò ottenga l'effetto desiderato di non supportare il protocollo corrispondente. Speriamo che gli sviluppatori delle prossime versioni apportino le dovute correzioni e riescano ad ottenere una maggiore consistenza dei componenti del pacchetto in relazione alle diverse versioni del protocollo.

"NUOTARE CON I PINGUINI"

L'accesso a Lefty configurato sopra, un file system esportato NFS basato su Linux, dipende dal sistema operativo client. Lo stile di installazione per la maggior parte dei sistemi operativi UNIX è quello dei sistemi operativi Sun e BSD originali o del più recente Solaris. Poiché questo articolo è incentrato su entrambi i sistemi Linux e Solaris, diamo un'occhiata alla configurazione del client Solaris 2.6 in termini di stabilire una connessione alla versione Linux di NFS descritta sopra.

Le funzionalità ereditate da Solaris 2.6 ne semplificano la configurazione per agire come client NFS. Ciò richiede un solo comando:

# mount -F nfs 192.168.1.254:/home / tmp / tmp2

Supponendo che il precedente comando di montaggio abbia avuto successo, il comando di montaggio senza parametri produrrà quanto segue:

# mount / on / dev / dsk / c0t0d0s0 read / write / setuid / largefiles on Mon Sep 3 10:17:56 2001 ... ... / tmp / tmp2 on 192.168.1.254:/home read / write / remote on Lun Set 3 23:19:25 2001

Analizziamo l'output di tcpdump dal nodo Lefty dopo che l'utente ha immesso il comando ls / tmp / tmp2 sul nodo Sunny:

# tcpdump host lefty e host sunny -s512 06: 07: 43.490583 sunny.2191983953> lefty.mcwrite.n.nfs: 128 getattr fh Unknown / 1 (DF) 06: 07: 43.490678 lefty.mcwrite.n.nfs> sunny. 2191983953: rispondi ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06: 07: 43.491397 sunny.2191983954> lefty.mcwrite.n.nfs: 132 access fh Unknown / 10001 (DF) 06: 07: 43.491463 lefty. mcwrite.n.nfs> sunny.2191983954: reply ok 120 access c0001 (DF) 06: 07: 43.492296 sunny.2191983955> lefty.mcwrite.n.nfs: 152 readdirplus fh 0,1 / 16777984 1048 byte @ 0x000000000 (DF) 06: 07: 43.492417 lefty.mcwrite.n.nfs> sunny.2191983955: rispondi ok 1000 readdirplus (DF)

Vediamo che Sunny chiede a ls un descrittore di file (fh), al quale Lefty risponde con OK e restituisce la struttura della directory. Sunny verifica quindi l'autorizzazione per il diritto al contenuto della directory (132 accessi fh) e riceve una risposta di autorizzazione da Lefty. Sunny legge quindi l'intero contenuto della directory utilizzando la routine readdirplus. Le chiamate di procedura remota sono descritte in RFC 1813 ea cui abbiamo fatto riferimento all'inizio di questo articolo.

Sebbene la sequenza di comandi per accedere ai file system remoti sia molto semplice, una serie di circostanze può portare a un montaggio errato del sistema. Il punto di montaggio deve già esistere prima che la directory possa essere montata, altrimenti deve essere creato utilizzando il comando mkdir. Di solito l'unica causa di errori lato client è la mancanza di una directory di montaggio locale. La maggior parte dei problemi con NFS è dovuta a una mancata corrispondenza tra il client e il server oa una configurazione errata del server.

Il modo più semplice per risolvere i problemi del server è dal sito in cui è in esecuzione il server. Tuttavia, quando qualcun altro sta amministrando il server al posto tuo, questo non è sempre possibile. Un modo rapido per assicurarsi che i servizi server appropriati siano configurati correttamente consiste nell'utilizzare il comando rpcinfo con il parametro -p. Dall'host Solaris Sunny, è possibile determinare quali processi RPC sono registrati sull'host Linux:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 100024 1 tcp 694 status 100005 3 udp 1024 mountd / 100005 3 tcp 1024 mountd 100003 2 100003 udp 2049 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #

Notare che qui vengono fornite anche le informazioni sulla versione, il che è molto utile quando il sistema richiede il supporto per vari protocolli NFS. Se un servizio non è in esecuzione sul server, questa situazione dovrebbe essere corretta. Se il montaggio fallisce, il seguente comando rpcinfo -p indicherà che il servizio mountd sul server è inattivo:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #

Il comando rpcinfo è molto utile per scoprire se un particolare processo remoto è attivo. L'opzione -p è la più importante delle opzioni. Per una panoramica completa delle funzionalità di rpcinfo, vedere la pagina man.

Un altro strumento utile è il comando nfsstat. Può essere utilizzato per scoprire se i client stanno effettivamente accedendo al file system esportato, nonché per visualizzare informazioni statistiche in base alla versione del protocollo.

Infine, tcpdump è un altro strumento utile per determinare la causa dei crash di sistema:

# tcpdump host lefty e host sunny -s512 tcpdump: ascolto su eth0 06: 29: 51.773646 sunny.2191984020> lefty.mcwrite.n.nfs: 140 lookup fh Unknown / 1 "test.c" (DF) 06: 29: 51.773819 lefty.mcwrite.n.nfs> sunny.2191984020: risposta ok 116 lookup ERRORE: nessun file o directory (DF) 06: 29: 51.774593 sunny.2191984021> lefty.mcwrite.n.nfs: 128 getattr fh Sconosciuto / 1 ( DF) 06: 29: 51.774670 lefty.mcwrite.n.nfs> sunny.2191984021: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06: 29: 51.775289 sunny.2191984022> lefty.mcwrite.n.nfs : 140 lookup fh Unknown / 1 "test.c" (DF) 06: 29: 51.775357 lefty.mcwrite.n.nfs> sunny.2191984022: risposta ok 116 lookup ERRORE: nessun file o directory (DF) 06:29: 51.776029 sunny.2191984023> lefty.mcwrite.n.nfs: 184 create fh Unknown / 1 "test.c" (DF) 06: 29: 51.776169 lefty.mcwrite.n.nfs> sunny.2191984023: reply ok 120 create ERROR: Permesso negato (DF)

L'elenco di cui sopra, ottenuto dopo aver eseguito l'istruzione touch test.c, riflette la seguente sequenza di azioni: prima, il comando touch tenta di accedere al file denominato test.c, quindi cerca una directory con lo stesso nome e, dopo aver fallito tentativi, tenta di creare il file test.c , che inoltre non porta a successo.

Quando il filesystem è montato, gli errori più comuni sono legati ai normali permessi UNIX. L'uso di uid o NIS+ da parte di Sun evita l'impostazione dei permessi a livello globale su tutti i filesystem. Alcuni amministratori praticano directory "aperte", in cui i permessi di lettura vengono dati a "tutto il mondo". Tuttavia, questo dovrebbe essere evitato per motivi di sicurezza. Problemi di sicurezza a parte, devi comunque ammettere che questa è una cattiva pratica perché gli utenti raramente creano dati con l'intenzione di renderli leggibili da chiunque.

L'accesso da parte del super utente (root) ai file system NFS montati viene trattato in modo diverso. Per evitare di concedere a un utente privilegiato l'accesso illimitato, le richieste dell'utente root vengono trattate come se provenissero dall'utente nessuno. Questo potente meccanismo limita l'accesso degli utenti privilegiati ai file leggibili e scrivibili a livello globale.

VERSIONE SOLARIS DEL SERVER NFS

Configurare Solaris per agire come server NFS è facile come Linux. Tuttavia, i comandi e le posizioni dei file sono leggermente diversi. All'avvio di Solaris, quando raggiunge il livello di esecuzione 3, i servizi NFS vengono avviati automaticamente e tutti i file system vengono esportati. Per avviare questi processi manualmente, inserisci il comando:

# / usr / lib / nfs / mountd

Per avviare il demone di montaggio e il server NFS, inserisci:

# / usr / lib / nfs / nfsd

A partire dalla versione 2.6, Solaris non utilizza più un file di esportazione per specificare i file system esportati. I file vengono ora esportati utilizzando il comando share. Supponiamo di voler consentire agli host remoti di montare / esportare / home. Inseriamo il seguente comando per questo:

Condividi -F nfs / export / home

Misure di sicurezza

SICUREZZA IN LINUX

Alcuni servizi di sistema NFS basati su Linux dispongono di un meccanismo aggiuntivo per limitare l'accesso tramite elenchi di controllo o tabelle. Internamente, questo meccanismo viene implementato utilizzando la libreria tcp_wrapper, che utilizza due file per generare liste di controllo degli accessi: /etc/hosts.allow e /etc/hosts/deny. Una panoramica completa delle regole per lavorare con tcp_wrapper va oltre lo scopo di questo articolo, ma il principio di base è il seguente: la mappatura viene eseguita prima con etc/hosts.allow, e poi con /etc/hosts. negare. Se la regola non viene trovata, il servizio di sistema richiesto non viene presentato. Per ignorare quest'ultimo requisito e fornire un livello di sicurezza molto elevato, è possibile aggiungere la seguente voce alla fine di /etc/hosts.deny:

Tutto tutto

Successivamente, puoi utilizzare / etc / hosts.allow per impostare questa o quella modalità di funzionamento. Ad esempio, il file /etc/hosts. Il permesso che ho usato durante la scrittura di questo articolo conteneva le seguenti righe:

Lockd: 192.168.1.0/255.255.255.0 mountd: 192.168.1.0/255.255.255.0 portmap: 192.168.1.0/255.255.255.0 rquotad: 192.168.1.0/255.255.255.0 statd: 192.168.1.0/255.255.255.0

Ciò consente un certo tipo di accesso ai nodi prima che venga concesso l'accesso a livello di applicazione. Su Linux, l'accesso a livello di applicazione è controllato dal file /etc/exports. Si compone di record nel seguente formato:

Directory esportata (spazio) nodo | rete (opzioni)

La "directory esportata" è la directory per la quale il demone nfsd può elaborare le richieste. "Host | network" è il nodo o la rete che ha accesso al file system esportato e le "opzioni" definiscono le restrizioni che il demone nfsd pone all'uso di questa risorsa condivisa - accesso in sola lettura o mappatura dell'ID utente ...

Nell'esempio seguente, all'intero dominio mcwrite.net viene concesso l'accesso in sola lettura a /home/mcwrite.net:

/home/mcwrite.net * .mcwrite.net (ro)

Altri esempi possono essere trovati nella pagina man delle esportazioni.

SICUREZZA NFS A SOLARIS

Su Solaris, la capacità di fornire l'accesso NFS è simile a quella di Linux, ma in questo caso le restrizioni vengono impostate utilizzando parametri specifici nel comando share con l'opzione -o. L'esempio seguente mostra come abilitare il montaggio di sola lettura /export/mcwrite.net su qualsiasi host nel dominio mcwrite.net:

#share -F nfs -o ro = .mcwrite.net / export / mcwrite.net

La pagina man di share_nfs descrive in dettaglio come concedere l'accesso utilizzando le liste di controllo su Solaris.

Risorse Internet

NFS e RPC non sono privi di buchi. In generale, NFS non dovrebbe essere utilizzato su Internet. I firewall non dovrebbero essere "buchi" fornendo alcun tipo di accesso NFS. Tieni d'occhio eventuali patch RPC e NFS che emergono e numerose fonti di informazioni sulla sicurezza possono aiutarti. Le due fonti più popolari sono Bugtraq e CERT:

Il primo può essere visionato regolarmente alla ricerca delle informazioni necessarie oppure avvalersi dell'abbonamento ad una newsletter periodica. Il secondo fornisce, forse, informazioni non così tempestive, rispetto ad altre, ma in un volume abbastanza completo e senza quel tocco di sensazionalismo insito in alcuni siti dedicati alla sicurezza informatica.

Ecco, cosa c'è dopo? Come posso guardare film e ascoltare file musicali scaricati? Hai davvero bisogno di masterizzarli su dischi e trasferirli in questo modo su un computer con una GUI? O devi copiarli su SFTP lento? Non! NFS viene in soccorso! No, questa non è una serie di giochi di corse, ma un Network File System.
Il Network File System (NFS) è un file system di rete che consente agli utenti di accedere a file e directory situati su computer remoti come se i file e le directory fossero locali. Il vantaggio principale di un tale sistema è che le singole workstation possono utilizzare meno spazio su disco, poiché i dati condivisi vengono archiviati su una macchina separata e sono disponibili per altre macchine sulla rete. NFS è un'applicazione client/server. Cioè, un client NFS deve essere installato sul sistema dell'utente e un server NFS sui computer che forniscono il loro spazio su disco.

Installazione e configurazione di un server NFS (192.168.1.2)

1. Installa. Dopo essersi connessi tramite SSH al computer tramite il server, o semplicemente nella sua console, inserire:

Sudo apt-get install nfs-kernel-server nfs-common portmap

Questo installerà il server NFS e il pacchetto portmap richiesto.

2. Configurazione. Per configurare l'elenco delle directory che vogliamo aprire e l'elenco a cui vogliamo aprirle, modifica il file / etc / esporta :

Sudo nano/etc/export/data 192.168.1.1/24(rw,no_root_squash,async)

Nell'esempio sopra, abbiamo aperto la directory sul server / dati e le sue sottodirectory per l'utilizzo condiviso da tutti i computer con IP: 192.168.1.1 - 192.168.1.255 con diritti di lettura e scrittura.

Un altro esempio:

/ home / serg / 192.168.1.34 (ro, asincrono)

Questo esempio rende disponibile la directory home dell'utente serg in modalità di sola lettura per il computer con IP 192.168.1.34. Tutti gli altri computer della rete non avranno accesso a questa directory.

Opzioni disponibili:

• ro - autorizzazione di sola lettura. Non è necessario specificarlo, poiché è installato di default;
• rw - fornisce ai client l'accesso in scrittura;
• no_root_squash - per impostazione predefinita, l'utente root sulla macchina client non avrà accesso alle directory aperte sul server. Con questa opzione, rimuoviamo questa limitazione. Per motivi di sicurezza, è meglio non farlo;
• noaccess - nega l'accesso alla directory specificata. Può essere utile se in precedenza è stato impostato l'accesso per tutti gli utenti della rete a una determinata directory e ora si desidera limitare l'accesso nella sottodirectory solo ad alcuni utenti.

Ora devi riavviare nfs-kernel-server:

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

Se dopo vuoi cambiare qualcosa nel file / etc / esporta , quindi affinché le modifiche abbiano effetto, esegui semplicemente il seguente comando:

Sudo exportfs -a

Qualunque cosa. Il server NFS è installato e configurato. Puoi andare al client NFS.

Installazione e configurazione del client NFS

1. Installazione. Eseguiamo quanto segue nel terminale del computer che si collegherà:

Sudo apt-get install portmap nfs-common

2. Impostazione. Innanzitutto, creiamo una directory in cui verrà montata la cartella remota:

Cd ~ dati mkdir

Puoi montare in due modi: ogni volta manualmente o scrivendo le opzioni di montaggio su un file / etc / fstab.

Metodo 1. Montaggio manuale
Crea un file di testo sul desktop o in un'altra cartella:

Nano ~ / desktop \ desktop / nfs-server-connect

Gli scriviamo:

#! /bin/bash sudo mount -t nfs -o ro, soft, intr 192.168.1.2:/data ~ / data

Lo rendiamo eseguibile:

Chmod + x ~ / desktop \ desktop / nfs-server-connect

Ora, quando ho bisogno di connettermi al server, eseguo questo script nel terminale in modo da poter inserire la password per sudo.

Metodo 2. Aggiunta a / etc / fstab
Apri / etc / fstab:

Sudo nano / etc / fstab

E aggiungi una riga alla fine del file:

192.168.1.2:/data ~ / data nfs rw, hard, intr 0 0

Attenzione! Sostituire 192.168.1.2:/data con l'IP o il nome del server e il percorso della directory condivisa. Le opzioni di montaggio possono essere modificate.

Opzione duro lega rigidamente la directory sul client al server e, se il server cade, anche il computer potrebbe bloccarsi. Opzione morbido, come suggerisce il nome, non è così categorico.

Dopo aver salvato il file, puoi montare la cartella remota.

NFS ( File system di rete) è principalmente progettato per essere condiviso File e cartelle tra / Unix sistemi da di Sun Microsystems v 1980 anno... Consente di montare file system locali sulla rete e host remoti per interagire con essi come se fossero installati localmente sullo stesso sistema. attraverso NFS, possiamo impostare la condivisione di file tra Unix v Linux sistema e Linux per il sistema Unix.

Vantaggi di NFS

1. NFS crea l'accesso locale ai file remoti.
2. Utilizza un'architettura standard cliente/server per scambiare file tra tutte le macchine in base a * NIX.
3. attraverso NFS non è necessario che entrambe le macchine funzionino allo stesso modo OS.
4. attraverso NFS possiamo personalizzare la soluzione archiviazione centralizzata.
5. Gli utenti ottengono il loro dati indipendentemente dalla loro posizione fisica.
6. Automatico aggiornare per nuovi file.
7. Versione più nuova NFS supporti di montaggio acl, pseudo- come radice.
8. Può essere protetto firewall e Kerberos.

Servizi NFS

Servizio Sistema V-lanciato... Pacchetto server NFS include tre strumenti inclusi nei pacchetti portmap e nfs-utils.

1. portmap: visualizza le chiamate effettuate da altre macchine al servizio corretto RPC(non richiesto con NFSv4).
2. nfs: converte le richieste remote condivisione di file in query sul filesystem locale.
3. rpc.mountd: questo servizio è responsabile di montaggio e smontare file system.

File di configurazione essenziali per NFS

1. / etc / esporta: il suo file di configurazione principale NFS, tutto esportato File e cataloghi che sono definiti in questo file e su server NFS di destinazione.
2. / etc / fstab: Per montare directory NFS sul tuo sistema senza si riavvia, dobbiamo registrare in / etc / fstab.
3. /etc/sysconfig/nfs: File di configurazione NFS per controllare quale porta RPC e altri servizi ascoltando.

Configurazione e montaggio di NFS su un server Linux

Per personalizzare la montatura NFS avremo bisogno di almeno due auto Linux/Unix... In questo tutorial utilizzeremo due server.

1. Server NFS: nfsserver.example.ru con IP - 192.168.0.55
2. client NFS: nfsclient.example.ru con IP - 192.168.0.60

Installazione del server NFS e del client NFS

Dobbiamo installare i pacchetti NFS sulla nostra Server NFS così come in auto client NFS... Possiamo installarlo con "" ( cappello rosso Linux) e pacchetto di installazione “ apt-get” (Debian e Ubuntu).

# yum install nfs-utils nfs-utils-lib # yum install portmap (non richiesto con NFSv4) # apt-get install nfs-utils nfs-utils-lib

Ora corri servizio su entrambe le macchine.

# /etc/init.d/portmap start # /etc/init.d/nfs start # chkconfig --level 35 portmap on # chkconfig --level 35 nfs on

Dopo aver installato i pacchetti ed eseguito i servizi su entrambe le macchine, è necessario configurare entrambe le macchine per condividere i file.

Configurazione di un server NFS

Per prima cosa, impostiamo il server NFS.

Configurazione della directory di esportazione

# mkdir / nfsshare

Ora dobbiamo scrivere su " / etc / esporta" e ricomincia servizi per rendere la nostra directory condivisibile sul web.

# vi / etc / exports / nfsshare 192.168.0.60 (rw, sync, no_root_squash)

Nell'esempio sopra, c'è una directory sotto / intitolato " nfsshare", Attualmente condiviso con un client IP" 192.168.0.60 ”Con privilegi lettura e record (RW), puoi anche usare Nome host cliente invece di IP nell'esempio sopra.

Opzioni NFS

Possiamo usare alcune altre opzioni nei file " / etc / esporta”Per la condivisione di file è simile a questo.

1. ro: Con questa opzione possiamo fornire accesso in sola lettura a file condivisi, ad es. cliente potrà solo leggere.
2. rw: Questa opzione consente da client a server accesso per entrambi per lettura e record all'interno della directory condivisa.
3. sincronizzare: la sincronizzazione conferma le richieste di directory condivise solo dopo i cambiamenti sono stati commessi.
4. no_subtree_check: Questa opzione impedisce il controllo sottoalbero... Quando una directory condivisa è una sottodirectory di un filesystem più grande, NFS scansiona ogni directory sopra di essa per verificarne i permessi e i dettagli. Disattiva controllo sottoalbero può migliorare l'affidabilità NFS ma ridurre sicurezza.
5. no_root_squash: Questa frase permette radice, Collegare in una cartella specifica.

Per ulteriori opzioni con " / etc / esporta“, Si consiglia di leggere pagine linee guida per esportare.

Configurazione di un client NFS

Dopo aver impostato NFS-server, abbiamo bisogno montare questa directory condivisa o partizione attiva cliente server.

Montare directory condivise su un client NFS

Ora su client NFS, abbiamo bisogno montare questa directory per accedere localmente. Per fare ciò, dobbiamo prima scoprire quali risorse sono disponibili sul server remoto o NFS.

# showmount -e 192.168.0.55 Esporta elenco per 192.168.0.55: / nfsshare 192.168.0.60

Montare una directory accessibile in NFS

In modo da montare generale NFS directory, possiamo usare il seguente comando mount.

# mount -t nfs 192.168.0.55:/nfsshare / mnt / nfsshare

Il comando precedente imposterà la directory condivisa su " / mnt / nfsshare”Sul server del cliente. Puoi verificarlo con il seguente comando.

# monta | grep nfs sunrpc on / var / lib / nfs / rpc_pipefs tipo rpc_pipefs (rw) nfsd on / proc / fs / nfsd tipo nfsd (rw) 192.168.0.55:/nfsshare on / mnt tipo nfs (rw, addr = 192.05)

Sopra il comando mount si monta su Directory condivisa NFS sul client NFS per montare temporaneamente la directory NFS costantemente sul tuo sistema indipendentemente dai riavvii, dobbiamo inserire una voce in " / etc / fstab“.

# vi / etc / fstab

Aggiungi la seguente nuova riga come mostrato di seguito.

192.168.0.55:/nfsshare / mnt nfs di default 0 0

Verifica del comportamento di installazione di NFS

Possiamo testare il nostro installazione di un server NFS creando file di prova lato server e verificarne la presenza su client NFS lato o viceversa.

Lato server nfsserver

Abbiamo creato un nuovo file di testo chiamato " nfstest.txt«In questo elenco generale.

# cat> /nfsshare/nfstest.txt Questo è un file di prova per testare il funzionamento della configurazione del server NFS.

Lato client nfsclient

Passa alla directory condivisa su server client e troverai il file condiviso senza alcun aggiornamento manuale o servizio di riavvio.

# ll / mnt / nfsshare total 4 -rw-r - r-- 1 root root 61 Sep 21 21:44 nfstest.txt [e-mail protetta]~] # cat /mnt/nfsshare/nfstest.txt Questo è un file di prova per testare il funzionamento della configurazione del server NFS.

Rimozione di un montaggio NFS

Se lo desidera smontare questa directory condivisa dal server dopo aver finito con la condivisione di file puoi semplicemente smontare questa particolare directory usando il comando " smontare“. Vedi questo esempio di seguito.

[e-mail protetta]~] # umount / mnt / nfsshare

Puoi vedere che il supporto è stato rimosso dal filesystem.

# df -h -F nfs

Vedrai che queste directory condivise non sono più disponibili.

Comandi importanti per NFS

Alcuni dei comandi più importanti per NFS .

1. showmount -e: Spettacoli disponibili oggetti condivisi sul computer locale
2. showmount -e : Elenco dei disponibili oggetti condivisi sul a distanza server
3. showmount -d: Elenco di tutti sottodirectory
4. exportfs -v: Visualizza un elenco di condivisi File e opzioni sul server
5. exportfs -a: Esporta tutti gli oggetti disponibili elencati in / etc / esporta, o nome
6. exportfs -u: Riesportazione di tutti gli oggetti disponibili elencati in / etc / esporta, o nome
7. exportfs -r: Aggiorna l'elenco dei server dopo la modifica / etc / esporta

È tutta una questione di montare nfs al momento, se interessati, potete leggere la guida a riguardo. lascia il tuo

L'essenza del problema: un tempo Samsung ha iniziato a produrre televisori che supportano la tecnologia DLNA sviluppata dai principali produttori di elettrodomestici, basata sul principio della "casa digitale". Questa tecnologia ha permesso di integrare i televisori in una rete domestica locale, che ha permesso di scambiare contenuti multimediali tra un televisore e un computer e, in particolare, guardare i film in TV memorizzati su un computer tramite una rete locale o tramite WiFi. Tuttavia, la soluzione multimediale proposta da Samsung per implementare questa tecnologia lascia molto a desiderare, per usare un eufemismo. Pertanto, i film guardati in rete nel lettore multimediale TV integrato, nella maggior parte dei casi, non vengono riavvolti. Inoltre, durante la visione di film in rete, a differenza della visione di film da un'unità flash USB o da un disco rigido portatile collegato a un televisore tramite una porta USB, la funzione di riproduzione continua (tasto blu sul telecomando) non è supportata. Infine, la stessa necessità di eseguire ogni volta Samsung PC Share Manger sul computer e di apportare correzioni dopo ogni cancellazione o aggiunta di file video sul disco è un po' fastidiosa.

L'abilitazione del protocollo di rete NFS (Network File System) ci aiuterà non solo ad eliminare i problemi esistenti con la visione di film in TV su una rete locale, ma anche ad aumentare la velocità di trasferimento dei dati (che può essere un fattore importante quando si guardano film HD di grandi dimensioni ). Dopo aver effettuato la necessaria installazione e configurazione del server NFS, il nostro computer verrà percepito dal televisore come se avessimo collegato un hard disk portatile al televisore tramite una porta USB (l'unica differenza sarà solo nel tasso di scambio dati, che è determinato dalla larghezza di banda massima della rete locale o dalla connessione WiFi).

NFS è un protocollo di rete client-server. Avremo un computer come server, un televisore come client. Abbiamo già discusso dell'inclusione del supporto NFS sulla TV nella sezione precedente durante la configurazione e l'installazione dell'applicazione SamyGO Auto sulla TV. Se ricordi, nelle impostazioni del configuratore di SamyGO Auto, abbiamo spuntato la casella di fronte alla sezione NFS e registrato anche l'indirizzo IP del server NFS (192.168.xxx.xxx), ovvero l'indirizzo del nostro computer:
In questa sezione, esamineremo l'installazione e la configurazione di un server NFS sul nostro computer. Esistono molti programmi diversi su Internet per l'installazione e la configurazione di un server NFS. Useremo l'applicazione haneWIN NFS Server(è shareware e dopo un certo periodo di tempo richiede la registrazione di un numero di serie, ma, come capisci, ci sono sempre artigiani su Internet che possono risolvere questo problema). Quindi iniziamo:

Nota: a volte il firewall di Windows o il firewall integrato dell'antivirus possono bloccare il funzionamento del server NFS. Qualunque cosa accada, nel firewall di Windows (o se hai un altro firewall, quindi in esso) devi consentire l'accesso alla rete per due applicazioni: nfsd.exe e pmapd.exe (si trovano nella cartella di installazione del server C: \ Programmi \ nfsd).

Infine, accendi la TV e assicurati che il nostro server NFS sia attivo e funzionante. Nella sezione precedente, quando abbiamo installato il programma SamyGO Auto sulla TV, abbiamo indicato il parametro per l'esecuzione automatica al suo interno. Pertanto, quando accendi la TV, dovrebbe rilevare automaticamente il nostro NFS (questo non avviene immediatamente, ma circa 20 secondi dopo aver acceso la TV). Quindi, accendi la TV, quindi vai al lettore multimediale e vedi un nuovo dispositivo lì: Server NFS.

Se noti, c'è un'icona di connessione USB accanto a NFS. Questo è ciò di cui abbiamo parlato prima, ora la tua TV percepirà il computer come un disco rigido o un'unità flash USB. Puoi andare alla sezione Film e divertirti a guardare film in rete. Non è più necessario eseguire Samsung PC Share Manager sul computer. Basta aggiungere un film alla cartella dei film del tuo computer e verrà automaticamente "caricato" nel lettore multimediale della tua TV.

Nella prossima sezione parleremo di come registrare i programmi dalla TV su un'unità flash USB o, poiché ora abbiamo NFS, su una cartella con i film su un computer.

File system di rete (NFS)- protocollo di accesso di rete ai file system, consente di connettere file system remoti.
Sviluppato originariamente da Sun Microsystems nel 1984, è basato su Sun RPC: Remote Procedure Call. NFS è indipendente dai tipi di file system server e client. Esistono molte implementazioni di server e client NFS per diversi sistemi operativi. Attualmente viene utilizzato NFS v.4, che supporta vari mezzi di autenticazione (in particolare, Kerberos e LIPKEY utilizzando il protocollo RPCSEC GSS) e liste di controllo degli accessi (sia POSIX che Windows).
NFS fornisce ai client un accesso trasparente ai file e al file system del server. A differenza di FTP, NFS accede solo alle parti del file a cui ha avuto accesso il processo e il suo vantaggio principale è che rende questo accesso trasparente. Grazie a ciò, qualsiasi applicazione client in grado di funzionare con un file locale può funzionare anche con un file NFS, senza modificare il programma stesso.
I client NFS accedono ai file sul server NFS inviando richieste RPC al server. Ciò può essere implementato utilizzando i normali processi utente, ovvero il client NFS può essere un processo utente che effettua chiamate RPC specifiche al server, che può anche essere un processo utente.

versioni
NFSv1 era per uso interno solo a scopo sperimentale. I dettagli di implementazione sono definiti nella RFC 1094.
NFSv2 (RFC 1094, marzo 1989) originariamente funzionava interamente su UDP.
NFSv3 (RFC 1813, giugno 1995). I descrittori di file nella versione 2 sono un array a dimensione fissa di 32 byte. Nella versione 3, è un array di dimensioni variabili fino a 64 byte. Un array a lunghezza variabile in XDR è definito da un contatore a 4 byte seguito da byte reali. Ciò riduce la dimensione del descrittore di file su implementazioni come UNIX, che richiedono solo circa 12 byte, ma consente alle implementazioni non Unix di scambiare informazioni aggiuntive.
La versione 2 limita il numero di byte per READ o WRITE RPC a 8192 byte. Questa limitazione non si applica nella versione 3, che, a sua volta, significa che utilizzando UDP, la limitazione sarà solo nella dimensione del datagramma IP (65535 byte). Ciò consente di utilizzare pacchetti di grandi dimensioni durante la lettura e la scrittura su reti veloci.
Le dimensioni dei file e l'offset di byte iniziale per le procedure READ e WRITE hanno iniziato a utilizzare l'indirizzamento a 64 bit anziché a 32 bit, il che consente di lavorare con file di dimensioni maggiori.
Gli attributi del file vengono restituiti in ogni chiamata che potrebbe influire sugli attributi.
Le scritture (WRITE) possono essere asincrone mentre nella versione 2 avrebbero dovuto essere sincrone.
È stata rimossa una procedura (STATFS) e ne sono state aggiunte sette: ACCESS (verifica dei permessi dei file), MKNOD (creazione di un file Unix speciale), READDIRPLUS (restituisce i nomi dei file in una directory insieme ai loro attributi), FSINFO (restituisce informazioni statistiche su il file system ), FSSTAT (restituisce le informazioni sul file system dinamico), PATHCONF (restituisce le informazioni sul file POSIX.1) e COMMIT (trasferisce le scritture asincrone precedentemente effettuate alla memoria permanente).
Al momento dell'introduzione della versione 3, gli sviluppatori hanno iniziato a utilizzare maggiormente TCP come protocollo di trasporto. Sebbene alcuni sviluppatori abbiano già utilizzato TCP per NFSv2, Sun Microsystems ha aggiunto il supporto TCP a NFS versione 3. Ciò ha reso più fattibile l'utilizzo di NFS su Internet.
NFSv4 (RFC 3010, dicembre 2000, RFC 3530, rivisto nell'aprile 2003), influenzato da AFS e CIFS, incorpora miglioramenti delle prestazioni, alta sicurezza ed è emerso come un protocollo completo. La versione 4 è stata la prima versione sviluppata in collaborazione con l'Internet Engineering Task Force (IETF) dopo che Sun Microsystems ha approvato lo sviluppo dei protocolli NFS. NFS v4.1 è stato approvato da IESG nel gennaio 2010 e ha ricevuto RFC 5661. Un'importante innovazione nella versione 4.1 è la specifica pNFS - Parallel NFS, un meccanismo per l'accesso client NFS parallelo ai dati da più server NFS distribuiti. La presenza di un tale meccanismo nello standard del file system di rete aiuterà a costruire archivi e sistemi informativi "cloud" distribuiti.

Struttura NFS
La struttura NFS ha tre componenti a diversi livelli:
Il livello dell'applicazione (NFS stesso) è costituito dalle chiamate di procedura remota (rpc) che eseguono le operazioni necessarie su file e directory sul lato server.
Le funzioni del livello di presentazione sono eseguite dal protocollo XDR (eXternal Data Representation), che è uno standard di astrazione dei dati multipiattaforma. Il protocollo XDR descrive una forma unificata, canonica, di rappresentazione dei dati che non dipende dall'architettura del sistema informatico. Durante la trasmissione dei pacchetti, il client RPC converte i dati locali in forma canonica e il server fa il contrario.
Il servizio Remote Procedure Call (RPC), che consente a un client di richiedere procedure remote ed eseguirle sul server, è una funzione a livello di sessione. Collegamento delle risorse di rete
La procedura per connettere una risorsa di rete tramite NFS è denominata "esportazione". Il client può chiedere al server un elenco delle risorse esportate che rappresenta. Il server NFS stesso non trasmette un elenco delle sue risorse esportate.
A seconda delle opzioni specificate, la risorsa esportata può essere montata (allegata) in "sola lettura", è possibile definire un elenco di host che possono essere montati, specificare l'uso di RPC sicuro (secureRPC), ecc. Una delle opzioni determina il metodo di montaggio: "hard" (hard) o "soft" (soft).
Con un montaggio "difficile", il client proverà a montare il filesystem a tutti i costi. Se il server è inattivo, ciò porterà al fatto che l'intero servizio NFS sembra bloccarsi: i processi che accedono al file system andranno in uno stato di attesa del completamento delle richieste RPC. Dal punto di vista dei processi utente, il file system apparirà come un disco locale molto lento. Quando il server viene riportato in linea, il servizio NFS continuerà a funzionare.
In un soft mount, il client NFS effettuerà diversi tentativi di connessione al server. Se il server non risponde, il sistema emette un messaggio di errore e smette di provare a montare. Dal punto di vista della logica delle operazioni sui file, quando un server si guasta, un soft mount emula un errore di un disco locale.
La scelta della modalità dipende dalla situazione. Se i dati sul client e sul server devono essere sincronizzati in caso di interruzione temporanea del servizio, è preferibile un montaggio "hard". Questa modalità è insostituibile anche nei casi in cui i file system montati contengano programmi e file vitali per il funzionamento del client, in particolare per le macchine diskless. In altri casi, specialmente quando si tratta di sistemi di sola lettura, la modalità di montaggio morbido è più conveniente.

Condivisione di rete mista
NFS è l'ideale per le reti basate su UNIX poiché viene fornito con la maggior parte delle versioni del sistema operativo. Inoltre, il supporto NFS è implementato a livello del kernel UNIX. L'utilizzo di NFS su computer client Windows crea alcuni problemi associati alla necessità di installare software client specializzato e piuttosto costoso. In tali reti, sembra preferibile l'uso di strumenti di condivisione basati su SMB/CIFS, in particolare il software Samba.

Standard
RFC 1094 NFS: specifica del protocollo del file system di rete] (marzo 1989)
Specifica del protocollo RFC 1813 NFS versione 3] (giugno 1995)
Schema URL NFS RFC 2224
RFC 2339 Un accordo tra Internet Society, IETF e Sun Microsystems, Inc. in materia di Protocolli NFS V.4
RFC 2623 Problemi di sicurezza di NFS versione 2 e versione 3 e utilizzo di RPCSEC_GSS e Kerberos V5 da parte del protocollo NFS
RFC 2624 NFS versione 4 Considerazioni sulla progettazione
Protocollo RFC 3010 NFS versione 4
Protocollo RFC 3530 Network File System (NFS) versione 4
RFC 5661 Network File System (NFS) Versione 4 Minor Versione 1 Protocollo

Fonti utilizzate
1.ru.wikipedia.org
2.ru.science.wikia.com
3. phone16.ru
4.4stud.info
5.yandex.ru
6.gogle.com