Kapitel 9. Netzwerk-Dateisystem (Network File System - NFS)
Mit dem Netzwerk-Dateisystem (NFS) können Dateisysteme über ein Netzwerk gemountet werden diese Dateisysteme verwenden, als wären diese lokal gemountet. Dies ermöglicht Systemadministratoren, Ressourcen auf zentralen Servern im Netzwerk zusammenzulegen.
Dieses Kapitel konzentriert sich auf fundamentale NFS-Konzepte und ergänzende Informationen. Für detaillierte Anweisungen bezüglich Konfiguration und Funktion von NFS-Servern und Client-Software siehe Kapitel Netzwerk-Dateisystem (NFS) im Red Hat Enterprise Linux Handbuch zur System-Administration.
9.1. Wie es funktioniert
Zur Zeit werden zwei Versionen von NFS verwendet. Die Version 2 von NFS (NFSv2) ist älter, wird aber von vielen Systemen unterstützt. Die NFS-Version 3 (NFSv3) verfügt über mehr Features, einschließlich einer variablen Dateigröße und einem besseren Fehlerreport, ist aber mit NFSv2-Clients nicht vollständig kompatibel. NFS Version 4 (NFSv4) beinhaltet Kerberos, arbeitet mittels Firewalls und im Internet, benötigt Portmapper nicht mehr länger, unterstützt ACLs und wendet statusbezogene Operationen an. Red Hat Enterprise Linux unterstützt NFSv2-, NFSv3- sowie auch NFSv4-Clients und wenn ein Dateisystem via NFS gemountet wird, verwendet Red Hat Enterprise Linux NFSv4 als Standard, wenn der Server es unterstützt.
Alle Versionen von NFS können das Transmission Control Protocol (TCP) verwenden, wenn es auf einem IP-Netzwerk abläuft. Dies wird von NFSv4 benötigt. NFSv2 und NFSv3 können das User Datagram Protocol (UDP) benutzen, wenn es auf einem IP-Netzwerk abläuft, um eine zustandslose Netzwerkverbindung zwischen Client und Server bereitzustellen.
Wenn Sie NFSv2 oder NFSv3 mit UDP verwenden, minimiert die statuslose UDP-Verbindung unter normalen Umständen den Netzwerkverkehr, da der NFS-Server dem Client ein Cookie sendet, nachdem der Client für den Zugriff auf die gemeinsamen Dateien authorisiert worden ist. Dieses Cookie ist ein zufälliger Wert, der im Server gespeichert ist und gemeinsam mit RPC-Anfragen vom Client übermittelt wird. Der NFS-Server kann ohne Auswirkung auf die Clients neu gestartet werden, das Cookie bleibt dabei intakt. Da aber UDP statuslos ist, bestürmen die UD- Clients das Netzwerk weiterhin mit Anfragen für den Server, auch wenn der Server unerwarteterweise herunterfährt. Deswegen ist TCP das bevorzugte Protokoll beim Verbinden mit einem NFS-Server.
Mit NFSv4 erhalten Sie eine 'stateful' Verbindung und eine optionale Kerberos Benutzer- und Gruppen-Authentifizierung mit verschiedenen Sicherheitsstufen. NFSv4 interagiert nicht mit Portmapper, rpc.mountd, rpc.lockd und rpc.statd, das diese in den Kernel eingespeichert worden sind. NFSv4 horcht den bekannten TCP-Port 2049 ab.
 | Anmerkung |
|---|---|
TCP ist das standardmäßige Transport-Protokoll für NFS unter Red Hat Enterprise Linux. Siehe Kapitel Network File System (NFS) im Red Hat Enterprise Linux Handbuch zur System-Administration für weitere Informationen über Verbindung zum Server mittels TCP. UDP kann je nach Bedarf für Kompatibilitätszwecke eingesetzt werden, wird jedoch desweiteren nicht empfohlen. |
NFS führt Authentifizierungen nur dann durch, wenn ein Client versucht, die gemeinsame NFS-Ressource zu mounten. Um Zugriffe auf den NFS-Server zu limitieren werden TCP-Wrapper verwendet. Die TCP-Wrapper lesen die Dateien /etc/hosts.allow und /etc/hosts.deny, um festzulegen, ob einem bestimmten Client oder einem Netzwerk der Zugriff auf den NFS-Server erlaubt oder verwehrt wird. Weitere Informationen zum Konfigurieren der Zugriffssteuerung mit TCP-Wrapper finden Sie unter Kapitel 17.
Erhält der Client die Berechtigung, die TCP-Wrapper zu passieren, verweist der NFS-Server auf die Konfigurationsdatei /etc/exports, um festzulegen, ob der Client über ausreichende Privilegien zum Zugreifen auf eine der exportierten Dateisysteme verfügt. Wird der Zutritt gewährt, kann der User über alle Datei- und Verzeichnisvorgänge verfügen.
 | Warnung |
|---|---|
NFS-Mount-Privilegien werden dem Client Host gewährt, nicht dem Benutzer, wenn Sie NFSv2 oder v3 benutzen, welche Kerberos Authenfifizierung nicht unterstützen. Deswegen kann jeder Benutzer auf einem Client Host mit Zugangsberechtigung auf die exportierten Dateisysteme zugreifen. Wenn Sie die gemeinsamen NFS- Dateien konfigurieren, seien Sie vorsichtig, welche Hosts eine Lese- und Schreibberechtigung erhalten (rw). |
 | Wichtig |
|---|---|
Sodass NFS mit einer Standardinstallation von Red Hat Enterprise Linux und einer aktivierten Firewall einwandfrei funktioniert, muss IPTables mit dem Standard-TCP-Port 2049 konfiguriert sein. Ohne IPTables Konfiguration, kann NFS nicht ordentlich funktionieren. Das NFS-Initialisierungsskript und der rpc.nfsd-Prozess ermöglichen nunmehr Bindungen zu jedem festgelegten Port während das System hochstartet. Dies kann jedoch sehr fehleranfällig sein, im Falle von Konflikten mit einem anderen Daemon oder dass ein Port nicht zur Verfügung steht. |
9.1.1. Erforderliche Dienste
Red Hat Enterprise Linux verwendet für das NFS Datei-Sharing eine Kombination aus dem Kernel-Level-Support und den Daemon-Prozessen. NFS verlässt sich auf Remote Procedure Calls (RPC), um Anfragen zwischen Clients und Servern zu routen. Bei Linux werden RPC-Dienste durch den portmap Dienst gesteuert. Beim gemeinsamen Verwenden oder mounten von NFS-Dateisystemen arbeiten folgende Dienste zusammen (abhängig von der verwendeten Version):
nfs — Startet die passenden RPC-Prozesse, um Anfragen für gemeinsame NFS-Dateisysteme zu handhaben.
nfslock — ein fakultativer Dienst, der die passenden RPC-Prozesse startet, damit NFS-Clients Dateien auf dem Server festmachen können.
portmap — Der RPC-Dienst für Linux; er reagiert auf Anfragen für RPC-Dienste und und baut Verbindungen zu den erfragten RPC-Diensten auf. Wird nicht mit NFSv4 verwendet.
Die folgenden RPC-Prozesse arbeiten im Hintergrund zusammen, um die NFS-Dienste zu unterstützen:
rpc.mountd — Dieser Prozess empfängt die Mount-Anfrage der NFS-Clients und kontrolliert, ob das erfragte Dateisystem zu diesem Zeitpunkt exportiert ist. Der Prozess wird automatisch durch den nfs Dienst gestartet und erfordert keine Benutzer- Konfiguration. Findet keine Verwendung in Zusammenhang mit NFSv4.
rpc.nfsd — Dieser Prozess ist der NFS-Server. Er arbeitet mit dem Linux-Kernel, um mit den dynamischen Vorgaben des NFS-Clients übereinzustimmen. Zum Beispiel das Bereitstellen zusätzlicher Server-Threads, immer wenn sich ein NFS-Client verbindet. Dieser Prozess korrespondiert mit dem nfs Dienst.
rpc.lockd — Ein fakultativer Prozess, der NFS-Clients erlaubt, Dateien am Server festzumachen. Dieser Prozess korrespondiert mit demnfslock Dienst. Findet keine Verwendung in Zusammenhang mit NFSv4.
rpc.statd — Implementiert das Network Status Monitor (NSM)-RPC- Protokoll. Dies verständigt NFS-Clients, wenn ein NFS-Server neu gestartet wird, ohne dass er ordentlich heruntergefahren wurde. Dieser Prozess wird automatisch durch den nfslock Dienst gestartet und erfordert keine Benutzer-Konfiguration. Findet keine Verwendung in Zusammenhang mit NFSv4.
rpc.rquotad — Dieser Prozess stellt Information über Benutzerquoten für Remote-Benutzer zur Verfügung. Der Prozess wird automatisch durch den nfs Dienst gestartet und erfordert keine Benutzer-Konfiguration.
rpc.idmapd — Dieser Prozess bietet NFSv4 Client- und Server-Upcalls, welche zwischen on-the-wire NFSv4 Namen (Strings in Form von user@domain) und lokalen UIDs und GIDs mappen. Sodass idmapd mit NFSv4 funktioniert, muss /etc/idmapd.conf konfiguriert sein. Ist nicht erforderlich in Zusammenhang mit NFSv4.
rpc.svcgssd — Dieser Prozess bietet den Server-Transportmechnanismus für den Authentifizierungsprozess (Kerberos Version 5) mit NFSv4. Dieser Service ist für die Benutzung mit NFSv4 erforderlich.
rpc.gssd — Dieser Prozess bietet den Client-Transportmechnanismus für den Authentifizierungsprozess (Kerberos Version 5) mit NFSv4. Dieser Service ist für die Benutzung mit NFSv4 erforderlich.
9.1.2. NFS und portmap
| Anmerkung |
|---|---|
Der folgende Abschnitt trifft nur auf NFSv2- oder NFSv3-Implementationen zu, welche den portmap-Dienst aus Kompatibilitätsgründen benötigen. |
Der portmap Dienst von Linux wird benötigt, um die RPC-Anfragen den korrekten Diensten zuzuordnen. portmap wird von den RPC-Prozessen benachrichtigt, wenn sie starten. Des Weiteren teilen die Anfragen die überwachte Port-Nummer sowie die Nummern des RPS-Programms mit, die aufgerufen werden. Der Client kontaktiert portmap auf dem Server mit einer bestimmten RPC-Programmnummer. Der portmap Dienst leitet dann den Client zur richtigen Port-Nummer um, damit er mit dem gewünschten Dienst kommunizieren kann.
Da auf RPC-basierte Dienste sich auf portmap verlassen, alle Verbindungen mit eingehenden Client-Anfragen herzustellen, muss portmap verfügbar sein, bevor irgendeiner dieser Dienste startet.
Der portmap-Dienst verwendet TCP-Wrapper für die Zugriffskontrolle, die Zugriffs-Kontrollregeln für portmap beeinflussen alle auf RPC basierenden Dienste. Als Alternative können Sie auch Zugriffs-Kontrollregeln für jeden der NFS-RPC-Daemonen einzeln bestimmen. Die man-Seiten für rpc.mountd und rpc.statd enthalten Informationen über die genaue Syntax dieser Regeln.
9.1.2.1. Probemlösungen bei NFS mit portmap
Da portmap die Koordination zwischen RPC- Diensten und den Port-Nummern übernimmt, die für die Kommunikation mit den Diensten verwendet werden, ist es sehr hilfreich, eine Übersicht über die aktuellen RPC- Dienste zu haben, die portmap verwenden. Der Befehl rpcinfo zeigt jeden auf RPC-basierenden Dienst mit Port-Nummern, RPC-Programmnummer, Version und dem Typ des IP- Protokolls (TCP oder UDP) an.
Um sicherzustellen, dass die richtigen NFS-RPC-basierten Dienste für portmap aktiviert sind, geben Sie den folgenden Befehl als Root ein:
rpcinfo -p |
Im folgenden ein Probe-Output dieses Befehls:
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100021 1 udp 32774 nlockmgr
100021 3 udp 32774 nlockmgr
100021 4 udp 32774 nlockmgr
100021 1 tcp 34437 nlockmgr
100021 3 tcp 34437 nlockmgr
100021 4 tcp 34437 nlockmgr
100011 1 udp 819 rquotad
100011 2 udp 819 rquotad
100011 1 tcp 822 rquotad
100011 2 tcp 822 rquotad
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100005 1 udp 836 mountd
100005 1 tcp 839 mountd
100005 2 udp 836 mountd
100005 2 tcp 839 mountd
100005 3 udp 836 mountd
100005 3 tcp 839 mountd |
Im oben aufgeführten Output wird angezeigt, dass die richtigen NFS-Dienste ablaufen. Wenn einer der NFS-Dienste nicht korrekt startet, kann portmap die RPC-Anfragen von Clients für diesen Dienst nicht dem richtigen Port zuordnen. Wenn NFS im rpcinfo Output nicht vorhanden ist, führt in vielen Fällen das Neustarten von NFS dazu, dass der Dienst korrekt in portmap registriert werden und arbeiten kann. Anweisungen für das Starten von NFS finden Sie unter Abschnitt 9.2.
Andere hilfreiche Optionen sind für den rpcinfo Befehl vorhanden. Siehe rpcinfo man Seite für weitere Informationen.