Storage. Backup. Virtualisierung.
NFS - Network File System · Version 1.6 · © Stor IT Back 2026
NFS (Network File System) ist ein Netzwerkprotokoll für den dateibasierten Zugriff auf zentrale Speichersysteme und Fileserver. NFS wird vor allem unter Linux und Unix eingesetzt, kommt aber auch bei NAS-Systemen, VMware ESXi, Virtualisierung, Webservern und Backup-Systemen zum Einsatz. In Unternehmensumgebungen sind heute insbesondere NFSv3 sowie NFSv4.1 und NFSv4.2 relevant. NFSv4 integriert Funktionen für Authentifizierung, Locking und Statusverwaltung stärker in das Protokoll; NFSv4.1 ergänzt unter anderem Sessions und pNFS für parallele Zugriffe.
In einer Client-Server-Architektur sollen Dateien häufig zentral gespeichert und von mehreren Systemen genutzt werden. Dabei können Server und Clients unterschiedliche Betriebssysteme und lokale Dateisysteme einsetzen. Für diesen netzwerkbasierten Dateizugriff entwickelte Sun Microsystems das Network File System (NFS). NFS entstand ursprünglich für Unix- und Solaris-Umgebungen; NFSv2 war die erste breit veröffentlichte Version.
Bei NFS werden Dateien nicht wie bei einem klassischen Dateiübertragungsprotokoll vollständig zwischen zwei Systemen kopiert. Stattdessen stellt der NFS-Server Verzeichnisse als sogenannte Exports bereit. Ein Client bindet einen solchen Export ein und greift über das Netzwerk auf Ordner und Dateien zu, als wären sie Bestandteil seines lokalen Dateisystems.
Im Windows-Umfeld erfüllt SMB eine vergleichbare Aufgabe. NFS und SMB sind jedoch unterschiedliche Protokolle und nicht direkt miteinander kompatibel. NFS ist heute nicht auf Unix oder Linux beschränkt: Auch andere Betriebssysteme, Hypervisoren, NAS-Systeme und Storage-Arrays können NFS-Clients oder NFS-Server bereitstellen.
NFS wird sowohl für Benutzerverzeichnisse als auch im Serverbetrieb eingesetzt. Typische Beispiele sind zentrale Anwendungsdaten, Webserver-Farmen, VM-Datastores, Backup-Ziele und gemeinsame Dateibereiche für mehrere Systeme.
AUTH_SYS betrieben. Die Dateiberechtigungen basieren dabei auf UID und GID.In bestehenden Infrastrukturen ist NFSv3 weiterhin weit verbreitet. Neue Installationen verwenden je nach Plattform häufig NFSv4.1 oder NFSv4.2. Entscheidend ist nicht nur die Versionsnummer, sondern auch, welche Funktionen der eingesetzte Client, der NFS-Server und gegebenenfalls das Storage-System tatsächlich unterstützen.
| Merkmal | NFSv3 | NFSv4.0 | NFSv4.1 | NFSv4.2 |
|---|---|---|---|---|
| Transport | TCP oder UDP | TCP üblich | TCP | TCP |
| NFS-Port | 2049 plus je nach Implementierung weitere RPC-Dienste | 2049 | 2049 | 2049 |
| Locking | über zusätzliche Mechanismen/Dienste | im Protokoll integriert | im Protokoll integriert | im Protokoll integriert |
| RPCSEC_GSS / Kerberos | möglich | integriert vorgesehen | integriert vorgesehen | integriert vorgesehen |
| Sessions | nein | nein | ja | ja |
| pNFS | nein | nein | ja | ja |
| Server-Side Copy / Clone | nein | nein | nicht Bestandteil der Basisversion | als optionale Erweiterung |
Praxis: NFSv3 kann für einfache und etablierte Umgebungen weiterhin sinnvoll sein. NFSv4.1 ist besonders interessant, wenn moderne Sicherheitsmechanismen, Sessions, pNFS oder plattformspezifisches Multipathing benötigt werden. NFSv4.2 ergänzt weitere Funktionen, deren Nutzen von der konkreten Unterstützung durch Client und Storage abhängt.
Ein NFS-Server stellt Verzeichnisse als Exports bereit. Export-Regeln bestimmen unter anderem, welche Clients oder Netze zugreifen dürfen und ob ein Export nur lesbar oder auch beschreibbar ist. Diese hostbasierte Freigabe ist jedoch nur ein Teil des Sicherheitsmodells.
Bei klassischen NFS-Konfigurationen mit AUTH_SYS übermittelt der Client Benutzer- und Gruppenkennungen
in Form von UID und GID. Der Server prüft anschließend die Dateirechte anhand dieser Kennungen.
Damit dies zuverlässig funktioniert, müssen die Identitäten auf den beteiligten Systemen konsistent sein.
In größeren Umgebungen werden dafür typischerweise zentrale Identitätsdienste verwendet.
NFSv4 erweitert dieses Modell um ein standardisiertes Identity Mapping. Benutzer und Gruppen können zwischen Client und Server über Namen und eine NFSv4-Domain zugeordnet werden. Auf dem lokalen Linux-Dateisystem werden die Berechtigungen weiterhin über UID und GID umgesetzt. NFSv4 ersetzt Unix-IDs daher nicht vollständig, sondern definiert einen flexibleren Mechanismus für die Zuordnung von Identitäten zwischen Systemen.
NFSv4 vereinfacht viele Funktionen, die bei älteren NFS-Versionen über zusätzliche RPC-Dienste realisiert wurden. Locking und Statusinformationen sind stärker in das Protokoll integriert. Das erleichtert insbesondere den Betrieb über Firewalls und in komplexeren Netzwerken.
Mit NFSv4.1 kamen Sessions und pNFS (Parallel NFS) hinzu. Sessions verbessern die Zustandsverwaltung zwischen Client und Server. pNFS trennt den Metadatenpfad vom eigentlichen Datenzugriff und kann – sofern die beteiligten Systeme dies unterstützen – parallele Zugriffe auf mehrere Data Server beziehungsweise Storage-Pfade ermöglichen.
NFSv4.2 baut auf NFSv4.1 auf und ergänzt unter anderem Server-Side Copy, Clone, Sparse Files, Space Reservation und weitere Optimierungen. Diese Funktionen sind nicht in jeder Implementierung vollständig verfügbar. Vor einem produktiven Einsatz sollte daher geprüft werden, welche Features Client, Betriebssystem, Hypervisor und Storage-System tatsächlich unterstützen.
Die Sicherheit einer NFS-Umgebung hängt nicht allein von der NFS-Version ab. Entscheidend sind das verwendete Authentifizierungsverfahren, die Export-Regeln, das Netzwerkdesign und die Dateiberechtigungen.
sec=sys / AUTH_SYS: Der Client übermittelt UID und GID. Dieses Verfahren ist einfach und weit verbreitet, setzt aber vertrauenswürdige Clients und konsistente Identitäten voraus.sec=krb5: Authentifiziert Benutzer über Kerberos.sec=krb5i: Ergänzt zur Kerberos-Authentifizierung einen Integritätsschutz für die RPC-Kommunikation.sec=krb5p: Ergänzt Authentifizierung und Integritätsschutz um die Verschlüsselung der übertragenen RPC-Nutzdaten.Ein weiterer wichtiger Schutzmechanismus ist root_squash. Dabei wird der Benutzer root eines NFS-Clients auf dem Server nicht automatisch als lokaler root behandelt. Das reduziert das Risiko, dass ein kompromittierter oder falsch administrierter Client mit UID 0 uneingeschränkten Zugriff auf exportierte Dateien erhält.
Für produktive Umgebungen empfiehlt sich zusätzlich eine Netzwerksegmentierung. NFS sollte nur aus den tatsächlich benötigten Server-, Storage- oder Client-Netzen erreichbar sein. Export-Regeln sollten nach dem Prinzip der minimal notwendigen Berechtigungen definiert werden.
Bei einem reinen NFSv4-Betrieb läuft der eigentliche NFS-Datenverkehr üblicherweise über TCP-Port 2049. Viele Funktionen, die bei NFSv3 über zusätzliche RPC-Dienste bereitgestellt werden, sind bei NFSv4 in das Protokoll integriert. Dadurch lassen sich Firewall-Regeln deutlich einfacher gestalten.
Bei NFSv3 können neben Port 2049 weitere Dienste erforderlich sein,
beispielsweise rpcbind auf Port 111 sowie – abhängig von Betriebssystem und Konfiguration –
Dienste wie mountd, statd oder Lock-Manager.
Diese Ports können dynamisch vergeben oder auf feste Werte konfiguriert werden.
Wichtig: Wird Kerberos, LDAP, DNS oder eine andere zentrale Identitätsinfrastruktur verwendet, müssen deren benötigte Verbindungen zusätzlich berücksichtigt werden. „Nur Port 2049“ gilt daher nur für den eigentlichen NFSv4-Datenpfad und nicht automatisch für die komplette Umgebung.
Die erreichbare NFS-Performance wird nicht allein durch das Protokoll bestimmt. Wichtige Faktoren sind Netzwerkbandbreite und Latenz, die Leistungsfähigkeit des Storage-Backends, CPU-Ressourcen auf Client und Server, das I/O-Profil sowie die Anzahl paralleler Datenströme.
Moderne NFS-Implementierungen können 10, 25, 40 oder 100 Gbit/s nutzen. Eine 10-Gbit/s-Verbindung ist daher keine grundsätzliche Grenze für NFS. Bei schnellen Storage-Systemen kann vielmehr die Parallelisierung entscheidend sein. Je nach Plattform stehen dafür mehrere Möglichkeiten zur Verfügung:
Bei vielen kleinen Dateien ist häufig die Metadatenleistung entscheidend. Große sequentielle Dateien belasten dagegen vor allem Netzwerk und Durchsatz des Storage-Backends. Vor einer Änderung von Mount-Optionen sollte deshalb zuerst gemessen werden, wo der tatsächliche Engpass liegt.
NFS wird häufig zwischen Linux- und Unix-Systemen eingesetzt. Ein klassisches Beispiel sind zentral bereitgestellte Home-Verzeichnisse. Meldet sich ein Benutzer an verschiedenen Clients an, kann sein persönliches Verzeichnis unabhängig vom jeweiligen Arbeitsplatzsystem zentral verfügbar bleiben.
Auch im Server-Umfeld ist NFS weit verbreitet. Bei einer Webserver-Farm können beispielsweise mehrere Frontend-Server denselben zentralen Datenbestand verwenden. Änderungen an gemeinsam genutzten Dateien müssen dann nicht auf jedem Webserver separat verteilt werden. Voraussetzung ist allerdings, dass Anwendung, Caching und Locking für einen gemeinsamen Dateizugriff geeignet sind.
Weitere typische Einsatzbereiche sind gemeinsam genutzte Anwendungsdaten, technische File-Services, Container- oder Cluster-Umgebungen sowie NAS-Systeme, die NFS-Exports für Linux-Server bereitstellen.
VMware ESXi kann NFS-Speicher direkt als Datastore einbinden. Der große Vorteil liegt in der einfachen Bereitstellung von Shared Storage: Mehrere ESXi-Hosts können denselben NFS-Datastore verwenden, ohne dass auf den Hosts ein klassisches Block-Dateisystem für das Storage-LUN verwaltet werden muss.
In aktuellen VMware-Umgebungen sind insbesondere NFSv3 und NFSv4.1 relevant. NFSv4.1 kann mehrere Netzwerkpfade unterstützen; abhängig von der ESXi-Version und dem Storage-System stehen zusätzlich mehrere TCP-Verbindungen beziehungsweise nConnect-Funktionen zur Verfügung. Dadurch lässt sich die verfügbare Netzwerkbandbreite besser nutzen und die Ausfallsicherheit erhöhen.
Für die Performance sind neben der Netzwerkgeschwindigkeit insbesondere Latenz, Storage-Controller, Anzahl paralleler I/O-Ströme und das verwendete Netzwerkdesign relevant. NFS ist daher nicht grundsätzlich langsamer als Block-Storage; die passende Technologie hängt vom Workload, den Anforderungen an Verfügbarkeit und den Funktionen der eingesetzten Plattform ab.
NFS eignet sich auch als Ziel für Datensicherungen. Ein Backup-Server kann ein NFS-Repository beziehungsweise einen NFS-Export über das vorhandene Ethernet-Netz einbinden. Dadurch lässt sich das Sicherungsziel räumlich vom Produktivsystem trennen, beispielsweise in einem anderen Brandabschnitt oder Rechenzentrumsbereich.
Die Sicherungsleistung sollte dabei über eine kontrollierte Parallelität an die verfügbare Netzwerk- und Storage-Leistung angepasst werden. Moderne Backup-Lösungen sichern in der Regel mehrere Datenströme parallel; wie viele parallele Jobs sinnvoll sind, hängt von Repository, Netzwerk, Quellsystemen und gewünschtem Sicherungsfenster ab.
Bei einem Backup-Ziel sind außerdem Sicherheitsaspekte entscheidend: Der NFS-Export sollte nur für die tatsächlich benötigten Backup-Systeme erreichbar sein, Schreibrechte sollten möglichst restriktiv vergeben werden und Snapshots, Immutable Storage oder eine zusätzliche Offline-/Offsite-Kopie können das Schutzkonzept ergänzen.
NFS ist File-Storage: Der Server verwaltet das Dateisystem und stellt Ordner und Dateien über das Netzwerk bereit. Bei SMB ist das Grundprinzip ähnlich, das Protokoll und das Identitäts-/Berechtigungsmodell unterscheiden sich jedoch. SMB ist besonders im Windows-Umfeld verbreitet, während NFS traditionell stark in Linux-, Unix- und Storage-Umgebungen vertreten ist.
Block-Storage über iSCSI oder Fibre Channel stellt dem Host dagegen Blöcke beziehungsweise virtuelle Laufwerke zur Verfügung. Das Dateisystem wird dann vom Host oder Cluster verwaltet. Block-Storage kann bei bestimmten Datenbanken, Cluster-Dateisystemen oder sehr latenzsensitiven Anwendungen Vorteile bieten. NFS ist häufig einfacher zu administrieren, wenn mehrere Systeme gemeinsam auf Dateien oder einen zentralen Datastore zugreifen sollen.
NFS (Network File System) ist ein Netzwerkprotokoll für den dateibasierten Zugriff auf entfernte Verzeichnisse und Dateien. NFS wird vor allem unter Linux und Unix eingesetzt, aber auch von NAS-Systemen, Hypervisoren und Storage-Arrays unterstützt. Typische Einsatzbereiche sind zentrale File-Services, Home-Verzeichnisse, Anwendungsdaten, VM-Datastores und Backup-Ziele.
NFSv3 verwendet für einige Funktionen zusätzliche RPC-Dienste und wird häufig mit AUTH_SYS sowie UID/GID betrieben. NFSv4 integriert Locking und Statusverwaltung stärker in das Hauptprotokoll und vereinfacht damit unter anderem den Betrieb über Firewalls. NFSv4.1 ergänzt Sessions und pNFS, NFSv4.2 weitere optionale Funktionen wie Server-Side Copy und Clone.
Nein, diese Aussage wäre zu pauschal. Exports können zwar auf Hosts oder Netze begrenzt werden, zusätzlich werden bei AUTH_SYS UID und GID für Dateiberechtigungen verwendet. Auch NFSv3 kann RPCSEC_GSS beziehungsweise Kerberos nutzen. In der Praxis hängt die Sicherheit von Export-Regeln, Authentifizierung, konsistenten Identitäten, Netzwerksegmentierung und Dateirechten ab.
Der eigentliche NFSv4-Datenverkehr läuft üblicherweise über TCP-Port 2049. Bei NFSv3 können zusätzliche RPC-Dienste erforderlich sein, beispielsweise rpcbind auf Port 111 sowie mountd, statd oder ein Lock-Manager. Werden Kerberos, LDAP oder andere Infrastrukturdienste genutzt, müssen deren Ports zusätzlich berücksichtigt werden.
sec=sys verwendet das klassische AUTH_SYS-Modell mit UID und GID.
krb5 authentifiziert Benutzer über Kerberos. krb5i ergänzt einen Integritätsschutz
für die Kommunikation, während krb5p zusätzlich die übertragenen RPC-Nutzdaten verschlüsselt.
root_squash verhindert, dass der Benutzer root eines NFS-Clients
automatisch mit root-Rechten auf dem NFS-Server arbeitet. Die Client-UID 0 wird stattdessen auf einen
weniger privilegierten Benutzer abgebildet. Das ist ein wichtiger Schutz gegen zu weitreichende Rechte von NFS-Clients.
Ein NFS-Export ist ein Verzeichnis oder Dateisystem, das ein NFS-Server für definierte Clients oder Netze freigibt. Exports sollten nach Anwendungszweck getrennt werden, beispielsweise für VM-Datastores, Applikationsdaten, Benutzerverzeichnisse oder Backup. Dadurch lassen sich Berechtigungen, Quotas, Performance und Wartung gezielter steuern.
pNFS ist Bestandteil von NFSv4.1 und kann Datenzugriffe auf mehrere Data Server beziehungsweise Storage-Pfade verteilen. Multipathing bezeichnet allgemein die Nutzung mehrerer Netzwerkpfade zu einem NFS-Datastore oder Export und ist plattformabhängig. nConnect verwendet mehrere TCP-Verbindungen zwischen Client und NFS-Server, um Parallelität und Ressourcennutzung zu verbessern. Die Funktionen sind verwandt, aber technisch nicht identisch.
Entscheidend sind Netzwerkbandbreite und Latenz, das Storage-Backend, CPU-Ressourcen, das I/O-Profil und die Parallelisierung. Viele kleine Dateien erzeugen vor allem Metadatenlast, große Dateien benötigen hohen sequenziellen Durchsatz. Moderne NFS-Implementierungen können auch 25, 40 oder 100 Gbit/s nutzen; NFS ist nicht grundsätzlich auf die Leistung einer einzelnen 10-Gbit/s-Verbindung begrenzt.
Ja. VMware ESXi kann NFS direkt als Shared Datastore verwenden. NFSv3 und NFSv4.1 sind dabei gebräuchliche Varianten. NFSv4.1 kann abhängig von Plattform und Storage-System mehrere Pfade nutzen; neuere Umgebungen können zusätzlich mehrere TCP-Verbindungen einsetzen. Welche Variante sinnvoll ist, hängt von ESXi-Version, Storage-System, Netzwerkdesign und Funktionsanforderungen ab.
NFS stellt Dateien und Verzeichnisse bereit; das Dateisystem wird auf dem NFS-Server verwaltet. Block-Storage stellt dem Host dagegen virtuelle Laufwerke beziehungsweise Blöcke bereit, auf denen der Host selbst ein Dateisystem betreibt. NFS ist häufig besonders einfach für Shared File-Services und Datastores, während Block-Storage für bestimmte Datenbanken, Cluster-Dateisysteme oder Spezialanwendungen Vorteile bieten kann.
Hochverfügbarkeit kann durch redundante Storage-Controller, Cluster- beziehungsweise Failover-Dateiserver und redundante Netzwerkpfade erreicht werden. Wichtig sind konsistente Export-Konfigurationen, getestete Failover-Zeiten und ein Client-Verhalten, das kurze Unterbrechungen zuverlässig übersteht. Failover sollte deshalb unter realer Last getestet werden.
