Zum Inhalt springen

Network File System: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
 
(29 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
{| class="float-right" style="margin-top:0; text-align:center;" cellspacing="3"
'''Network File System''' - [[Netzwerkprotokoll|Protokoll]], das den Zugriff auf [[Datei]]en über ein [[Rechnernetz|Netzwerk]] ermöglicht
|+ '''NFS im [[OSI-Schichtenmodell]]'''
 
|-
== Beschreibung ==
|style="background:#FFCC99"| '''Anwendung'''
{{:Network_File_System/OSI}}
|colspan="4" style="background:#9999FF"| '''NFS'''
|-
|style="background:#FFCC99"| ''Darstellung''
|colspan="4" style="background:#EEEEFF"| '''[[External Data Representation|XDR]]'''
|-
|style="background:#FFCC99"| ''Sitzung''
|colspan="4" style="background:#EEEEFF"| ''(Sun-)'' '''[[Remote Procedure Call|RPC]]'''
|-
|style="background:#FFCC99"| ''Transport''
|colspan="2" style="background:#EEEEFF"| '''([[User Datagram Protocol|UDP]])'''
|colspan="2" style="background:#EEEEFF"| '''[[Transmission Control Protocol|TCP]]'''
|-
|style="background:#FFCC99"| ''Netzwerk''
|colspan="4" style="background:#EEEEFF"| '''[[Internet Protocol|IP]] ([[IPv4]], [[IPv6]])'''
|-
|style="background:#FFEEBB"| ''Netzzugang''
|style="background:#EEEEEE"| [[Ethernet]]
|style="background:#EEEEEE"| [[Token Ring|Token<br />Ring]]
|style="background:#EEEEEE"| [[Fiber Distributed Data Interface|FDDI]]
|style="background:#EEEEEE"| …
|}


Das '''Network File System''' ('''NFS''', auch ''Network File Service'') ist ein von [[Sun Microsystems]] entwickeltes [[Netzwerkprotokoll|Protokoll]], das den Zugriff auf [[Datei]]en über ein [[Rechnernetz|Netzwerk]] ermöglicht. Dabei werden die Dateien nicht wie z.&nbsp;B. bei [[File Transfer Protocol|FTP]] übertragen, sondern die Benutzer können auf Dateien, die sich auf einem entfernten Rechner befinden, so zugreifen, als ob sie auf ihrer lokalen [[Laufwerk (Computer)|Festplatte]] abgespeichert wären.
Das '''Network File System''' ('''NFS''', auch ''Network File Service'') ist ein von [[Sun Microsystems]] entwickeltes [[Netzwerkprotokoll|Protokoll]], das den Zugriff auf [[Datei]]en über ein [[Rechnernetz|Netzwerk]] ermöglicht
* Dabei werden die Dateien nicht wie z.&nbsp;B.&nbsp;bei [[File Transfer Protocol|FTP]] übertragen, sondern die Benutzer können auf Dateien, die sich auf einem entfernten Rechner befinden, so zugreifen, als ob sie auf ihrer lokalen [[Laufwerk (Computer)|Festplatte]] abgespeichert wären


Bei diesem [[Unix]]-Netzwerkprotokoll handelt es sich um einen [[Internet]]-[[Standard]] (<nowiki>RFC&nbsp;1094</nowiki>,<ref>{{RFC-Internet |RFC=1094 |Titel=NFS Version 2 Protocol Specification |Datum=1989 |Updated=3010}}</ref> <nowiki>RFC&nbsp;1813</nowiki>,<ref>{{RFC-Internet |RFC=1813 |Titel=NFS Version 3 Protocol Specification |Datum=1995 |Updated=3010}}</ref> <nowiki>RFC&nbsp;3530</nowiki>,<ref>{{RFC-Internet |RFC=3530 |Titel=Network File System (NFS) version 4 Protocol |Datum=2003 |Updated=7530}}</ref> <nowiki>RFC&nbsp;7530</nowiki><ref name="RFC7530" />), der auch als verteiltes [[Dateisystem]] ({{enS|distributed file system}}) bezeichnet wird.
Bei diesem [[Unix]]-Netzwerkprotokoll handelt es sich um einen [[Internet]]-[[Standard]] (<nowiki>RFC&nbsp;1094</nowiki>, <nowiki>RFC&nbsp;7530</nowiki>), der auch als verteiltes [[Dateisystem]] ({{enS|distributed file system}}) bezeichnet wird


Die Entsprechung zu NFS heißt unter Windows- und [[OS/2]]-Umgebungen [[Server Message Block]] (SMB).
Die Entsprechung zu NFS heißt unter Windows- und [[OS/2]]-Umgebungen [[Server Message Block]] (SMB)
Während sich bei SMB der Benutzer authentifiziert, authentisiert NFSv3 den Client-Rechner, erst NFSv4 ermöglicht Benutzerauthentifikation. NFS-Dienste sind auch auf [[Microsoft Windows|Microsoft-Windows]]-[[Server]]n verfügbar, wodurch UNIX-[[Workstation]]s Zugang zu deren Dateien erhalten können, allerdings wird in gemischten Umgebungen meist SMB mit [[Samba (Software)|Samba]] auf Unixseite verwendet.
Während sich bei SMB der Benutzer authentifiziert, authentisiert NFSv3 den Client-Rechner, erst NFSv4 ermöglicht Benutzerauthentifikation
* NFS-Dienste sind auch auf [[Microsoft Windows|Microsoft-Windows]]-[[Server]]n verfügbar, wodurch UNIX-[[Workstation]]s Zugang zu deren Dateien erhalten können, allerdings wird in gemischten Umgebungen meist SMB mit [[Samba (Software)|Samba]] auf Unixseite verwendet


NFS arbeitet auf dem [[Netzwerkprotokoll]] [[Internet Protocol|IP]] ursprünglich zusammen mit dem [[Zustandslosigkeit|zustandslosen]] [[User Datagram Protocol|UDP]]. Mittlerweile gibt es aber auch NFS über [[Transmission Control Protocol|TCP]]. NFSv4 arbeitet nur mit TCP und benötigt nur noch einen Port (2049), was den Betrieb durch [[Firewall]]s erleichtert. NFSv4 wurde maßgeblich durch die [[Internet Engineering Task Force|IETF]] entwickelt, nachdem Sun die Entwicklung abgegeben hatte.<ref>{{Internetquelle |url=https://datatracker.ietf.org/wg/nfsv4/charter/ |titel=Network File System Version 4 (nfsv4) |hrsg=[[Internet Engineering Task Force|IETF]] |sprache=en |abruf=2021-03-04}}</ref>
NFS arbeitet auf dem [[Netzwerkprotokoll]] [[Internet Protocol|IP]] ursprünglich zusammen mit dem [[Zustandslosigkeit|zustandslosen]] [[User Datagram Protocol|UDP]]
* Mittlerweile gibt es aber auch NFS über [[Transmission Control Protocol|TCP]]
* NFSv4 arbeitet nur mit TCP und benötigt nur noch einen Port (2049), was den Betrieb durch [[Firewall]]s erleichtert
* NFSv4 wurde maßgeblich durch die [[Internet Engineering Task Force|IETF]] entwickelt, nachdem Sun die Entwicklung abgegeben hatte


== Schematischer Ablauf der Datenübertragung ==
== Datenübertragung ==
Im Folgenden ist der prinzipielle Ablauf einer NFS-Kommunikation des alten zustandslosen NFS bis einschließlich Version&nbsp;3 beschrieben. Szenario: Ein Nutzer des Client-Rechners möchte ein entferntes Verzeichnis ''(/directory)'' öffnen und eine darin befindliche Datei ''(test)'' anzeigen lassen.
; Schematischer Ablauf der Datenübertragung
Im Folgenden ist der prinzipielle Ablauf einer NFS-Kommunikation des alten zustandslosen NFS bis einschließlich Version&nbsp;3 beschrieben
* Szenario: Ein Nutzer des Client-Rechners möchte ein entferntes Verzeichnis ''(/directory)'' öffnen und eine darin befindliche Datei ''(test)'' anzeigen lassen


Damit ein Datenaustausch zwischen NFS-Server und -Client stattfinden kann, muss der NFS-Server gestartet und beim [[Portmapper]] registriert sein.
Damit ein Datenaustausch zwischen NFS-Server und -Client stattfinden kann, muss der NFS-Server gestartet und beim [[Portmapper]] registriert sein


# [[Client]] kontaktiert Portmapper auf Port 111 und fragt nach dem [[Port (Netzwerkadresse)|Port]] des [[Mounten|Mount]]-[[Daemon]]s (mountd)
# [[Client]] kontaktiert Portmapper auf Port 111 und fragt nach dem [[Port (Netzwerkadresse)|Port]] des [[Mounten|Mount]]-[[Daemon]]s (mountd)
# Portmapper gibt Portnummer für mountd heraus. Typischerweise ist das 694.
# Portmapper gibt Portnummer für mountd heraus
# Client kontaktiert mountd und fragt nach einem [[Filehandle]] für ''/directory'', des vom Clienten zu mountenden Verzeichnisses des Servers.
* Typischerweise ist das 694
# Client kontaktiert mountd und fragt nach einem [[Filehandle]] für ''/directory'', des vom Clienten zu mountenden Verzeichnisses des Servers
# mountd gibt ein ''Filehandle 0'' als ''root''-Filehandle für das zu mountende Verzeichnis des Servers zurück
# mountd gibt ein ''Filehandle 0'' als ''root''-Filehandle für das zu mountende Verzeichnis des Servers zurück
# Client kontaktiert Portmapper und fragt nach dem Port für NFS (nfsd). Typischerweise ist das 2049.
# Client kontaktiert Portmapper und fragt nach dem Port für NFS (nfsd)
* Typischerweise ist das 2049
# Portmapper gibt Portnummer für nfsd heraus
# Portmapper gibt Portnummer für nfsd heraus
# Client führt ''LOOKUP''-[[Prozedur (Programmierung)|Prozedur]] aus mit den Parametern ''Filehandle&nbsp;0'' und dem Dateinamen ''(test)''
# Client führt ''LOOKUP''-[[Prozedur (Programmierung)|Prozedur]] aus mit den Parametern ''Filehandle&nbsp;0'' und dem Dateinamen ''(test)''
Zeile 50: Zeile 38:
# nfsd gibt Inhalt der Datei ''(test)'' zurück (Daten)
# nfsd gibt Inhalt der Datei ''(test)'' zurück (Daten)


== Design der frühen Versionen des Systems ==
== Design ==
Ein Programm greift auf das Dateisystem über [[Systemaufruf]]e zu. Unter [[Unix]] sind die wichtigsten Systemaufrufe:
; Design der frühen Versionen des Systems
Ein Programm greift auf das Dateisystem über [[Systemaufruf]]e zu
* Unter [[Unix]] sind die wichtigsten Systemaufrufe
* ''open'', ''close'' – Öffnen und Schließen einer Datei
* ''open'', ''close'' – Öffnen und Schließen einer Datei
* ''read'', ''write'' – Lesen und Schreiben
* ''read'', ''write'' – Lesen und Schreiben
Zeile 58: Zeile 48:
* ''readdir'' – Lesen von Verzeichniseinträgen
* ''readdir'' – Lesen von Verzeichniseinträgen


Ein Netzwerkdateisystem muss diese Aufrufe in Netzwerkpakete verpacken und an einen [[Server]] senden. Dieser antwortet dann mit der entsprechenden Information oder einem Fehler.
Ein Netzwerkdateisystem muss diese Aufrufe in Netzwerkpakete verpacken und an einen [[Server]] senden
* Dieser antwortet dann mit der entsprechenden Information oder einem Fehler


Die Entwickler von Sun Microsystems entschieden sich zunächst für ein [[Remote Procedure Call|Remote-Procedure-Call]]-Modell. [[External Data Representation|XDR]] setzt die Parameter des ''RPCs'' in ein maschinenunabhängiges Format um, die Zugriffe werden dann über den RPC Mechanismus wie ein normaler Unterprogrammaufruf behandelt.
Die Entwickler von Sun Microsystems entschieden sich zunächst für ein [[Remote Procedure Call|Remote-Procedure-Call]]-Modell. [[External Data Representation|XDR]] setzt die Parameter des ''RPCs'' in ein maschinenunabhängiges Format um, die Zugriffe werden dann über den RPC Mechanismus wie ein normaler Unterprogrammaufruf behandelt


Die Systemaufrufe werden aber nicht direkt in RPC-Aufrufe umgesetzt, da dann eine über ''open'' geöffnete Datei auch auf dem Server geöffnet werden müsste. Bei vielen Clients wären die Server dann schnell überlastet, da die Maschinen Mitte der 1980er-Jahre noch relativ wenig Speicher hatten. Die Aufgaben des Servers wurden daher so einfach wie möglich gehalten, der Server merkt sich keine Dateiinformationen zwischen zwei RPC-Aufrufen. Er ist also zustandslos.
Die Systemaufrufe werden aber nicht direkt in RPC-Aufrufe umgesetzt, da dann eine über ''open'' geöffnete Datei auch auf dem Server geöffnet werden müsste
* Bei vielen Clients wären die Server dann schnell überlastet, da die Maschinen Mitte der 1980er-Jahre noch relativ wenig Speicher hatten
* Die Aufgaben des Servers wurden daher so einfach wie möglich gehalten, der Server merkt sich keine Dateiinformationen zwischen zwei RPC-Aufrufen
* Er ist also zustandslos


Statt ''open'' wird ein ''lookup''-Aufruf implementiert. Dieser liefert ein Datei-„Handle“, das die [[Inode]]nummer und die Gerätenummer des Massenspeichers auf dem Server enthält. Über dieses Handle kann eine Datei auf dem Server eindeutig identifiziert werden. Unter Unix steht über diese beiden Nummern die Dateiinformation effizient ohne aufwändige Suche eindeutig zur Verfügung.
Statt ''open'' wird ein ''lookup''-Aufruf implementiert
* Dieser liefert ein Datei-„Handle“, das die [[Inode]]nummer und die Gerätenummer des Massenspeichers auf dem Server enthält. Über dieses Handle kann eine Datei auf dem Server eindeutig identifiziert werden
* Unter Unix steht über diese beiden Nummern die Dateiinformation effizient ohne aufwändige Suche eindeutig zur Verfügung


Die weiteren Aufrufe wie ''read'' oder ''write'' müssen stets ein Offset übergeben, so dass der Server auch hier ohne Kenntnis früherer Operation die gewünschte Information eindeutig liefern kann.
Die weiteren Aufrufe wie ''read'' oder ''write'' müssen stets ein Offset übergeben, so dass der Server auch hier ohne Kenntnis früherer Operation die gewünschte Information eindeutig liefern kann


Weitere Eigenschaften des Protokolls sind
Weitere Eigenschaften des Protokolls sind
Zeile 75: Zeile 71:
* Verwendung von Unix-Dateiattributen (zum Beispiel Benutzer-''uid'')
* Verwendung von Unix-Dateiattributen (zum Beispiel Benutzer-''uid'')


Wegen des einfachen Designs läuft NFS in normalen Umgebungen gut:
Wegen des einfachen Designs läuft NFS in normalen Umgebungen gut
* lokales Netzwerk mit kurzen [[Antwortzeit]]en
* lokales Netzwerk mit kurzen [[Antwortzeit]]en
* Ausführen von Programmen über das lokale Netzwerk
* Ausführen von Programmen über das lokale Netzwerk
Zeile 86: Zeile 82:
* Verwendung von Firewalls (UDP, kein fester Port wegen ''Portmapper'') (Unter NFSv4 kein Problem mehr; jegliche Kommunikation läuft über Port 2049/TCP)
* Verwendung von Firewalls (UDP, kein fester Port wegen ''Portmapper'') (Unter NFSv4 kein Problem mehr; jegliche Kommunikation läuft über Port 2049/TCP)


Das Protokoll wurde Ende der 1980er-Jahre entwickelt. Auch teure [[Workstation]]s hatten zu dieser Zeit nur wenige [[Mebibyte]]s Arbeitsspeicher, typisch etwa 4 bis 8&nbsp;[[Mebibyte|MiB]]. Ein NFS-Server kann auf solchen Maschinen aufgrund des Designs trotzdem effizient betrieben werden.
Das Protokoll wurde Ende der 1980er-Jahre entwickelt
* Auch teure [[Workstation]]s hatten zu dieser Zeit nur wenige [[Mebibyte]]s Arbeitsspeicher, typisch etwa 4 bis 8&nbsp;[[Mebibyte|MiB]]
* Ein NFS-Server kann auf solchen Maschinen aufgrund des Designs trotzdem effizient betrieben werden


Wegen des zustandslosen Servers kann dieser ohne Datenverlust heruntergefahren und neu gestartet werden. Programme stürzen nicht ab und Benutzer müssen dann einfach warten, bis der Server wieder verfügbar ist.
Wegen des zustandslosen Servers kann dieser ohne Datenverlust heruntergefahren und neu gestartet werden
* Programme stürzen nicht ab und Benutzer müssen dann einfach warten, bis der Server wieder verfügbar ist


== Festplattenlose Arbeitsrechner ==
== Festplattenlose Arbeitsrechner ==
[[Arbeitsrechner]] (Workstations) können über NFS ganz ohne Festplatte betrieben werden.
[[Arbeitsrechner]] (Workstations) können über NFS ganz ohne Festplatte betrieben werden
Das Betriebssystem und die Betriebsparameter können über Protokolle wie [[Bootstrap Protocol|BOOTP]] und [[Trivial File Transfer Protocol|TFTP]] geladen werden. Ein spezieller Kernel (z.&nbsp;B. Linux) kann dann über NFS bereits auf das Root-Laufwerk unter Unix zugreifen. Spezielle plattenlose Arbeitsrechner ''([[Diskless-Workstation|diskless workstations]])'' wurden von der Firma Sun in den 1990er-Jahren angeboten.
Das Betriebssystem und die Betriebsparameter können über Protokolle wie [[Bootstrap Protocol|BOOTP]] und [[Trivial File Transfer Protocol|TFTP]] geladen werden
* Ein spezieller Kernel (z.&nbsp;B
* Linux) kann dann über NFS bereits auf das Root-Laufwerk unter Unix zugreifen
* Spezielle plattenlose Arbeitsrechner ''([[Diskless-Workstation|diskless workstations]])'' wurden von der Firma Sun in den 1990er-Jahren angeboten


Vorteile sind ein verringerter Wartungsaufwand, gemeinsame Nutzung von Speicherplatz sowie einfachere und preiswerte Client-Workstations ([[Thin Client]]s). Bei vielen Clients wird der Server jedoch stark belastet, außerdem sind die Zugriffe über Netzwerk in den meisten Fällen langsamer.
Vorteile sind ein verringerter Wartungsaufwand, gemeinsame Nutzung von Speicherplatz sowie einfachere und preiswerte Client-Workstations ([[Thin Client]]s)
* Bei vielen Clients wird der Server jedoch stark belastet, außerdem sind die Zugriffe über Netzwerk in den meisten Fällen langsamer


== PC-NFS ==
== PC-NFS ==
Sun und andere Firmen boten in den 1990er Jahren auch NFS-Clientsoftware für PCs unter [[Microsoft Windows|Windows]] an, das PC-NFS. Der Server musste weiterhin eine Unix-Workstation sein. Bis [[Windows for Workgroups]] war der Netzwerkzugriff unter Windows nicht Teil des Betriebssystems. In Unix-Umgebungen wurde der Einsatz von PCs dadurch wesentlich erleichtert.
Sun und andere Firmen boten in den 1990er Jahren auch NFS-Clientsoftware für PCs unter [[Microsoft Windows|Windows]] an, das PC-NFS
* Der Server musste weiterhin eine Unix-Workstation sein
* Bis [[Windows for Workgroups]] war der Netzwerkzugriff unter Windows nicht Teil des Betriebssystems
* In Unix-Umgebungen wurde der Einsatz von PCs dadurch wesentlich erleichtert


PC-NFS musste mit den unterschiedlichen Konzepten des DOS/Windows-Systems kämpfen. Die damaligen Windows-Versionen erlaubten nur Dateinamen mit bis zu acht Zeichen sowie eine drei Zeichen lange Erweiterung, die durch einen Punkt abgetrennt wurde (z.&nbsp;B. <code>AUTOEXEC.BAT</code>, die sogenannte [[8.3]]-Notation), während Unix 255 Zeichen lange Pfadnamen erlaubte. Die Dateinamen unterschieden im Gegensatz zu DOS zwischen Groß- und Kleinschreibung. PC-NFS musste also zwischen den Dateinamenkonzepten übersetzen.
PC-NFS musste mit den unterschiedlichen Konzepten des DOS/Windows-Systems kämpfen
* Die damaligen Windows-Versionen erlaubten nur Dateinamen mit bis zu acht Zeichen sowie eine drei Zeichen lange Erweiterung, die durch einen Punkt abgetrennt wurde (z.&nbsp;B. <code>AUTOEXEC.BAT</code>, die sogenannte [[8.3]]-Notation), während Unix 255 Zeichen lange Pfadnamen erlaubte
* Die Dateinamen unterschieden im Gegensatz zu DOS zwischen Groß- und Kleinschreibung
* PC-NFS musste also zwischen den Dateinamenkonzepten übersetzen


Ein Unix-Dateiname ''file.txt'' erschien als <span style="font-family:monospace;">FILE.TXT</span> unter Windows/DOS, während ein Dateiname ''Dokumentation.txt'' etwa in <span style="font-family:monospace;">DOKUME~1.TXT</span> umgesetzt wurde.
Ein Unix-Dateiname ''file.txt'' erschien als <span style="font-family:monospace;">FILE.TXT</span> unter Windows/DOS, während ein Dateiname ''Dokumentation.txt'' etwa in <span style="font-family:monospace;">DOKUME~1.TXT</span> umgesetzt wurde


== NFS Version 4 ==
== NFS Version 4 ==
Die NFS Version 4 stellt eine Neuimplementierung dar, die neuere Erfordernisse berücksichtigt. Sie ist in <nowiki>RFC&nbsp;7530</nowiki> standardisiert.<ref name="RFC7530" />
Die NFS Version 4 stellt eine Neuimplementierung dar, die neuere Erfordernisse berücksichtigt
* Sie ist in <nowiki>RFC&nbsp;7530</nowiki> standardisiert


Die Unix-Lastigkeit der frühen Versionen wird so weit wie möglich verringert. Die UNIX-Benutzer- und Gruppennummern werden durch eindeutigere Zeichenketten nach dem Muster nutzer@domain ersetzt. ''nutzer'' ist hierbei der Nutzername auf dem Server, ''domain'' ist die Domain des Servers, also der Teil des Hostnamens, der nicht den Server selbst identifiziert (''srv.cs.example.net'' → ''cs.example.net''). Durch die Kennung ''user@cs.example.net'' kann nun auf allen Rechnern der Domain ''cs.example.net'' der Nutzer eindeutig identifiziert werden, auch wenn der Nutzer ''user'' auf dem Server die Unix-User-ID 1050 hat und auf dem Client z.&nbsp;B. 1100. Dies führte bei früheren NFS-Versionen zu Problemen, wenn keine konsistente Nutzernummerierung eingehalten wurde. Für die Umsetzung der neuen NFS-Nutzernamen in (Unix-)Nutzer-IDs ist unter Linux zum Beispiel der Dienst ''rpc.idmapd'' ('''''ID''' '''map'''per '''d'''aemon''), unter [[FreeBSD]] der [[Daemon]] ''nfsuserd'' ('''''NFS''' '''user''' '''d'''aemon'') zuständig (sowohl für Server- als auch für Clientseite). Die Nutzernamen werden nur richtig zugeordnet, wenn Server und Client die gleiche Domain haben, ansonsten wird als Eigentümer ''nobody.nogroup'' angegeben.
Die Unix-Lastigkeit der frühen Versionen wird so weit wie möglich verringert
* Die UNIX-Benutzer- und Gruppennummern werden durch eindeutigere Zeichenketten nach dem Muster nutzer@domain ersetzt. ''nutzer'' ist hierbei der Nutzername auf dem Server, ''domain'' ist die Domain des Servers, also der Teil des Hostnamens, der nicht den Server selbst identifiziert (''srv.cs.example.net'' → ''cs.example.net'')
* Durch die Kennung ''user@cs.example.net'' kann nun auf allen Rechnern der Domain ''cs.example.net'' der Nutzer eindeutig identifiziert werden, auch wenn der Nutzer ''user'' auf dem Server die Unix-User-ID 1050 hat und auf dem Client z.&nbsp;B. 1100
* Dies führte bei früheren NFS-Versionen zu Problemen, wenn keine konsistente Nutzernummerierung eingehalten wurde
* Für die Umsetzung der neuen NFS-Nutzernamen in (Unix-)Nutzer-IDs ist unter Linux zum Beispiel der Dienst ''rpc.idmapd'' ('''''ID''' '''map'''per '''d'''aemon''), unter [[FreeBSD]] der [[Daemon]] ''nfsuserd'' ('''''NFS''' '''user''' '''d'''aemon'') zuständig (sowohl für Server- als auch für Clientseite)
* Die Nutzernamen werden nur richtig zugeordnet, wenn Server und Client die gleiche Domain haben, ansonsten wird als Eigentümer ''nobody.nogroup'' angegeben


Da manche Dateisysteme keine effiziente Implementierung von eindeutigen [[Datei-Handle]]s ermöglichen, werden ''flüchtige'' [[Handle]]s eingeführt, die nur eine bestimmte Zeit zur Verfügung stehen. Unter Unix kann man Handles sehr einfach aus der Geräte- und [[Inode]]-Nummer konstruieren. Auch Dateisysteme, die nicht zwischen Groß- und Kleinschreibung unterscheiden, sowie benutzerdefinierte Dateiattribute werden jetzt unterstützt.
Da manche Dateisysteme keine effiziente Implementierung von eindeutigen [[Datei-Handle]]s ermöglichen, werden ''flüchtige'' [[Handle]]s eingeführt, die nur eine bestimmte Zeit zur Verfügung stehen
* Unter Unix kann man Handles sehr einfach aus der Geräte- und [[Inode]]-Nummer konstruieren
* Auch Dateisysteme, die nicht zwischen Groß- und Kleinschreibung unterscheiden, sowie benutzerdefinierte Dateiattribute werden jetzt unterstützt


Das [[Mounten|Mount]]- und [[Lock]]protokoll sind jetzt Bestandteil des Protokolls selbst, Hilfsprotokolle werden nicht mehr benötigt. Das Protokoll selbst läuft auf dem festen [[Transmission Control Protocol|TCP]]-Port ''2049'', [[User Datagram Protocol|UDP]] wird nicht mehr unterstützt. Zwar liefen auch schon frühere Versionen auf diesem Port, die Hilfsprotokolle wurden vom RPC-Portmapper aber dynamisch zugeteilt. Die Verwendung von [[Firewall]]s bei NFS-Verbindungen wird durch diese Maßnahmen stark vereinfacht.
Das [[Mounten|Mount]]- und [[Lock]]protokoll sind jetzt Bestandteil des Protokolls selbst, Hilfsprotokolle werden nicht mehr benötigt
* Das Protokoll selbst läuft auf dem festen [[Transmission Control Protocol|TCP]]-Port ''2049'', [[User Datagram Protocol|UDP]] wird nicht mehr unterstützt
* Zwar liefen auch schon frühere Versionen auf diesem Port, die Hilfsprotokolle wurden vom RPC-Portmapper aber dynamisch zugeteilt
* Die Verwendung von [[Firewall]]s bei NFS-Verbindungen wird durch diese Maßnahmen stark vereinfacht


Mehrere Anfragen können gebündelt werden ''(combined request)'', sie werden dann vom Server ausgeführt und nur eine Antwort muss zurückgesendet werden. Das Protokoll kann damit effizient auch im Weitverkehrsbereich ([[Wide Area Network|WAN]]) eingesetzt werden, zum Beispiel zwischen verschiedenen Standorten einer Organisation.
Mehrere Anfragen können gebündelt werden ''(combined request)'', sie werden dann vom Server ausgeführt und nur eine Antwort muss zurückgesendet werden
* Das Protokoll kann damit effizient auch im Weitverkehrsbereich ([[Wide Area Network|WAN]]) eingesetzt werden, zum Beispiel zwischen verschiedenen Standorten einer Organisation


Verschlüsselung und [[Authentifizierung]] sind jetzt Teil der [[Spezifikation]]. Zwar war früher schon über Secure-RPC eine Verschlüsselung möglich. Das wurde nur selten genutzt, unter anderem, weil Secure-RPC nicht überall zur Verfügung stand.
Verschlüsselung und [[Authentifizierung]] sind jetzt Teil der [[Spezifikation]]
* Zwar war früher schon über Secure-RPC eine Verschlüsselung möglich
* Das wurde nur selten genutzt, unter anderem, weil Secure-RPC nicht überall zur Verfügung stand


Der ''lookup''-Aufruf wird durch ''open'' ersetzt, die Speicherung von Dateiinformationen wird dadurch möglich. Beispielsweise könnte die Schreib-/Leseposition auf dem Server verwaltet werden. Auch die gemeinsame Nutzung von Dateien wird besser unterstützt. Falls viele Clients eine Datei nur lesen, kann diese an alle Clients verliehen ''(leases)'' werden. Wenn ein Client eine Datei schreiben möchte, kann diese exklusiv verliehen werden.
Der ''lookup''-Aufruf wird durch ''open'' ersetzt, die Speicherung von Dateiinformationen wird dadurch möglich
* Beispielsweise könnte die Schreib-/Leseposition auf dem Server verwaltet werden
* Auch die gemeinsame Nutzung von Dateien wird besser unterstützt
* Falls viele Clients eine Datei nur lesen, kann diese an alle Clients verliehen ''(leases)'' werden
* Wenn ein Client eine Datei schreiben möchte, kann diese exklusiv verliehen werden


In Version 4.1 ist unter anderem paralleler Zugriff auf über mehrere Server verteilten Speicher hinzugefügt worden. Ab Version 4.2 im November 2016 werden serverseitige Kopien und Sparsefiles unterstützt.
In Version 4.1 ist unter anderem paralleler Zugriff auf über mehrere Server verteilten Speicher hinzugefügt worden
* Ab Version 4.2 im November 2016 werden serverseitige Kopien und Sparsefiles unterstützt


== Konfiguration in Unix-Systemen ==
== Installation ==
Die NFS-Freigaben werden unter Unix serverseitig meist in der Datei /etc/exports festgelegt, die nach dem folgenden Schema aufgebaut ist. Dabei sind die Unterschiede zwischen Linux- und FreeBSD-Systemen zu beachten:
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>


# Server-Adresse: 10.0.0.1
== Aufruf ==
# NFSv2, NFSv3:
<syntaxhighlight lang="bash" highlight="1" line copy>
# Exportiert /path/to/directory an alle IPs von 10.0.0.0 bis 10.0.255.255,
</syntaxhighlight>
# und zwar zum Lesen/Schreiben (rw), asynchronem Zugriff (Daten werden
# nicht sofort geschrieben) und auch von Ports über 1024 aus (insecure)
#
# Erreichbar als: 10.0.0.1:/path/to/directory
#
### Linux-Systeme
/path/to/directory 10.0.0.0/16(rw,async,insecure)


### FreeBSD
=== Optionen ===
/path/to/directory        -network 10.0.0.0/16
{| class="wikitable sortable options gnu big"
 
|-
# NFSv4:
! Unix !! GNU !! Parameter !! Beschreibung
# Benötigt zur optimalen Funktion eine Freigabe mit der Option ''fsid=0''.
# Diese wird als root-Freigabe genutzt und ist als die Freigabe / zu
# erreichen. Die anderen Freigaben liegen unterhalb davon. Ansonsten
# ist optional eine Authentifizierung/Verschlüsselung mit [[Kerberos (Informatik)|Kerberos]]
# möglich.
#
### Linux-Systeme:
# Erreichbar als 10.0.0.1:/
# Wird diese Freigabe eingehängt, so sind alle darunterliegenden
# Freigaben logischerweise zugänglich.
/path/to/nfsv4/root 10.0.0.0/16(rw,async,insecure,'''fsid=0''')
# Erreichbar als 10.0.0.1:/export1
/path/to/nfsv4/root/export1 10.0.0.0/16(rw,async,insecure)
 
### FreeBSD
# Root-Punkt spezifizieren (unter Linux der mit fsid=0 markierte Punkt)
V4: /path/to/nfsv4/root    -network 10.0.0.0/16
# Freigaben angeben
/path/to/nfsv4/root/export1 -network 10.0.0.0/16
 
Der Client kann eine Freigabe manuell mounten oder ggf. mit einem Eintrag in der Datei [[fstab]] automatisieren.
 
Vielen aktuellen [[Linux-Distribution]]en liegen grafische Hilfswerkzeuge bei, um die Einbindung von NFS-Freigaben ins System zu vereinfachen, zum Beispiel das NFS-[[YaST]]-Plugin unter [[openSUSE]].
 
== Sicherheit ==
 
=== NFS Version 3 und früher ===
NFS wurde geschaffen, um in Unix-Netzen [[Dateisystem]]e über Rechnergrenzen hinweg zugänglich zu machen. Zur Zeit der Entwicklung von NFS waren solche Netze fast ausschließlich zentral verwaltet und die Rechner wurden zentral administriert, entsprechend wurde das Sicherheitskonzept gestaltet.
 
Die Entwickler von NFS bei Sun Microsystems hatten ursprünglich vorgesehen, die Sicherheit als Aufgabe der RPC-Schicht zu implementieren. Dazu wird RPC durch Secure-RPC ersetzt. Die NFS-Protokolle selbst bleiben davon unberührt. Secure-RPC hat allerdings keine weite Verbreitung gefunden, die Verwendung ist auch nicht bei allen Implementierungen möglich.
 
Ein NFS-Server ohne Secure-RPC exportiert Dateisysteme an bestimmte andere Rechner (von [[Root-Konto|root]] durch [[IP-Adresse]]n festgelegt), d.&nbsp;h. der root-User eines Clientrechners kann auf alle Dateien zugreifen, die der Server an den Client exportiert, unabhängig von deren Zugriffsrechten. Die Zugriffsrechte (der Benutzer) werden von NFS an den Client mitübertragen und vom Betriebssystem des jeweiligen Rechners ausgewertet und gegenüber den Benutzern durchgesetzt. Die Konsistenz der Benutzerdatenbank auf den beteiligten Rechnern wird dabei z.&nbsp;B. durch [[Network Information Service|NIS]] erreicht.
 
Heute sind Rechnernetze häufig offen und nur bedingt zentral administriert, d.&nbsp;h. ein Angreifer kann relativ einfach entweder einen Rechner übernehmen, dem der NFS-Server vertraut, indem er ihn z.&nbsp;B. mit einem [[Live-System]] neu bootet oder einen zusätzlichen Laptop ins Netz hängt und die IP eines gerade nicht laufenden NFS-Clients annimmt. In beiden Fällen kann der Angreifer, da er auf seinem System Rootrechte hat, auf alle an den Client exportierten Dateien zugreifen, unabhängig von deren Zugriffsrechten. Somit ist NFS v3 ohne separat installiertes [[Kerberos (Protokoll)|Kerberos]] immer nur so sicher wie das Netz und die beteiligten Rechner.
 
Mit der Server-Option ''root_squash'' (unter FreeBSD mit der in der entsprechenden Zeile anzugebenden Option <span style="font-family:monospace;">-maproot=<USER></span>) kann man das oben genannte Szenario unterbinden. Damit werden Zugriffe durch Benutzer mit der UID 0 (meist ''root'') als Zugriffe des anonymen Benutzers (UID=65534) gewertet, der dann u.&nbsp;U. keinerlei Zugriffsrechte auf die freigegebenen Dateien hat. Ein Angreifer muss nun beim Verbinden so lange unterschiedliche UIDs ausprobieren, bis er die UID des Benutzers oder der Gruppe erwischt, die berechtigt ist. Da es nur <math>2^{16}</math> (65536) UIDs gibt, bietet auch dieses Vorgehen keine echte Sicherheit.
 
=== NFS Version 4 ===
NFSv4 löst dieses Problem, indem z.&nbsp;B. [[Kerberos (Informatik)|Kerberos]] nun Bestandteil des Protokolls ist und eine Authentifizierung der Benutzer ermöglicht. Zudem lässt sich mit einer ebenfalls optionalen Verschlüsselung auch die [[Vertraulichkeit]] sicherstellen.
 
==== Verfügbare Sicherheitsmodi ====
Beim Verbinden kann einer der folgenden Mechanismen gewählt werden, um das Sicherheitsniveau (welches auch die Übertragungsgeschwindigkeit beeinflusst) festzulegen:
{| class="wikitable"
|-
|-
! Bezeichnung
| || || ||
! Bedeutung
! Mount-Option
|-
|-
| sys
|}
| Benutzeridentifikation erfolgt nach dem Schema von NFS3. Dies bietet sehr wenig Sicherheit.
 
| sec=sys
=== Parameter ===
=== Umgebungsvariablen ===
=== Exit-Status ===
{| class="wikitable options col1center big"
|-
|-
| krb5
! Wert !! Beschreibung
| Server und Client authentifizieren sich gegenseitig unter Benutzung der [[GSSAPI|GSS]]-Schnittstelle mittels Kerberos. Dies unterbindet das obige Angriffsszenario.
| sec=krb5
|-
|-
| krb5i
| 0 || Erfolg
| Zusätzlich wird die Integrität der übertragenen Daten sichergestellt. Dies verhindert eine Veränderung der Daten durch einen [[Man-in-the-Middle-Angriff|Man In The Middle]].
| sec=krb5i
|-
|-
| krb5p
| >0 || Fehler
| Die Vertraulichkeit der übertragenen Daten wird zusätzlich zur Integrität gewährleistet. Dies verhindert ein Mitlesen durch einen Angreifer im Netzwerk.
| sec=krb5p
|}
|}


Eine Freigabe kann mehrere Mechanismen anbieten, aus denen der Client einen durch die Mount-Option auswählen kann.
== Anwendung ==
<syntaxhighlight lang="bash" highlight="1" line copy>
</syntaxhighlight>


==== Alternative zu Kerberos ====
=== Problembehebung ===
Allerdings wird des Öfteren bemängelt, dass mit Kerberos eine enorm komplexe und in einigen Umgebungen unmögliche Voraussetzung besteht. Daher wird anstelle der eingebauten Sicherheitsfunktionen von NFS oft eine zusätzliche Sicherheits-Schicht wie [[Transport Layer Security|TLS]] genutzt.<ref>{{Internetquelle |autor=Charles Fisher |url=https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls |titel=Encrypting NFSv4 with Stunnel TLS |werk=Linux Journal |hrsg=Slashdot Media, LLC |datum=2018-08-03 |sprache=en |abruf=2022-01-14}} {{" |Sprache=en |Text=The sec=krb5p option will encrypt NFSv4 traffic in a Kerberos realm, but requiring this infrastructure is inappropriate in hosted environments and is generally far from helpful. Basic access to symmetric cryptography does not and should not mandate such enormous baggage.}}</ref>


== Normen und Standards ==
Die Version 1.0 hat [[Sun Microsystems]] im Jahr 1984 erstellt.<ref name="sun85">{{Internetquelle |autor=Russel Sandberg, David Goldberg, Steve Kleiman, Dan Walsh, Bob Lyon |url=http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.473 |titel=Design and Implementation of the Sun Network Filesystem |hrsg=[[USENIX]] |datum=1985 |abruf=2023-07-20}}</ref> Ab der Version 2.0 erfolgte die weitere Standardisierung als [[Request for Comments]]. Erst mit der Version 4.0 erfolgte der Wechsel vom Status Informational in Offizieller Standard. Die drei Versionen 4.0, 4.1 und 4.2 sind alle zugleich aktuelle Standards, deshalb gibt es seit 2017 auch Ergänzungen ohne Versionsnummer:


a) Ursprünglicher Pfad von Version 2 zu Version 4.0:
<noinclude>
* {{RFC-Internet |RFC=1094 |Titel=NFS Version 2 Protocol Specification |Datum=1989 |Updated=3010}}
* {{RFC-Internet |RFC=1813 |Titel=NFS Version 3 Protocol Specification |Datum=1995 |Updated=3010}}
* {{RFC-Internet |RFC=3010 |Titel=NFS Version 4 Protocol |Datum=2000 |Updated=3530}}
* {{RFC-Internet |RFC=3530 |Titel=Network File System (NFS) version 4 Protocol |Datum=2003 |Updated=7530}}
* {{RFC-Internet |RFC=7530 |Titel=NFS Version 4 Protocol Specification |Datum=2015}}
* {{RFC-Internet |RFC=7931 |Titel=NFSv4.0 Migration: Specification Update |Datum=2016}}


b) Neuere Versionen 4.x
== Anhang ==
* {{RFC-Internet |RFC=5661 |Titel=Network File System (NFS) Version 4 Minor Version 1 Protocol |Datum=2010 |Kommentar=NFS 4.1}}
=== Siehe auch ===
* {{RFC-Internet |RFC=7862 |Titel=Network File System (NFS) Version 4 Minor Version 2 Protocol |Datum=2016 |Kommentar=NFS 4.2}}
<div style="column-count:2">
<categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree>
</div>
----
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}


c) Ergänzungen für 4.x
=== Dokumentation ===
* {{RFC-Internet |RFC=8178 |Titel=Rules for NFSv4 Extensions and Minor Versions |Datum=2017}}
; Man-Page
* {{RFC-Internet |RFC=8434 |Titel=Requirements for Parallel NFS (pNFS) Layout Types |Datum=2018}}
# [https://manpages.debian.org/stable/procps/pgrep.1.de.html prep(1)]


== Weblinks ==
=== Links ===
==== Projekt ====
==== Weblinks ====
# https://de.wikipedia.org/wiki/Network_File_System
# https://de.wikipedia.org/wiki/Network_File_System


== Einzelnachweise ==
[[Kategorie:NFS]]
<references>
<ref name="RFC7530">
{{RFC-Internet |RFC=7530 |Titel=NFS Version 4 Protocol Specification |Datum=2015}}
</ref>
</references>


[[Kategorie:Freies Dateisystem]]
</noinclude>
[[Kategorie:Internet-Dateiübertragungsprotokoll]]
[[Kategorie:Verteiltes Dateisystem]]

Aktuelle Version vom 8. Oktober 2025, 10:13 Uhr

Network File System - Protokoll, das den Zugriff auf Dateien über ein Netzwerk ermöglicht

Beschreibung

NFS im OSI-Schichtenmodell
Anwendung NFS
Darstellung XDR
Sitzung (Sun-) RPC
Transport (UDP) TCP
Netzwerk IP (IPv4, IPv6)
Netzzugang Ethernet Token
Ring 		FDDI …

Das Network File System (NFS, auch Network File Service) ist ein von Sun Microsystems entwickeltes Protokoll, das den Zugriff auf Dateien über ein Netzwerk ermöglicht

  • Dabei werden die Dateien nicht wie z. B. bei FTP übertragen, sondern die Benutzer können auf Dateien, die sich auf einem entfernten Rechner befinden, so zugreifen, als ob sie auf ihrer lokalen Festplatte abgespeichert wären

Bei diesem Unix-Netzwerkprotokoll handelt es sich um einen Internet-Standard (RFC 1094, RFC 7530), der auch als verteiltes Dateisystem () bezeichnet wird

Die Entsprechung zu NFS heißt unter Windows- und OS/2-Umgebungen Server Message Block (SMB) Während sich bei SMB der Benutzer authentifiziert, authentisiert NFSv3 den Client-Rechner, erst NFSv4 ermöglicht Benutzerauthentifikation

  • NFS-Dienste sind auch auf Microsoft-Windows-Servern verfügbar, wodurch UNIX-Workstations Zugang zu deren Dateien erhalten können, allerdings wird in gemischten Umgebungen meist SMB mit Samba auf Unixseite verwendet

NFS arbeitet auf dem Netzwerkprotokoll IP ursprünglich zusammen mit dem zustandslosen UDP

  • Mittlerweile gibt es aber auch NFS über TCP
  • NFSv4 arbeitet nur mit TCP und benötigt nur noch einen Port (2049), was den Betrieb durch Firewalls erleichtert
  • NFSv4 wurde maßgeblich durch die IETF entwickelt, nachdem Sun die Entwicklung abgegeben hatte

Datenübertragung

Schematischer Ablauf der Datenübertragung

Im Folgenden ist der prinzipielle Ablauf einer NFS-Kommunikation des alten zustandslosen NFS bis einschließlich Version 3 beschrieben

  • Szenario: Ein Nutzer des Client-Rechners möchte ein entferntes Verzeichnis (/directory) öffnen und eine darin befindliche Datei (test) anzeigen lassen

Damit ein Datenaustausch zwischen NFS-Server und -Client stattfinden kann, muss der NFS-Server gestartet und beim Portmapper registriert sein

  1. Client kontaktiert Portmapper auf Port 111 und fragt nach dem Port des Mount-Daemons (mountd)
  2. Portmapper gibt Portnummer für mountd heraus
  • Typischerweise ist das 694
  1. Client kontaktiert mountd und fragt nach einem Filehandle für /directory, des vom Clienten zu mountenden Verzeichnisses des Servers
  2. mountd gibt ein Filehandle 0 als root-Filehandle für das zu mountende Verzeichnis des Servers zurück
  3. Client kontaktiert Portmapper und fragt nach dem Port für NFS (nfsd)
  • Typischerweise ist das 2049
  1. Portmapper gibt Portnummer für nfsd heraus
  2. Client führt LOOKUP-Prozedur aus mit den Parametern Filehandle 0 und dem Dateinamen (test)
  3. nfsd gibt Filehandle 1 für Datei (test) heraus
  4. Client führt READ-Prozedur aus mit dem Parameter Filehandle 1
  5. nfsd gibt Inhalt der Datei (test) zurück (Daten)

Design

Design der frühen Versionen des Systems

Ein Programm greift auf das Dateisystem über Systemaufrufe zu

  • Unter Unix sind die wichtigsten Systemaufrufe
  • open, close – Öffnen und Schließen einer Datei
  • read, write – Lesen und Schreiben
  • create, unlink – Erzeugen und Löschen
  • mkdir, rmdir – Erzeugen und Löschen eines Verzeichnisses
  • readdir – Lesen von Verzeichniseinträgen

Ein Netzwerkdateisystem muss diese Aufrufe in Netzwerkpakete verpacken und an einen Server senden

  • Dieser antwortet dann mit der entsprechenden Information oder einem Fehler

Die Entwickler von Sun Microsystems entschieden sich zunächst für ein Remote-Procedure-Call-Modell. XDR setzt die Parameter des RPCs in ein maschinenunabhängiges Format um, die Zugriffe werden dann über den RPC Mechanismus wie ein normaler Unterprogrammaufruf behandelt

Die Systemaufrufe werden aber nicht direkt in RPC-Aufrufe umgesetzt, da dann eine über open geöffnete Datei auch auf dem Server geöffnet werden müsste

  • Bei vielen Clients wären die Server dann schnell überlastet, da die Maschinen Mitte der 1980er-Jahre noch relativ wenig Speicher hatten
  • Die Aufgaben des Servers wurden daher so einfach wie möglich gehalten, der Server merkt sich keine Dateiinformationen zwischen zwei RPC-Aufrufen
  • Er ist also zustandslos

Statt open wird ein lookup-Aufruf implementiert

  • Dieser liefert ein Datei-„Handle“, das die Inodenummer und die Gerätenummer des Massenspeichers auf dem Server enthält. Über dieses Handle kann eine Datei auf dem Server eindeutig identifiziert werden
  • Unter Unix steht über diese beiden Nummern die Dateiinformation effizient ohne aufwändige Suche eindeutig zur Verfügung

Die weiteren Aufrufe wie read oder write müssen stets ein Offset übergeben, so dass der Server auch hier ohne Kenntnis früherer Operation die gewünschte Information eindeutig liefern kann

Weitere Eigenschaften des Protokolls sind

  • nur kurze Cachezeiten (wenige Sekunden) für Verzeichnisinformationen und Dateiattribute
  • kein Datencache
  • Verwendung des verbindungslosen User Datagram Protocols (UDP) optional TCP (NFSv4 nur TCP)
  • Lock- und Mount-Operationen über zusätzliche Hilfsprotokolle
  • Verwendung von Unix-Dateiattributen (zum Beispiel Benutzer-uid)

Wegen des einfachen Designs läuft NFS in normalen Umgebungen gut

  • lokales Netzwerk mit kurzen Antwortzeiten
  • Ausführen von Programmen über das lokale Netzwerk
  • Normale Benutzeraktivitäten (Editieren, Programme übersetzen)
  • Server mit relativ wenig Arbeitsspeicher

Weniger gut ist das Verhalten bei

  • gemeinsamer Nutzung von Dateien
  • Verwendung über das Internet (lange Antwortzeiten, geringe Sicherheit)
  • Verwendung von Firewalls (UDP, kein fester Port wegen Portmapper) (Unter NFSv4 kein Problem mehr; jegliche Kommunikation läuft über Port 2049/TCP)

Das Protokoll wurde Ende der 1980er-Jahre entwickelt

  • Auch teure Workstations hatten zu dieser Zeit nur wenige Mebibytes Arbeitsspeicher, typisch etwa 4 bis 8 MiB
  • Ein NFS-Server kann auf solchen Maschinen aufgrund des Designs trotzdem effizient betrieben werden

Wegen des zustandslosen Servers kann dieser ohne Datenverlust heruntergefahren und neu gestartet werden

  • Programme stürzen nicht ab und Benutzer müssen dann einfach warten, bis der Server wieder verfügbar ist

Festplattenlose Arbeitsrechner

Arbeitsrechner (Workstations) können über NFS ganz ohne Festplatte betrieben werden Das Betriebssystem und die Betriebsparameter können über Protokolle wie BOOTP und TFTP geladen werden

  • Ein spezieller Kernel (z. B
  • Linux) kann dann über NFS bereits auf das Root-Laufwerk unter Unix zugreifen
  • Spezielle plattenlose Arbeitsrechner (diskless workstations) wurden von der Firma Sun in den 1990er-Jahren angeboten

Vorteile sind ein verringerter Wartungsaufwand, gemeinsame Nutzung von Speicherplatz sowie einfachere und preiswerte Client-Workstations (Thin Clients)

  • Bei vielen Clients wird der Server jedoch stark belastet, außerdem sind die Zugriffe über Netzwerk in den meisten Fällen langsamer

PC-NFS

Sun und andere Firmen boten in den 1990er Jahren auch NFS-Clientsoftware für PCs unter Windows an, das PC-NFS

  • Der Server musste weiterhin eine Unix-Workstation sein
  • Bis Windows for Workgroups war der Netzwerkzugriff unter Windows nicht Teil des Betriebssystems
  • In Unix-Umgebungen wurde der Einsatz von PCs dadurch wesentlich erleichtert

PC-NFS musste mit den unterschiedlichen Konzepten des DOS/Windows-Systems kämpfen

  • Die damaligen Windows-Versionen erlaubten nur Dateinamen mit bis zu acht Zeichen sowie eine drei Zeichen lange Erweiterung, die durch einen Punkt abgetrennt wurde (z. B. AUTOEXEC.BAT, die sogenannte 8.3-Notation), während Unix 255 Zeichen lange Pfadnamen erlaubte
  • Die Dateinamen unterschieden im Gegensatz zu DOS zwischen Groß- und Kleinschreibung
  • PC-NFS musste also zwischen den Dateinamenkonzepten übersetzen

Ein Unix-Dateiname file.txt erschien als FILE.TXT unter Windows/DOS, während ein Dateiname Dokumentation.txt etwa in DOKUME~1.TXT umgesetzt wurde

NFS Version 4

Die NFS Version 4 stellt eine Neuimplementierung dar, die neuere Erfordernisse berücksichtigt

  • Sie ist in RFC 7530 standardisiert

Die Unix-Lastigkeit der frühen Versionen wird so weit wie möglich verringert

  • Die UNIX-Benutzer- und Gruppennummern werden durch eindeutigere Zeichenketten nach dem Muster nutzer@domain ersetzt. nutzer ist hierbei der Nutzername auf dem Server, domain ist die Domain des Servers, also der Teil des Hostnamens, der nicht den Server selbst identifiziert (srv.cs.example.net → cs.example.net)
  • Durch die Kennung user@cs.example.net kann nun auf allen Rechnern der Domain cs.example.net der Nutzer eindeutig identifiziert werden, auch wenn der Nutzer user auf dem Server die Unix-User-ID 1050 hat und auf dem Client z. B. 1100
  • Dies führte bei früheren NFS-Versionen zu Problemen, wenn keine konsistente Nutzernummerierung eingehalten wurde
  • Für die Umsetzung der neuen NFS-Nutzernamen in (Unix-)Nutzer-IDs ist unter Linux zum Beispiel der Dienst rpc.idmapd (ID mapper daemon), unter FreeBSD der Daemon nfsuserd (NFS user daemon) zuständig (sowohl für Server- als auch für Clientseite)
  • Die Nutzernamen werden nur richtig zugeordnet, wenn Server und Client die gleiche Domain haben, ansonsten wird als Eigentümer nobody.nogroup angegeben

Da manche Dateisysteme keine effiziente Implementierung von eindeutigen Datei-Handles ermöglichen, werden flüchtige Handles eingeführt, die nur eine bestimmte Zeit zur Verfügung stehen

  • Unter Unix kann man Handles sehr einfach aus der Geräte- und Inode-Nummer konstruieren
  • Auch Dateisysteme, die nicht zwischen Groß- und Kleinschreibung unterscheiden, sowie benutzerdefinierte Dateiattribute werden jetzt unterstützt

Das Mount- und Lockprotokoll sind jetzt Bestandteil des Protokolls selbst, Hilfsprotokolle werden nicht mehr benötigt

  • Das Protokoll selbst läuft auf dem festen TCP-Port 2049, UDP wird nicht mehr unterstützt
  • Zwar liefen auch schon frühere Versionen auf diesem Port, die Hilfsprotokolle wurden vom RPC-Portmapper aber dynamisch zugeteilt
  • Die Verwendung von Firewalls bei NFS-Verbindungen wird durch diese Maßnahmen stark vereinfacht

Mehrere Anfragen können gebündelt werden (combined request), sie werden dann vom Server ausgeführt und nur eine Antwort muss zurückgesendet werden

  • Das Protokoll kann damit effizient auch im Weitverkehrsbereich (WAN) eingesetzt werden, zum Beispiel zwischen verschiedenen Standorten einer Organisation

Verschlüsselung und Authentifizierung sind jetzt Teil der Spezifikation

  • Zwar war früher schon über Secure-RPC eine Verschlüsselung möglich
  • Das wurde nur selten genutzt, unter anderem, weil Secure-RPC nicht überall zur Verfügung stand

Der lookup-Aufruf wird durch open ersetzt, die Speicherung von Dateiinformationen wird dadurch möglich

  • Beispielsweise könnte die Schreib-/Leseposition auf dem Server verwaltet werden
  • Auch die gemeinsame Nutzung von Dateien wird besser unterstützt
  • Falls viele Clients eine Datei nur lesen, kann diese an alle Clients verliehen (leases) werden
  • Wenn ein Client eine Datei schreiben möchte, kann diese exklusiv verliehen werden

In Version 4.1 ist unter anderem paralleler Zugriff auf über mehrere Server verteilten Speicher hinzugefügt worden

  • Ab Version 4.2 im November 2016 werden serverseitige Kopien und Sparsefiles unterstützt

Installation

Aufruf

Optionen

Unix GNU Parameter Beschreibung

Parameter

Umgebungsvariablen

Exit-Status

Wert Beschreibung
0 Erfolg
>0 Fehler

Anwendung

Problembehebung

Anhang

Siehe auch

Dokumentation

Man-Page
  1. prep(1)

Links

Projekt

Weblinks

  1. https://de.wikipedia.org/wiki/Network_File_System


Abgerufen von „https://wiki.foxtom.de/index.php?title=Network_File_System&oldid=154461“