Nfs3 Server Grundlagen: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „=NFS Server Version 3= ==Allgemeines== NFS (Network File System) ist ein Protokoll, mit dem ein Server Verzeichnisse über das Netz freigibt, die Clients wie…“)
 
 
Zeile 2: Zeile 2:
  
 
==Allgemeines==
 
==Allgemeines==
−
NFS (Network File System) ist ein Protokoll, mit dem ein Server Verzeichnisse über das Netz freigibt, die Clients wie ein lokales Dateisystem einhängen. Es stammt ursprünglich von Sun Microsystems und ist im Unix-/Linux-Umfeld der Standard für Dateifreigaben.
+
NFS (Network File System) ist ein Protokoll, mit dem ein Server Verzeichnisse über das Netz freigibt. Clients hängen diese Freigaben ein und arbeiten damit wie mit einem lokalen Dateisystem. NFS wurde ursprünglich von Sun Microsystems entwickelt und ist im Unix- und Linux-Umfeld der Standard für Dateifreigaben.
  
−
NFS Version 3 (RFC 1813, 1995) ist trotz NFSv4 weiterhin weit verbreitet, z.B. als Storage für Virtualisierungsplattformen wie Proxmox VE oder VMware, und auf vielen NAS-Systemen.
+
NFS Version 3 wurde 1995 veröffentlicht (RFC 1813). Obwohl es mit NFSv4 längst einen Nachfolger gibt, ist Version 3 weiterhin weit verbreitet, vor allem als Storage für Virtualisierungsplattformen wie Proxmox VE oder VMware und auf vielen NAS-Systemen. Gründe dafür sind die einfache Einrichtung, die hohe Robustheit und die breite Unterstützung.
  
−
==Eigenschaften von NFSv3==
+
==Eigenschaften==
−
* '''Zustandslos''' - der Server merkt sich nicht, welche Clients welche Dateien geöffnet haben. Fällt der Server aus und startet neu, machen die Clients einfach weiter.
+
* '''Zustandslos''' - der Server merkt sich nicht, welche Clients welche Dateien geöffnet haben. Jede Anfrage enthält alle nötigen Informationen. Startet der Server neu, arbeiten die Clients einfach weiter, als wäre nichts gewesen.
−
* '''Basiert auf RPC''' (Remote Procedure Call) - die Funktionen sind auf mehrere Dienste verteilt, die teilweise dynamische Ports benutzen.
+
* '''Basiert auf RPC''' - NFS nutzt Remote Procedure Calls. Die Funktionen sind auf mehrere einzelne Dienste verteilt.
−
* '''Locking ist ausgelagert''' - Dateisperren laufen über ein eigenes Protokoll (NLM, Network Lock Manager) und nicht über NFS selbst.
+
* '''Locking ist ausgelagert''' - Dateisperren sind nicht Teil von NFSv3, sondern laufen über ein eigenes Protokoll, den Network Lock Manager.
−
* '''TCP und UDP''' - beides möglich, heute wird praktisch nur noch TCP verwendet.
+
* '''TCP und UDP''' - beide Transportprotokolle sind möglich, heute wird praktisch nur noch TCP verwendet.
−
* '''Authentifizierung über UID/GID''' (AUTH_SYS) - der Server vertraut den Benutzer- und Gruppennummern, die der Client mitschickt. Es gibt keine echte Benutzeranmeldung.
+
* '''Authentifizierung über Benutzer- und Gruppennummern''' - der Server vertraut den UID- und GID-Werten, die der Client mitschickt. Eine echte Anmeldung von Benutzern gibt es nicht.
−
* '''64-Bit-Dateigrößen''' und asynchrone Schreibvorgänge mit COMMIT - das waren die großen Neuerungen gegenüber NFSv2.
+
* '''Große Dateien und asynchrones Schreiben''' - gegenüber NFSv2 brachte Version 3 64-Bit-Dateigrößen und die Möglichkeit, Schreibvorgänge zu puffern und später gesammelt zu bestätigen.
  
 
==Beteiligte Dienste==
 
==Beteiligte Dienste==
 +
Ein NFSv3-Server besteht aus mehreren Diensten, die zusammenarbeiten:
 +
 
{| class="wikitable"
 
{| class="wikitable"
−
! Dienst !! Port !! Aufgabe
+
! Dienst !! Aufgabe
 
|-
 
|-
−
| rpcbind (portmapper) || 111 tcp/udp || Vermittelt, welcher RPC-Dienst auf welchem Port läuft
+
| rpcbind (Portmapper) || Läuft auf dem festen Port 111 und teilt Clients mit, auf welchem Port welcher RPC-Dienst erreichbar ist
 
|-
 
|-
−
| nfsd || 2049 tcp/udp || Der eigentliche NFS-Dienst (Lesen, Schreiben, Verzeichnisse)
+
| nfsd || Der eigentliche NFS-Dienst auf Port 2049, zuständig für Lesen, Schreiben und Verzeichniszugriffe
 
|-
 
|-
−
| mountd || dynamisch || Nimmt Mount-Anfragen entgegen und prüft die Exports
+
| mountd || Nimmt Mount-Anfragen entgegen und prüft, ob der Client die Freigabe nutzen darf
 
|-
 
|-
−
| lockd (NLM) || dynamisch || Dateisperren
+
| lockd || Verwaltet Dateisperren (Network Lock Manager)
 
|-
 
|-
−
| statd (NSM) || dynamisch || Benachrichtigt nach einem Neustart, damit Sperren wiederhergestellt werden
+
| statd || Benachrichtigt Server und Clients nach einem Neustart, damit Sperren wiederhergestellt oder freigegeben werden
 
|-
 
|-
−
| rquotad || dynamisch || Quota-Abfragen (optional)
+
| rquotad || Liefert Quota-Informationen an die Clients (optional)
 
|}
 
|}
  
−
Ablauf beim Einhängen:
+
Bis auf rpcbind und nfsd benutzen diese Dienste standardmäßig wechselnde Ports. Das macht NFSv3 hinter einer Firewall unhandlich. In der Praxis legt man die Ports deshalb fest.
−
# Der Client fragt rpcbind auf Port 111, wo mountd läuft.
 
−
# Der Client fragt mountd nach dem Export und bekommt ein Filehandle.
 
−
# Mit diesem Filehandle spricht der Client nfsd auf Port 2049 an.
 
  
−
==Unterschiede zu NFSv4==
+
==Ablauf beim Einhängen==
−
{| class="wikitable"
+
# Der Client fragt rpcbind auf dem Server, auf welchem Port mountd läuft.
−
! Merkmal !! NFSv3 !! NFSv4
+
# Der Client meldet sich bei mountd und fordert die gewünschte Freigabe an.
−
|-
+
# mountd prüft die Berechtigung und gibt ein Filehandle für das Wurzelverzeichnis der Freigabe zurück.
−
| Zustand || zustandslos || zustandsbehaftet
+
# Ab jetzt spricht der Client direkt mit nfsd und benutzt Filehandles, um Dateien und Verzeichnisse anzusprechen.
−
|-
 
−
| Ports || 111, 2049 und mehrere dynamische || nur 2049
 
−
|-
 
−
| Locking || separat (NLM) || im Protokoll integriert
 
−
|-
 
−
| Authentifizierung || UID/GID || UID/GID oder Kerberos (krb5, krb5i, krb5p)
 
−
|-
 
−
| Benutzerzuordnung || numerisch || über Namen (user@domain, idmapd)
 
−
|-
 
−
| Firewall || aufwendig || einfach
 
−
|-
 
−
| Namensraum || jeder Export einzeln || Pseudo-Dateisystem mit gemeinsamer Wurzel
 
−
|}
 
  
−
==Installation==
+
==Filehandles==
−
===Debian===
+
Ein NFS-Client spricht Dateien nicht über Pfade an, sondern über Filehandles. Ein Filehandle ist eine Kennung, die im Wesentlichen das Dateisystem und die Inode-Nummer der Datei enthält. Der Server sieht bei einer Anfrage also nicht den Pfad, sondern nur, welche Inode auf welchem Dateisystem gemeint ist.
−
apt install nfs-kernel-server
 
−
systemctl enable --now nfs-server
 
  
−
===Rocky Linux===
+
Daraus ergibt sich eine Besonderheit: Wird nur ein Unterverzeichnis eines Dateisystems freigegeben, liegen auf demselben Dateisystem auch Dateien außerhalb der Freigabe. Mit der Option ''subtree_check'' prüft der Server bei jedem Zugriff, ob die Datei tatsächlich innerhalb der Freigabe liegt. Diese Prüfung kostet Leistung und führt zu Fehlern, wenn geöffnete Dateien umbenannt oder verschoben werden. Heute ist deshalb ''no_subtree_check'' der Standard. Die saubere Lösung ist, für jede Freigabe ein eigenes Dateisystem zu verwenden.
−
dnf install nfs-utils
 
−
systemctl enable --now nfs-server
 
  
−
==Freigaben definieren==
+
==Freigaben==
−
Die Freigaben stehen in der Datei ''/etc/exports''. Jede Zeile enthält ein Verzeichnis, gefolgt von den berechtigten Clients mit ihren Optionen in Klammern.
+
Welche Verzeichnisse freigegeben werden, ist auf dem Server in der Datei ''/etc/exports'' festgelegt. Für jedes Verzeichnis wird angegeben, welche Rechner oder Netze darauf zugreifen dürfen und mit welchen Optionen.
  
−
mkdir -p /srv/nfs/daten
+
Wichtige Optionen sind:
−
vi /etc/exports
+
* '''rw / ro''' - Lesen und Schreiben oder nur Lesen.
 +
* '''sync / async''' - bei sync bestätigt der Server einen Schreibvorgang erst, wenn die Daten auf der Platte sind. async ist schneller, kann aber bei einem Absturz zu Datenverlust führen.
 +
* '''root_squash''' - der Benutzer root auf dem Client wird auf dem Server zum unprivilegierten Benutzer nobody. Das ist der Standard.
 +
* '''no_root_squash''' - root auf dem Client bleibt root auf dem Server. Wird z.B. für Hypervisor-Storage benötigt.
 +
* '''all_squash''' - alle Benutzer des Clients werden auf einen anonymen Benutzer abgebildet.
 +
* '''no_subtree_check''' - keine Prüfung, ob eine Datei innerhalb der Freigabe liegt.
  
−
/srv/nfs/daten  192.168.10.0/24(rw,sync,no_subtree_check)
+
==Benutzer und Rechte==
−
/srv/nfs/iso    192.168.10.0/24(ro,sync,no_subtree_check)
+
NFSv3 überträgt Benutzer und Gruppen nur als Nummern. Der Server prüft die Dateirechte anhand dieser Nummern. Damit die Rechte stimmen, müssen UID und GID eines Benutzers auf Client und Server gleich sein. In größeren Umgebungen sorgt dafür eine zentrale Benutzerverwaltung, z.B. über LDAP.
  
−
'''Wichtig:''' Zwischen Client und Klammer darf kein Leerzeichen stehen. ''192.168.10.0/24 (rw)'' bedeutet etwas völlig anderes: Das Netz bekommt Standardrechte und '''alle''' anderen Rechner bekommen rw.
+
==Mount-Verhalten auf dem Client==
 +
Der Client kann eine Freigabe auf zwei Arten einhängen:
 +
* '''hard''' - ist der Server nicht erreichbar, wartet der Client unbegrenzt und wiederholt die Anfrage. Programme hängen, es gehen aber keine Daten verloren. Das ist der Standard und die richtige Wahl für Daten und VM-Images.
 +
* '''soft''' - nach einer Zeitüberschreitung gibt der Client einen Fehler an das Programm zurück. Bei Schreibzugriffen kann das zu beschädigten Dateien führen.
  
−
===Wichtige Optionen===
+
==Unterschiede zu NFSv4==
 
{| class="wikitable"
 
{| class="wikitable"
−
! Option !! Bedeutung
+
! Merkmal !! NFSv3 !! NFSv4
 
|-
 
|-
−
| rw / ro || Lesen und Schreiben / nur Lesen
+
| Zustand || zustandslos || zustandsbehaftet
 
|-
 
|-
−
| sync || Server bestätigt Schreibvorgänge erst, wenn sie auf der Platte sind (Standard, sicher)
+
| Ports || 111, 2049 und mehrere wechselnde || nur 2049
 
|-
 
|-
−
| async || Server bestätigt sofort - schneller, aber Datenverlust bei Absturz möglich
+
| Locking || separates Protokoll || im Protokoll integriert
 
|-
 
|-
−
| root_squash || root des Clients wird auf nobody abgebildet (Standard)
+
| Authentifizierung || UID/GID || UID/GID oder Kerberos
 
|-
 
|-
−
| no_root_squash || root des Clients bleibt root auf dem Server
+
| Benutzerzuordnung || numerisch || über Namen
 
|-
 
|-
−
| all_squash || alle Benutzer werden auf nobody abgebildet
+
| Verschlüsselung || keine || mit Kerberos möglich
 
|-
 
|-
−
| anonuid / anongid || UID/GID, auf die abgebildet wird
+
| Firewall || aufwendig || einfach
−
|-
 
−
| no_subtree_check || keine Prüfung, ob die Datei im exportierten Unterbaum liegt (empfohlen)
 
 
|}
 
|}
  
−
===Exports aktivieren und prüfen===
+
==Einsatz als Storage für Proxmox VE==
−
exportfs -ra
+
Proxmox VE kann NFS-Freigaben als gemeinsamen Speicher für alle Knoten eines Clusters nutzen. Darauf lassen sich VM-Images, ISO-Dateien, Container-Vorlagen und Backups ablegen. Weil alle Knoten auf dieselben Images zugreifen, ist eine Live-Migration von VMs ohne Kopieren der Festplatten möglich.
−
exportfs -v
 
−
 
 
−
==NFS auf Version 3 festlegen==
 
−
In ''/etc/nfs.conf'' kann der Server auf bestimmte Versionen beschränkt werden:
 
−
 
 
−
[nfsd]
 
−
vers3=y
 
−
vers4=n
 
−
 
 
−
systemctl restart nfs-server
 
−
 
 
−
Ohne diese Einstellung bietet der Server v3 und v4 gleichzeitig an, der Client handelt dann die höchste Version aus.
 
  
−
==Feste Ports für die Firewall==
+
Da Proxmox die Images als root anlegt und bearbeitet, wird die Freigabe in der Regel mit no_root_squash eingerichtet. Die NFS-Version lässt sich beim Einbinden in Proxmox festlegen.
−
Weil mountd, statd und lockd standardmäßig dynamische Ports benutzen, ist NFSv3 hinter einer Firewall unhandlich. Die Ports lassen sich in ''/etc/nfs.conf'' festlegen:
 
−
 
 
−
[mountd]
 
−
port=20048
 
−
 
−
[statd]
 
−
port=32765
 
−
outgoing-port=32766
 
−
 
−
[lockd]
 
−
port=32768
 
−
udp-port=32768
 
−
 
 
−
systemctl restart nfs-server rpc-statd
 
−
 
 
−
Kontrolle:
 
−
rpcinfo -p
 
−
 
 
−
===firewalld (Rocky)===
 
−
firewall-cmd --permanent --add-service={nfs3,mountd,rpc-bind}
 
−
firewall-cmd --permanent --add-port={32765-32768/tcp,32765-32768/udp}
 
−
firewall-cmd --reload
 
−
 
 
−
===nftables (Debian)===
 
−
tcp dport { 111, 2049, 20048, 32765-32768 } ip saddr 192.168.10.0/24 accept
 
−
udp dport { 111, 2049, 20048, 32765-32768 } ip saddr 192.168.10.0/24 accept
 
−
 
 
−
==Client==
 
−
===Paket===
 
−
apt install nfs-common    # Debian
 
−
dnf install nfs-utils      # Rocky
 
−
 
 
−
===Freigaben anzeigen===
 
−
showmount -e 192.168.10.20
 
−
 
 
−
''showmount'' fragt mountd und funktioniert deshalb nur, wenn der Server NFSv3 anbietet.
 
−
 
 
−
===Manuell einhängen===
 
−
mkdir -p /mnt/daten
 
−
mount -t nfs -o vers=3 192.168.10.20:/srv/nfs/daten /mnt/daten
 
−
 
 
−
===Kontrolle===
 
−
nfsstat -m
 
−
mount | grep nfs
 
−
 
 
−
===Dauerhaft in /etc/fstab===
 
−
192.168.10.20:/srv/nfs/daten  /mnt/daten  nfs  vers=3,_netdev  0  0
 
−
 
 
−
===hard und soft===
 
−
* '''hard''' (Standard) - ist der Server weg, wartet der Client unbegrenzt. Prozesse hängen, aber es gehen keine Daten verloren.
 
−
* '''soft''' - nach einer Zeitüberschreitung gibt der Client einen Fehler zurück. Kann bei Schreibzugriffen zu kaputten Dateien führen.
 
−
Für Daten und VM-Images immer ''hard'' verwenden.
 
−
 
 
−
==NFSv3 als Storage für Proxmox VE==
 
−
Proxmox erzeugt und bearbeitet die Images als root. Mit root_squash landen die Dateien als nobody und Proxmox bekommt Rechteprobleme. Der Export für Proxmox braucht daher in der Regel no_root_squash:
 
−
 
 
−
/srv/nfs/pmx  192.168.10.0/24(rw,sync,no_subtree_check,no_root_squash)
 
−
 
 
−
Auf einem Proxmox-Knoten einbinden (gilt für den ganzen Cluster):
 
−
pvesm add nfs nfs-daten --server 192.168.10.20 --export /srv/nfs/pmx --content images,iso,backup --options vers=3
 
−
 
 
−
Alternativ in der GUI unter ''Rechenzentrum -> Storage -> Hinzufügen -> NFS'', NFS-Version unter ''Erweitert''.
 
  
 
==Sicherheit==
 
==Sicherheit==
−
* NFSv3 hat '''keine Verschlüsselung''' - alle Daten gehen im Klartext über das Netz.
+
* NFSv3 überträgt alle Daten '''unverschlüsselt'''.
−
* Die Authentifizierung beruht nur auf der IP-Adresse des Clients und den mitgeschickten UID/GID. Wer root auf einem berechtigten Client ist, kann jede UID annehmen.
+
* Der Zugriff wird nur über die IP-Adresse des Clients geregelt. Wer root auf einem berechtigten Client ist, kann jede beliebige UID annehmen und damit auf alle Dateien dieses Benutzers zugreifen.
−
* no_root_squash nur dort einsetzen, wo es nötig ist (z.B. Hypervisor-Storage), und nur für einzelne Hosts oder ein eigenes Storage-Netz freigeben.
+
* no_root_squash sollte nur dort verwendet werden, wo es nötig ist, und nur für einzelne Hosts oder ein eigenes Storage-Netz.
−
* NFS gehört in ein eigenes, abgeschottetes Netz bzw. VLAN und nie ins Internet.
+
* NFS gehört in ein eigenes, abgeschottetes Netz oder VLAN und darf nie aus dem Internet erreichbar sein.
−
* Wenn Verschlüsselung oder echte Benutzerauthentifizierung gebraucht wird: NFSv4 mit Kerberos (krb5p).
+
* Werden Verschlüsselung oder eine echte Benutzerauthentifizierung benötigt, ist NFSv4 mit Kerberos die richtige Wahl.
−
 
 
−
==Fehlersuche==
 
−
{| class="wikitable"
 
−
! Befehl !! Zweck
 
−
|-
 
−
| rpcinfo -p SERVER || welche RPC-Dienste laufen auf welchen Ports
 
−
|-
 
−
| showmount -e SERVER || welche Exports bietet der Server an
 
−
|-
 
−
| exportfs -v || aktive Exports mit allen Optionen (auf dem Server)
 
−
|-
 
−
| nfsstat -m || eingehängte NFS-Freigaben mit Optionen (auf dem Client)
 
−
|-
 
−
| journalctl -u nfs-server || Meldungen des Servers
 
−
|-
 
−
| tcpdump -n port 2049 or port 111 || Verkehr mitschneiden
 
−
|}
 
−
 
 
−
Typische Fehler:
 
−
* ''access denied by server'' - Client-IP passt nicht zum Eintrag in /etc/exports oder exportfs -ra vergessen.
 
−
* ''Permission denied'' beim Schreiben - root_squash greift oder UID/GID auf Client und Server passen nicht zusammen.
 
−
* Mount hängt - Firewall blockiert 111 oder einen der dynamischen Ports.
 
−
* ''Stale file handle'' - Export wurde auf dem Server geändert oder neu angelegt, während der Client noch eingehängt war. Client neu einhängen.
 

Aktuelle Version vom 13. Oktober 2026, 10:44 Uhr

NFS Server Version 3

Allgemeines

NFS (Network File System) ist ein Protokoll, mit dem ein Server Verzeichnisse über das Netz freigibt. Clients hängen diese Freigaben ein und arbeiten damit wie mit einem lokalen Dateisystem. NFS wurde ursprünglich von Sun Microsystems entwickelt und ist im Unix- und Linux-Umfeld der Standard für Dateifreigaben.

NFS Version 3 wurde 1995 veröffentlicht (RFC 1813). Obwohl es mit NFSv4 längst einen Nachfolger gibt, ist Version 3 weiterhin weit verbreitet, vor allem als Storage für Virtualisierungsplattformen wie Proxmox VE oder VMware und auf vielen NAS-Systemen. Gründe dafür sind die einfache Einrichtung, die hohe Robustheit und die breite Unterstützung.

Eigenschaften

  • Zustandslos - der Server merkt sich nicht, welche Clients welche Dateien geöffnet haben. Jede Anfrage enthält alle nötigen Informationen. Startet der Server neu, arbeiten die Clients einfach weiter, als wäre nichts gewesen.
  • Basiert auf RPC - NFS nutzt Remote Procedure Calls. Die Funktionen sind auf mehrere einzelne Dienste verteilt.
  • Locking ist ausgelagert - Dateisperren sind nicht Teil von NFSv3, sondern laufen über ein eigenes Protokoll, den Network Lock Manager.
  • TCP und UDP - beide Transportprotokolle sind möglich, heute wird praktisch nur noch TCP verwendet.
  • Authentifizierung über Benutzer- und Gruppennummern - der Server vertraut den UID- und GID-Werten, die der Client mitschickt. Eine echte Anmeldung von Benutzern gibt es nicht.
  • Große Dateien und asynchrones Schreiben - gegenüber NFSv2 brachte Version 3 64-Bit-Dateigrößen und die Möglichkeit, Schreibvorgänge zu puffern und später gesammelt zu bestätigen.

Beteiligte Dienste

Ein NFSv3-Server besteht aus mehreren Diensten, die zusammenarbeiten:

Dienst Aufgabe
rpcbind (Portmapper) Läuft auf dem festen Port 111 und teilt Clients mit, auf welchem Port welcher RPC-Dienst erreichbar ist
nfsd Der eigentliche NFS-Dienst auf Port 2049, zuständig für Lesen, Schreiben und Verzeichniszugriffe
mountd Nimmt Mount-Anfragen entgegen und prüft, ob der Client die Freigabe nutzen darf
lockd Verwaltet Dateisperren (Network Lock Manager)
statd Benachrichtigt Server und Clients nach einem Neustart, damit Sperren wiederhergestellt oder freigegeben werden
rquotad Liefert Quota-Informationen an die Clients (optional)

Bis auf rpcbind und nfsd benutzen diese Dienste standardmäßig wechselnde Ports. Das macht NFSv3 hinter einer Firewall unhandlich. In der Praxis legt man die Ports deshalb fest.

Ablauf beim Einhängen

  1. Der Client fragt rpcbind auf dem Server, auf welchem Port mountd läuft.
  2. Der Client meldet sich bei mountd und fordert die gewünschte Freigabe an.
  3. mountd prüft die Berechtigung und gibt ein Filehandle für das Wurzelverzeichnis der Freigabe zurück.
  4. Ab jetzt spricht der Client direkt mit nfsd und benutzt Filehandles, um Dateien und Verzeichnisse anzusprechen.

Filehandles

Ein NFS-Client spricht Dateien nicht über Pfade an, sondern über Filehandles. Ein Filehandle ist eine Kennung, die im Wesentlichen das Dateisystem und die Inode-Nummer der Datei enthält. Der Server sieht bei einer Anfrage also nicht den Pfad, sondern nur, welche Inode auf welchem Dateisystem gemeint ist.

Daraus ergibt sich eine Besonderheit: Wird nur ein Unterverzeichnis eines Dateisystems freigegeben, liegen auf demselben Dateisystem auch Dateien außerhalb der Freigabe. Mit der Option subtree_check prüft der Server bei jedem Zugriff, ob die Datei tatsächlich innerhalb der Freigabe liegt. Diese Prüfung kostet Leistung und führt zu Fehlern, wenn geöffnete Dateien umbenannt oder verschoben werden. Heute ist deshalb no_subtree_check der Standard. Die saubere Lösung ist, für jede Freigabe ein eigenes Dateisystem zu verwenden.

Freigaben

Welche Verzeichnisse freigegeben werden, ist auf dem Server in der Datei /etc/exports festgelegt. Für jedes Verzeichnis wird angegeben, welche Rechner oder Netze darauf zugreifen dürfen und mit welchen Optionen.

Wichtige Optionen sind:

  • rw / ro - Lesen und Schreiben oder nur Lesen.
  • sync / async - bei sync bestätigt der Server einen Schreibvorgang erst, wenn die Daten auf der Platte sind. async ist schneller, kann aber bei einem Absturz zu Datenverlust führen.
  • root_squash - der Benutzer root auf dem Client wird auf dem Server zum unprivilegierten Benutzer nobody. Das ist der Standard.
  • no_root_squash - root auf dem Client bleibt root auf dem Server. Wird z.B. für Hypervisor-Storage benötigt.
  • all_squash - alle Benutzer des Clients werden auf einen anonymen Benutzer abgebildet.
  • no_subtree_check - keine Prüfung, ob eine Datei innerhalb der Freigabe liegt.

Benutzer und Rechte

NFSv3 überträgt Benutzer und Gruppen nur als Nummern. Der Server prüft die Dateirechte anhand dieser Nummern. Damit die Rechte stimmen, müssen UID und GID eines Benutzers auf Client und Server gleich sein. In größeren Umgebungen sorgt dafür eine zentrale Benutzerverwaltung, z.B. über LDAP.

Mount-Verhalten auf dem Client

Der Client kann eine Freigabe auf zwei Arten einhängen:

  • hard - ist der Server nicht erreichbar, wartet der Client unbegrenzt und wiederholt die Anfrage. Programme hängen, es gehen aber keine Daten verloren. Das ist der Standard und die richtige Wahl für Daten und VM-Images.
  • soft - nach einer Zeitüberschreitung gibt der Client einen Fehler an das Programm zurück. Bei Schreibzugriffen kann das zu beschädigten Dateien führen.

Unterschiede zu NFSv4

Merkmal NFSv3 NFSv4
Zustand zustandslos zustandsbehaftet
Ports 111, 2049 und mehrere wechselnde nur 2049
Locking separates Protokoll im Protokoll integriert
Authentifizierung UID/GID UID/GID oder Kerberos
Benutzerzuordnung numerisch über Namen
Verschlüsselung keine mit Kerberos möglich
Firewall aufwendig einfach

Einsatz als Storage für Proxmox VE

Proxmox VE kann NFS-Freigaben als gemeinsamen Speicher für alle Knoten eines Clusters nutzen. Darauf lassen sich VM-Images, ISO-Dateien, Container-Vorlagen und Backups ablegen. Weil alle Knoten auf dieselben Images zugreifen, ist eine Live-Migration von VMs ohne Kopieren der Festplatten möglich.

Da Proxmox die Images als root anlegt und bearbeitet, wird die Freigabe in der Regel mit no_root_squash eingerichtet. Die NFS-Version lässt sich beim Einbinden in Proxmox festlegen.

Sicherheit

  • NFSv3 überträgt alle Daten unverschlüsselt.
  • Der Zugriff wird nur über die IP-Adresse des Clients geregelt. Wer root auf einem berechtigten Client ist, kann jede beliebige UID annehmen und damit auf alle Dateien dieses Benutzers zugreifen.
  • no_root_squash sollte nur dort verwendet werden, wo es nötig ist, und nur für einzelne Hosts oder ein eigenes Storage-Netz.
  • NFS gehört in ein eigenes, abgeschottetes Netz oder VLAN und darf nie aus dem Internet erreichbar sein.
  • Werden Verschlüsselung oder eine echte Benutzerauthentifizierung benötigt, ist NFSv4 mit Kerberos die richtige Wahl.
Abgerufen von „https://www.xinux.net/index.php?title=Nfs3_Server_Grundlagen&oldid=73647“