Network File System - Versionsgeschichte

178.15.120.59: /* Weblinks */

178.15.120.59 — Thu, 22 May 2025 06:00:06 GMT

Weblinks

← Nächstältere Version		Version vom 22. Mai 2025, 08:00 Uhr
Zeile 237:		Zeile 237:
	\|abruf=2010-12-16}}		\|abruf=2010-12-16}}
	* {{dmoz\|Computers/Software/Operating_Systems/File_Systems/NFS/\|NFS}} (englisch).		* {{dmoz\|Computers/Software/Operating_Systems/File_Systems/NFS/\|NFS}} (englisch).
	* [http://support.microsoft.com/kb/324055 Installation des NFS-Clients unter Windows.] Microsoft Technet.
	* [http://www.selflinux.org/selflinux/html/nfs.html NFS – Network File System.] SelfLinux.

	== Einzelnachweise ==		== Einzelnachweise ==

Wiegels: Tabellenformatierung, Typografie

Wiegels — Sun, 26 Jan 2025 14:57:58 GMT

Tabellenformatierung, Typografie

SineOhneApfel am 16. August 2024 um 23:21 Uhr

SineOhneApfel — Fri, 16 Aug 2024 23:21:51 GMT

← Nächstältere Version		Version vom 17. August 2024, 01:21 Uhr
Zeile 30:		Zeile 30:

	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 ~~das~~ 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.<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>

SineOhneApfel: reine Spkulation über Popularität von NFSv3/SMB gelöscht

SineOhneApfel — Fri, 16 Aug 2024 23:20:00 GMT

reine Spkulation über Popularität von NFSv3/SMB gelöscht

← Nächstältere Version		Version vom 17. August 2024, 01:20 Uhr
Zeile 30:		Zeile 30:

	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 das ~~populärere~~ 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 das 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.<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>

SineOhneApfel: /* NFS Version 3 und früher */ Link ohne Weiterleitung

SineOhneApfel — Fri, 16 Aug 2024 22:46:16 GMT

NFS Version 3 und früher: Link ohne Weiterleitung

← Nächstältere Version		Version vom 17. August 2024, 00:46 Uhr
Zeile 171:		Zeile 171:
	Ein NFS-Server ohne Secure-RPC exportiert Dateisysteme an bestimmte andere Rechner (von [[Root-Konto\|root]] durch [[IP-Adresse]]n festgelegt), d. 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. B. durch [[Network Information Service\|NIS]] erreicht.		Ein NFS-Server ohne Secure-RPC exportiert Dateisysteme an bestimmte andere Rechner (von [[Root-Konto\|root]] durch [[IP-Adresse]]n festgelegt), d. 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. B. durch [[Network Information Service\|NIS]] erreicht.

	Heute sind Rechnernetze häufig offen und nur bedingt zentral administriert, d. h. ein Angreifer kann relativ einfach entweder einen Rechner übernehmen, dem der NFS-Server vertraut, indem er ihn z. 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 (~~Informatik~~)\|Kerberos]] immer nur so sicher wie das Netz und die beteiligten Rechner.		Heute sind Rechnernetze häufig offen und nur bedingt zentral administriert, d. h. ein Angreifer kann relativ einfach entweder einen Rechner übernehmen, dem der NFS-Server vertraut, indem er ihn z. 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. 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.		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. 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.

A.hafner: Anpassung URL (führte am 18.08.23 um 11:03 ohne 'www.' auf die Haupt- stattt auf die Themenseite)

A.hafner — Fri, 18 Aug 2023 09:04:26 GMT

Anpassung URL (führte am 18.08.23 um 11:03 ohne 'www.' auf die Haupt- stattt auf die Themenseite)

← Nächstältere Version		Version vom 18. August 2023, 11:04 Uhr
Zeile 238:		Zeile 238:
	* {{dmoz\|Computers/Software/Operating_Systems/File_Systems/NFS/\|NFS}} (englisch).		* {{dmoz\|Computers/Software/Operating_Systems/File_Systems/NFS/\|NFS}} (englisch).
	* [http://support.microsoft.com/kb/324055 Installation des NFS-Clients unter Windows.] Microsoft Technet.		* [http://support.microsoft.com/kb/324055 Installation des NFS-Clients unter Windows.] Microsoft Technet.
	* [http://selflinux.org/selflinux/html/nfs.html NFS – Network File System.] SelfLinux.		* [http://www.selflinux.org/selflinux/html/nfs.html NFS – Network File System.] SelfLinux.

	== Einzelnachweise ==		== Einzelnachweise ==

Matthäus Wander: link

Matthäus Wander — Tue, 25 Jul 2023 15:52:18 GMT

link

← Nächstältere Version		Version vom 25. Juli 2023, 17:52 Uhr
Zeile 39:		Zeile 39:
	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 (~~Protokoll~~)\|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. Typischerweise ist das 694.
	# Client kontaktiert mountd und fragt nach einem [[Filehandle]] für ''/directory'', des vom Clienten zu mountenden Verzeichnisses des Servers.		# Client kontaktiert mountd und fragt nach einem [[Filehandle]] für ''/directory'', des vom Clienten zu mountenden Verzeichnisses des Servers.

PerfektesChaos: tk k

PerfektesChaos — Thu, 20 Jul 2023 17:09:22 GMT

tk k

Änderungen zeigen

Bildungsbürger: -BKL-Link mit AWB

Bildungsbürger — Wed, 25 Jan 2023 11:51:54 GMT

-BKL-Link mit AWB

← Nächstältere Version		Version vom 25. Januar 2023, 13:51 Uhr
Zeile 25:		Zeile 25:
	\|}		\|}

	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. 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 [[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. 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.

	Bei diesem [[Unix]]-Netzwerkprotokoll handelt es sich um einen [[Internet]]-[[Standard]] (RFC 1094, RFC 1813, RFC 3530, RFC 7530), der auch als verteiltes [[Dateisystem]] ({{enS\|''distributed file system''}}) bezeichnet wird.		Bei diesem [[Unix]]-Netzwerkprotokoll handelt es sich um einen [[Internet]]-[[Standard]] (RFC 1094, RFC 1813, RFC 3530, RFC 7530), der auch als verteiltes [[Dateisystem]] ({{enS\|''distributed file system''}}) bezeichnet wird.

Ugnil: Wörter korrigiert und TLS verlinkt

Ugnil — Fri, 14 Jan 2022 10:46:48 GMT

Wörter korrigiert und TLS verlinkt

← Nächstältere Version		Version vom 14. Januar 2022, 12:46 Uhr
Zeile 176:		Zeile 176:

	=== NFS Version 4 ===		=== NFS Version 4 ===
	NFSv4 löst dieses Problem, indem z. B. [[Kerberos (Informatik)\|Kerberos]] nun Bestandteil des Protokolls ist und eine ~~Authentifikation~~ der Benutzer ermöglicht. Zudem lässt sich mit einer ebenfalls optionalen Verschlüsselung auch die [[Vertraulichkeit]] sicherstellen.		NFSv4 löst dieses Problem, indem z. 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 ====		==== Verfügbare Sicherheitsmodi ====
Zeile 205:		Zeile 205:

	==== Alternative zu Kerberos ====		==== Alternative zu Kerberos ====
	Allerdings wird des Öfteren bemängelt, dass mit Kerberos eine enorm komplexe und in einigen Umgebungen unmögliche ~~Vorraussetzung~~ besteht. Daher wird anstelle der eingebauten Sicherheitsfunktionen von NFS oft eine zusätzliche Sicherheits-Schicht wie 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 \|zitat=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>		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 \|zitat=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 ==		== Normen und Standards ==

← Nächstältere Version		Version vom 26. Januar 2025, 16:57 Uhr
Zeile 1:		Zeile 1:
	{\| ~~style~~="float:right; ~~padding~~-~~left~~:~~1em~~; text-align:center;" cellspacing="3"		{\| class="float-right" style="margin-top:0; text-align:center;" cellspacing="3"
	\|+ '''NFS im [[OSI-Schichtenmodell]]'''		\|+ '''NFS im [[OSI-Schichtenmodell]]'''
	\|-		\|-
Zeile 15:		Zeile 15:
	\|colspan="2" style="background:#EEEEFF"\| '''[[Transmission Control Protocol\|TCP]]'''		\|colspan="2" style="background:#EEEEFF"\| '''[[Transmission Control Protocol\|TCP]]'''
	\|-		\|-
	\|~~rowspan="1"~~ style="background:#FFCC99"\| ''Netzwerk''		\|style="background:#FFCC99"\| ''Netzwerk''
	\|colspan="4" style="background:#EEEEFF"\| '''[[Internet Protocol\|IP]] ([[IPv4]], [[IPv6]])'''		\|colspan="4" style="background:#EEEEFF"\| '''[[Internet Protocol\|IP]] ([[IPv4]], [[IPv6]])'''
	\|-		\|-
	\|~~rowspan="2"~~ style="background:#FFEEBB"\| ''Netzzugang''		\|style="background:#FFEEBB"\| ''Netzzugang''
	\|~~rowspan="2"~~ style="background:#EEEEEE"\| [[Ethernet]]		\|style="background:#EEEEEE"\| [[Ethernet]]
	\|~~rowspan="2"~~ style="background:#EEEEEE"\| [[Token Ring\|Token<br />Ring]]		\|style="background:#EEEEEE"\| [[Token Ring\|Token<br />Ring]]
	\|~~rowspan="2"~~ style="background:#EEEEEE"\| [[Fiber Distributed Data Interface\|FDDI]]		\|style="background:#EEEEEE"\| [[Fiber Distributed Data Interface\|FDDI]]
	\|~~rowspan="2"~~ style="background:#EEEEEE"\| …		\|style="background:#EEEEEE"\| …
	\|}		\|}

Zeile 35:		Zeile 35:

	== Schematischer Ablauf der 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.		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.		Damit ein Datenaustausch zwischen NFS-Server und -Client stattfinden kann, muss der NFS-Server gestartet und beim [[Portmapper]] registriert sein.
Zeile 45:		Zeile 45:
	# 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 0'' und dem Dateinamen (''test'')		# Client führt ''LOOKUP''-[[Prozedur (Programmierung)\|Prozedur]] aus mit den Parametern ''Filehandle 0'' und dem Dateinamen ''(test)''
	# nfsd gibt ''Filehandle 1'' für Datei (''test'') heraus		# nfsd gibt ''Filehandle 1'' für Datei ''(test)'' heraus
	# Client führt ''READ''-Prozedur aus mit dem Parameter ''Filehandle 1''		# Client führt ''READ''-Prozedur aus mit dem Parameter ''Filehandle 1''
	# 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 der frühen Versionen des Systems ==
Zeile 112:		Zeile 112:
	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.