Manpages

BEZEICHNUNG

nfs - Format und Optionen in der fstab-Datei für das nfs-Dateisystem

ÜBERSICHT

/etc/fstab

BESCHREIBUNG

NFS ist ein von Sun Microsystems 1984 entwickeltes Internet Standardprotokoll. Es wurde zum Dateiaustausch zwischen Systemen im lokalen Netz entwickelt. Der Linux-NFS-Client unterstützt drei Versionen des NFS-Protokolls: NFS-Version 2 [RFC1094], NFS Version 3 [RFC1813] und NFS Version 4 [RFC3530].

Der Befehl mount(8) fügt ein Dateisystem an einem angegebenen Einhängepunkt zu der Namensraumhierarchie des Systems hinzu. Die Datei /etc/fstab beschreibt, wie mount(8) die Dateinamenshierarchie des Systems aus verschiedenen unabhängigen Dateisystemen (darunter von NFS-Servern exportierten) zusammenbauen soll. Jede Zeile in der Datei /etc/fstab beschreibt ein einzelnes Dateisystem, seinen Einhängepunkt und eine Menge an Standardeinhängeoptionen für diesen Einhängepunkt.

Für NFS-Dateisystemeinhängungen gibt eine Zeile in der Datei /etc/fstab folgende Informationen an: den Servernamen, den Pfadnamen des exportierten und einzuhängenden Server-Verzeichnisses, das als Einhängepunkt dienende lokale Verzeichnis und eine Liste von Einhängeoptionen, die die Art des Einhängens und die Reaktion des NFS-Clients beim Zugriff auf Dateien unterhalb dieses Einhängepunktes steuern. Das fünfte und sechste Feld auf jeder Zeile wird von NFS nicht verwandt und enthält per Konvention jeweils die Ziffer Null. Beispiel:

Option,Option,…t0 0

Der Rechnername und die exportierten Pfadnamen werden durch einen Doppelpunkt getrennt, während die Einhängeoptionen durch Kommata getrennt werden. Die verbleibenden Felder werden durch Leerzeichen oder Tabulatoren getrennt.

Der Rechnername des Servers kann unqualifiziert, ein voll qualifizierter Domain-Name, eine mit Punkten versehene, vierteilige IPv4-Adresse oder eine in eckige Klammern eingeschlossene IPv6-Adresse sein. Link-local- und Site-local-IPv6-Adressen müssen von einem Schnittstellenidentifikator begleitet werden. Siehe ipv6(7) für Details zur Angabe von rohen IPv6-Adressen.

Das Feld fstype enthält »nfs«. Die Verwendung des Dateityps »nfs4« in /etc/fstab wird missbilligt.

EINHÄNGEOPTIONEN

Schauen Sie in mount(8) für eine Beschreibung der generischen Einhängeoptionen, die für alle Dateisysteme verfügbar sind. Falls Sie keine Einhängeoption angeben müssen, verwenden Sie die generische Option defaults in /etc/fstab.

Optionen, die von allen Versionen unterstützt werden
Diese Optionen sind für die Verwendung mit allen NFS-Versionen gültig.

Nebenbemerkung: Eine sogenannte »weiche« Zeitüberschreitung kann in bestimmten Fällen zu stiller Datenverfälschung führen. Verwenden Sie daher die Option soft nur, wenn die Reaktionsfähigkeit des Clients wichtiger als die Datenintegrität ist. Die Verwendung von NFS über TCP oder die Erhöhung des Wertes der Option retrans kann einige der Risiken des Einsatzes der Option soft verringern.

Für NFS über TCP beträgt der Standardwert für timeo 600 (60 Sekunden). Der NFS-Client führt einen linearen Rückschritt aus: Nach jeder Neuübertragung wird die Zeitüberschreitung um timeo bis zum Maximum von 600 Sekunden erhöht.

Für NFS über UDP verwendet der Client einen adaptiven Algorithmus, um die angemessenen Werte für eine Zeitüberschreitung (Timeput) für häufig verwandte Anfragetypen (wie READ- und WRITE-Anfragen) abzuschätzen, verwendet allerdings die Einstellung timeo für seltenere Anfragetypen (wie FSINFO-Anfragen). Falls die Option timeo nicht angegeben ist, werden solche selten verwandten Anfragetypen nach 1,1 Sekunden erneut versucht. Nach jeder Neuübertragung verdoppelt der NFS-Client die Zeitüberschreitung für diese Anfrage bis zu einem maximalen Wert für die Zeitüberschreitung von 60 Sekunden.

Der NFS-Client erzeugt »server not responding« (Server reagiert nicht) Nachrichten nach retrans Versuchen. Dann versucht er weitere Wiederherstellungen (abhängig davon, ob die Einhängeoption hard in Kraft ist).

Der Wert von rsize ist ein positives, ganzzahliges Vielfaches von 1024. Werte von rsize kleiner als 1024 werden durch 4096 ersetzt; Werte größer als 1048576 durch 1048576. Falls ein angegebener Wert in den unterstützten Bereich fällt, aber kein Vielfaches von 1024 ist, wird er auf das nächste Vielfache von 1024 abgerundet.

Falls der Wert rsize nicht angegeben ist oder falls der angegebene Wert für rsize größer als das maximale sowohl vom Server oder vom Client unterstützte ist, handeln der Client und der Server den größten Wert für rsize aus, den beide unterstützen.

Die Einhängeoption rsize taucht in der Datei /etc/mtab so auf, wie sie auf der mount(8)-Befehlszeile angegeben wurde. Der effektive zwischen Server und Client ausgehandelte Wert von rsize wird allerdings in der Datei /proc/mounts angezeigt.

Ähnlich wie rsize ist der Wert von wsize ein positives, ganzzahliges Vielfaches von 1024. Werte von wsize kleiner als 1024 werden durch 4096 ersetzt; Werte größer als 1048576 durch 1048576. Falls ein angegebener Wert in den unterstützten Bereich fällt, aber kein Vielfaches von 1024 ist, wird er auf das nächste Vielfache von 1024 abgerundet.

Falls ein Wert von wsize nicht angegeben ist oder der angegebene Wert von wsize größer als das maximal vom Client oder Server unterstützbare ist, werden der Client und Server den größten Wert von wsize aushandeln, den beide unterstützen können.

Die Einhängeoption wsize taucht in der Datei /etc/mtab so auf, wie sie auf der mount(8)-Befehlszeile angegeben wurde. Der effektive zwischen Server und Client ausgehandelte Wert von wsize wird allerdings in der Datei /proc/mounts angezeigt.

Um die Leistung zu erhöhen, speichern NFS-Clients Dateiattribute zwischen. Alle paar Sekunden prüft ein NFS-Client die Version des Servers von jedem Dateiattribut auf Aktualisierungen. Änderungen, die auf dem Server innerhalb dieser kurzen Intervalle passieren, bleiben unerkannt, bis der Server durch den Client erneut geprüft wird. Die Option noac verhindert, dass Clients Dateiattribute zwischenspeichern, so dass Anwendungen schneller Dateiänderungen auf dem Server erkennen können.

Zusätzlich zur Verhinderung des Zwischenspeicherns von Dateiattributen durch den Client zwingt die Option noac Anwendungen dazu, Schreibvorgänge synchron durchzuführen, so dass lokale Änderungen an einer Datei auf dem Server sofort sichtbar werden. Damit können andere Clients schnell neue Schreibvorgänge erkennen, wenn sie die Dateiattribute überprüfen.

Die Verwendung der Option noac stellt größere Kohärenz der Zwischenspeicher unter NFS-Clients, die auf die gleiche Datei zugreifen, sicher, führt aber zu einem großen Leistungseinbruch. Stattdessen wird eine gezieltere Verwendung von Dateisperren empfohlen. Der Abschnitt DATEN- UND METADATENKOHÄRENZ enthält eine detaillierte Diskussion dieses Zielkonflikts.

Falls die Option bg angegeben ist, wird eine Zeitüberschreitung oder ein Fehlschlag dazu führen, dass der Befehl mount(8) mit Fork einen Kindprozess startet, der weiter versucht, das exportierte Dateisystem einzuhängen. Der Elternprozess kommt sofort mit einem Exit-Code von Null zurück. Dies ist als »Hintergrund«-Einhängung bekannt.

Falls das lokale Einhängeverzeichnis fehlt, verhält sich der Befehl mount(8), als ob eine Zeitüberschreitung aufgetreten wäre. Dies erlaubt in /etc/fstab angegebene verschachtelte NFS-Einhängungen in beliebiger Reihenfolge während des Systemstarts fortzufahren, selbst falls einige NFS-Server noch nicht verfügbar sind. Alternativ können diese Probleme mit einem Selbsteinhängeprogramm angegangen werden (siehe automount(8) für Details).

rdirplus/nordirplus

Wählt aus, ob NFS-v3- oder -v4-READDIRPLUS-Anfragen verwandt werden sollen. Falls diese Option nicht angegeben ist, verwendet der NFS-Client READDIRPLUS-Anfragen auf NFS-v3- oder -v4-Einhängungen, um kleine Verzeichnisse zu lesen. Einige Anwendungen arbeiten besser, falls der Client nur READDIR-Anfragen für alle Verzeichnisse verwendet.

Beachten Sie, dass dies nur die Anzahl der durchgeführten Versuche beeinflusst, nicht die durch jeden Versuch hervorgerufene Verzögerung. Für UDP benötigt jeder Versuch die durch die Optionen timeo und retrans bestimmte Zeit, die standardmäßig 7 Sekunden ist. Für TCP ist die Vorgabe 3 Minuten, aber System-TCP-Verbindungszeitüberschreitungen begrenzen manchmal die Zeitüberschreitung für jede Neuübertragung auf rund 2 Minuten.

sharecache/nosharecache

Bestimmt, wie die Daten- und Attributszwischenspeicher des Clients gemeinsam benutzt werden, wenn die exportierten Verzeichnisse gleichzeitig mehr als einmal eingehängt werden. Die Verwendung des gleichen Zwischenspeichers reduziert die Speicheranforderungen auf dem Client und präsentiert Anwendungen identische Dateiinhalte, wenn auf die gleiche Datei aus der Ferne über verschiedene Einhängepunkte aus zugegriffen wird.

Falls keine der Optionen oder falls die Option sharecache angegeben ist, wird ein einzelner Zwischenspeicher für alle Einhängepunkte, die auf den gleichen Export zugreifen, verwandt. Falls die Option nosharecache angegeben ist, dann bekommt dieser Einhängepunkt einen separaten Zwischenspeicher. Beachten Sie, dass die Einhängeoptionen von dem ersten Einhängepunkt auch für folgende gleichzeitige Einhängungen auf dem gleichen Export verwendet werden, falls die Daten- und Attributzwischenspeicher gemeinsam benutzt werden.

Ab Kernel 2.6.18 ist das mit nosharecache angegebene Verhalten veraltet. Es wird als Datenrisiko betrachtet, da mehrere zwischengespeicherte Kopien der gleichen Datei auf dem gleichen Client nach einer lokalen Aktualisierung einer der Kopien auseinanderlaufen können.

resvport/noresvport

Legt fest, ob der NFS-Client einen privilegierten Quell-Port für die Kommunikation mit dem NFS-Server für diesen Einhängepunkt verwenden soll. Falls diese Option nicht oder die Option resvport angegeben ist, verwendet der NFS-Client einen privilegierten Quell-Port. Falls die Option noresvport angegeben ist, verwendet der NFS-Client einen nichtprivilegierten Port. Diese Option wird durch Kernel 2.6.28 und neuer unterstützt.

Die Verwendung von nichtprivilegierten Quell-Ports hilft bei der Erhöhung der auf dem Client maximal erlaubten Anzahl an NFS-Einhängepunkten. Allerdings muss der NFS-Server so konfiguriert sein, dass er Clients erlaubt, sich über nichtprivilegierte Quell-Ports zu verbinden.

Der Abschnitt SICHERHEITSBETRACHTUNGEN enthält wichtige Details.

lookupcache=Modus

Legt fest, wie der Kernel seinen Zwischenspeicher von Verzeichniseinträgen für einen angegebenen Einhängepunkt verwaltet. Modus kann entweder all, none, pos oder positive sein. Diese Option wird durch Kernel 2.6.28 und neuer unterstützt.

Der Linux-NFS-Client speichert die Ergebnisse aller »NFS LOOKUP«-Anfragen zwischen. Falls der angeforderte Verzeichniseintrag auf dem Server existiert, wird auf das Ergebnis als positive referenziert. Falls der angeforderte Verzeichniseintrag auf dem Server nicht existiert, wird auf das Ergebnis als negative referenziert.

Falls diese Option nicht oder all angegeben ist, nimmt der Client an, dass beide Arten von Verzeichniseinträgen gültig sind, bis die zwischengespeicherten Attribute des Elternverzeichnisses verfallen.

Falls pos oder positive angegeben ist, nimmt der Client an, dass positive Einträge gültig sind, bis die zwischengespeicherten Attribute des Elternverzeichnisses verfallen, überprüft aber immer negative Einträge, bevor eine Anwendung sie verwenden kann.

Falls none angegeben ist, überprüft der Client beide Arten von Verzeichniszwischenspeichereinträgen, bevor eine Anwendung sie verwenden kann. Dies ermöglicht eine schnelle Erkennung von Dateien, die von anderen Clients angelegt oder entfernt wurden, kann aber Auswirkungen auf Anwendungen und die Leistung des Servers haben.

Der Abschnitt DATEN- UND METADATENKOHÄRENZ enthält eine detaillierte Diskussion dieses Zielkonflikts.

Optionen nur für NFS-Version 2 und 3
Verwenden Sie diese Optionen, zusammen mit den Optionen in den obigen Unterabschnitten, nur für NFS Version 2 und 3.

Jedes Transportprotokoll verwendet andere Vorgaben für die Einstellungen von retrans und timeo. Lesen Sie die Beschreibungen dieser Einhängeoptionen für Details.

Diese Einhängungsoption steuert, wie der NFS-Client Anfragen an den Server überträgt und zusätzlich, wie der Befehl mount(8) auch mit den Diensten Rpcbind und Mountd des Servers kommuniziert. Wird eine Netid angegeben, die TCP verwendet, wird aller Verkehr von dem Befehl mount(8) und dem NFS-Client dazu gezwungen, TCP zu verwenden. Wird eine Netid angegeben, die UDP verwendet, werden alle Verkehrstypen zur Verwendung von UDP gezwungen.

Lesen Sie den Abschnitt TRANSPORTMETHODEN unten, bevor Sie NFS über UDP verwenden.

Falls die Einhängeoption proto nicht angegeben ist, findet der Befehl mount(8) heraus, welche Protokolle der Server unterstützt und wählt für jeden Dienst ein angemessenes Protokoll. Lesen Sie den Abschnitt TRANSPORTMETHODEN für weitere Details.

Lesen Sie den Abschnitt TRANSPORTMETHODEN unten, bevor Sie NFS über UDP verwenden.

Falls diese Option nicht angegeben ist oder falls der angegebene Port-Wert 0 ist, wird der NFS-Client die vom Rpcbind-Dienst des Servers bekanntgemachte Server-Port-Nummer verwenden. Die Einhängeanfrage schlägt fehl, falls der Rpcbind-Dienst des Servers nicht verfügbar ist, der NFS-Dienst nicht beim Rpcbind-Dienst des Servers registriert ist oder falls der NFS-Dienst des Servers nicht auf dem bekanntgemachten Port des Servers verfügbar ist.

Falls diese Option nicht angegeben ist oder falls der angegebene Port-Wert 0 ist, wird der Befehl mount(8) die vom Rpcbind-Dienst des Servers bekanntgemachte Mountd-Dienstenummer verwenden. Die Einhängeanfrage schlägt fehl, falls der Rpcbind-Dienst des Servers nicht verfügbar ist, der Mountd-Dienst nicht beim Rpcbind-Dienst des Servers registriert ist oder falls der Mountd-Dienst des Servers nicht auf dem bekanntgemachten Port des Servers verfügbar ist.

Diese Option kann bei Einhängen eines NFS-Servers durch eine Firewall, die das Rpcbind-Protokoll blockiert, verwandt werden.

mountproto=netid

Den Transport, den der NFS-Client verwendet, um Anfragen an den Mountd-Dienst des Servers zu übertragen, wenn er diese Einhängeanfrage durchführt und später, wenn der diesen Einhängepunkt aushängt.

netid kann entweder udp oder tcp sein, die IPv4-Adressen verwenden, oder, falls TI-RPC im Befehl mount.nfs eingebaut ist, udp6 oder tcp6, die IPv6-Adressen verwenden.

Diese Option kann beim Einhängen eines NFS-Servers durch eine Firewall, die bestimmte Transporte blockiert, verwendet werden. Falls es in Kombination mit der Option proto verwandt wird, können verschiedene Transporte für Mountd-Anfragen und für NFS-Anfragen festgelegt werden. Falls der Mountd-Dienst des Server über den festgelegten Transport nicht verfügbar ist, schlägt die Einhängeanfrage fehl.

Lesen Sie den Abschnitt TRANSPORTMETHODEN für Informationen, wie die Einhängeoption mountproto mit der Einhängeoption proto wechselwirkt.

Einige ältere Versionen von NFS unterstützten diese Aushandlung nicht. Mittels dieser Option wird sichergestellt, dass pathconf(3) in diesen Fällen die geeignete maximale Komponentenlänge an Anwendungen meldet.

Das Sperren mit NLM muss mit der Option nolock deaktiviert sein, wenn NFS zum Einhängen von /var verwandt wird, da /var Dateien enthält, die von der NLM-Implementierung von Linux verwandt werden. Die Verwendung der Option nolock ist auch notwendig, wenn Exporte auf NFS-Servern eingehängt werden, die das NLM-Protokoll nicht unterstützen.

Der Einsatz der Option nocto kann die Leistung für rein-lesbare Einhängungen erhöhen. Er sollte aber nur verwandt werden, wenn sich die Daten auf dem Server nur gelegentlich ändern. Der Abschnitt DATEN- UND METADATENKOHÄRENZ enthält eine detailliertere Diskussion des Verhaltens dieser Option.

Falls weder die Option acl noch noacl festgelegt ist, handelt der NFS-Client mit dem Server aus, ob das NFSACL-Protokoll unterstützt wird und verwendet es, falls der Server es unterstützt. Falls die Aushandlung zu Problemen auf dem Client oder Server führt, könnte die Deaktivierung des NFSACL-Seitenbandprotokolls notwendig sein. Der Abschnitt SICHERHEITSBETRACHTUNGEN enthält weitere Details.

local_lock=Mechanismus

Legt fest, ob lokale Sperren für einen oder beide der Sperrmechanismen (Flock und POSIX) verwandt werden sollen. Mechanismus kann entweder all, flock, posix oder none sein. Diese Option wird seit Kernel 2.6.37 unterstützt.

Der Linux-NFS-Client bietet eine Möglichkeit, Sperren lokal durchzuführen. Das bedeutet, dass Anwendungen Dateien sperren können. Allerdings bieten solche Sperren nur Ausschlussrechte gegenüber anderen Anwendungen, die auf dem gleichen Client laufen. Anwendungen auf anderen Rechnern sind von diesen Sperren nicht betroffen.

Falls diese Option nicht oder falls none angegeben ist, nimmt der Client an, dass die Sperren nicht lokal sind.

Falls all angegeben ist, nimmt der Client an, dass sowohl Flock- als auch POSIX-Sperren lokal sind.

Falls flock angegeben ist, nimmt der Client an, dass nur Flock-Sperren lokal sind und verwendet das NLM-Sideband-Protokoll, wenn POSIX-Sperren verwandt werden.

Falls posix angegeben ist, nimmt der Client an, dass POSIX-Sperren lokal sind und verwendet das NLM-Sideband-Protokoll, wenn Flock-Sperren verwandt werden.

Um herkömmliches Flock-Verhalten zu unterstützen, das dem von NFS-Clients < 2.6.12 ähnlich ist, benutzen Sie »local_lock=flock«. Diese Option wird benötigt, wenn NFS-Einhängungen über Samba exportiert werden, da Samba Windows-Freigabemodusspeerren als Flock exportiert. Da NFS-Clients > 2.6.12 Flock durch Emulieren von POSIX-Sperren implementieren, wird dies zu im Konflikt stehenden Sperren führen.

Hinweis: Falls sie zusammen verwandt werden, wird die Einhängeoption »local_lock« durch die Einhängeoption »nolock«/»lock« außer Kraft gesetzt.

Optionen nur für NFS-Version 4
Verwenden Sie diese Optionen zusammen mit den Optionen in dem obigen Unterabschnitt für NFS-Version 4 oder neuer.

Alle NFS-Version-4-Server müssen TCP unterstützen. Daher verwendet der NFS-Version-4-Client das TCP-Protokoll, falls diese Option nicht angegeben ist. Lesen Sie den Abschnitt TRANSPORTMETHODEN für weitere Details.

Falls diese Einhängeoption nicht festgelegt ist, verwendet der NFS-Client die Standard-Portnummer 2049, ohne erst den Rpcbind-Dienst des Servers zu prüfen. Dies erlaubt es, einem NFS-Version-4-Client, Kontakt zu einem Server aufzunehmen, der hinter einer Firewall, die Rpcbind-Anfragen blockiert, liegt.

Falls der angegebene Port-Wert 0 ist, verwendet der NFS-Client die vom Rpcbind-Dienst des NFS-Servers bekanntgegebene Port-Nummer. Die Einhängeanfrage schlägt fehl, falls der Rpcbind-Dienst des Servers nicht verfügbar, der NFS-Dienst nicht in dem Rpcbind-Dienst registriert oder der NFS-Dienst auf dem bekanntgegebenen Port nicht verfügbar ist.

Das Zwischenspeichern von Dateidaten wird durch diese Option nicht beeinflusst. Der Abschnitt DATEN- UND METADATENKOHÄRENZ enthält eine detailliertere Beschreibung dieser Option.

clientaddr=n.n.n.n
clientaddr=n:n:…:n

Gibt eine einzelne IPv4-Adresse (in Dreipunktschreibweise) oder eine Nicht-Link-Local-IPv6-Adresse, die der NFS-Client bekanntgibt, um Servern zu erlauben, NFS-Version-4-Rückrufanfrage für Dateien auf diesem Einhängepunkt durchzuführen, an. Falls der Server keine Rückrufverbindungen zu Clients aufbauen kann, kann sich die Leistung verringern oder Dateizugriffe können zeitweise hängen.

Falls diese Option nicht festgelegt ist, versucht der Befehl mount(8) die geeigneten Rückrufadressen automatisch zu ermitteln. Dieser automatische Ermittlungsprozess ist allerdings nicht perfekt. Falls mehrere Client-Netzschnittstellen, spezielle Routing-Optionen oder atypische Netztopologien vorhanden sind, ist es möglicherweise nicht trivial, die genaue Adresse für Rückrufe zu ermitteln.

migration/nomigration

Wählt aus, ob der Client eine Identifizierungszeichenkette verwendet, die mit dem »NFSv4 Transparent State Migration (TSM)« kompatibel ist. Falls der eingehängte Server NFSv4-Migration mit TSM unterstützt, geben Sie die Option migration an.

Einige Server-Funktionalitäten funktionieren im Angesicht einer Migrations-kompatiblen Identifizierungszeichenkette nicht richtig. Die Option nomigration erhält die Verwendung einer traditionellen Client-Identifizierungszeichenkette, die mit veralteten NFS-Servern kompatibel ist. Dies ist auch das Verhalten, falls keine der Optionen festgelegt wurde. Die offenen und Sperrenstatus können nicht transparent migriert werden, wenn er sich selbst mit einer traditionellen Identifizierungszeichenkette identifiziert.

Diese Einhängeoption hat bei NFSv4-Versionen, deren Unternummer größer als Null ist, keinen Effekt. Bei diesen wird immer eine TSM-kompatible Identifizierungszeichenkette verwandt.

NFS4-DATEISYSTEMTYP

Der Dateisystemtyp nfs4 ist eine alte Syntax für die Angabe der Verwendung von NFSv4. Er kann noch mit allen NFSv4-spezifischen und allgemeinen Optionen außer der nfsvers-Einhängeoption verwandt werden.

EINHÄNGEKONFIGURATIONSDATEI

Falls der Befehl »mount« entsprechend konfiguriert ist, können alle in den vorhergehenden Kapiteln beschriebenen Einhängeoptionen auch in der Datei /etc/nfsmount.conf konfiguriert werden. Siehe nfsmount.conf(5) für Details.

BEISPIELE

Um einen Export mit NFS-Version 2 einzuhängen, verwenden Sie den nfs-Dateisystemtyp und legen Sie die Einhängeoption nfsvers=2 fest. Um mit NFS-Version 3 einzuhängen, verwenden Sie den nfs-Dateisystemtyp und legen Sie die Einhängeoption nfsvers=3 fest. Um mit NFS-Version 4 einzuhängen, verwenden Sie entweder den nfs-Dateisystemtyp mit der Einhängeoption nfsvers=4 oder den Dateisystemtyp nfs4.

Das folgende Beispiel aus der Datei /etc/fstab führt dazu, dass der Befehl »mount« vernünftige Vorgaben für das NFS-Verhalten aushandelt.

server:/export /mnt nfs defaults 0 0

Ein Beispiel für eine Datei »/etc/fstab« für eine NFS-Version-2-Einhängung über UDP:

server:/export /mnt nfs nfsvers=2,proto=udp 0 0

Dieses Beispiel zeigt, wie NFS-Version 4 über TCP mit Kerberos 5 gegenseitiger Authentifizierung einzuhängen ist:

server:/export /mnt nfs4 sec=krb5 0 0

Dieses Beispiel zeigt, wie NFS-Version 4 über TCP mit Kerberos 5 Datenschutz- oder Datenintegritätsmodus einzuhängen ist:

server:/export /mnt nfs4 sec=krb5p:krb5i 0 0

Dieses Beispiel kann zum Einhängen von /usr über NFS verwandt werden:

server:/export /usr nfs ro,nolock,nocto,actimeo=3600 0 0

Dieses Beispiel zeigt, wie ein NFS-Server mit einer rohen IPv6-link-lokalen-Adresse eingehängt wird:

[fe80::215:c5ff:fb3e:e2b1%eth0]:/export /mnt nfs defaults 0 0

TRANSPORTMETHODEN

NFS-Clients senden Anfragen an NFS-Server mittels Remote Procedure Calls oder RPCs. Der RPC-Client ermittelt die Diensteendpunkte automatisch, kümmert sich um die Authentifizierung pro Anfrage, passt Anfrageparameter auf verschiedene Byte-Endianess auf dem Client und Server an und überträgt Anfragen erneut, die im Netz oder auf dem Server verloren gegangen sind. RPC-Anfragen und -Antworten fließen über einen Netztransport.

Meistens kann der Befehl mount(8), der NFS-Client und der NFS-Server die korrekten Transport- und Datentransfergrößeneinstellungen für einen Einhängepunkt automatisch aushandeln. In einigen Fällen lohnt es sich aber, diese Einstellungen explizit mit Einhängeoptionen festzulegen.

Traditionell verwenden NFS-Clients exklusiv den UDP-Transport für die Übertragung von Anfragen an Server. Obwohl die Implementierung einfach ist, hat NFS über UDP viele Einschränkungen, die einen reibungslosen Betrieb und gute Leistung in einigen typischen Einsatzumgebungen verhindern. Selbst ein unbedeutender Paketverlust führt zu dem Verlust ganzer NFS-Anfragen. Daher sind Neuübertragungszeitüberschreitungen normalerweise im Subsekundenbereich, damit Clients sich schnell von verlorengegangenen Anfragen erholen können. Dies kann aber zu zusätzlichem Netzverkehr und Serverlast führen.

UDP kann jedoch in spezialisierten Einstellungen ziemlich effektiv sein, bei denen die MTU des Netzes im Vergleich zur Datentransfergröße von NFS groß ist (wie in Netzwerkumgebungen, die Jumbo-Ethernet-Frames aktivieren). In derartigen Umgebungen wird empfohlen, die Einstellungen rsize und wsize so einzuschränken, dass jede NFS-Lese- oder -Schreib-Anfrage in nur wenige Netz-Frames (oder sogar einem einzigen Frame) passt. Dies vermindert die Wahrscheinlichkeit, dass der Verlust eines einzelnen Netz-Frames in MTU-Größe zum Verlust einer ganzen großen Lese- oder Schreibabfrage führt.

TCP ist das von allen modernen NFS-Implementierungen verwandte Standardprotokoll. Es liefert in fast allen denkbaren Netzumgebungen eine gute Leistung und bietet exzellente Garantien gegen durch Netzunzuverlässigkeit hervorgerufene Datenverfälschung. TCP ist oft eine Voraussetzung, um einen Server durch eine Firewall einzuhängen.

Unter normalen Umständen verwirft das Netz viel häufiger Pakete, als dies der NFS-Server tut. Daher ist eine aggressive Zeitüberschreitung für die Wiederübertragung unnötig. Typische Einstellungen für die Zeitüberschreitung für NFS über TCP liegen zwischen einer und zehn Minuten. Nachdem ein Client seine Neuübertragungen (dem Wert der Einhängeoption retrans) ausgeschöpft hat, nimmt er an, dass das Netz in Teile zerfallen ist und versucht, sich auf einem neuen Socket mit dem Server zu verbinden. Da TCP alleine für zuverlässigen Datentransfer sorgt, können rsize und wsize standardmäßig auf die größten Werte erlaubt werden, die vom Client und Server unterstützt werden, unabhängig von der MTU-Größe des Netzes.

Verwendung der Einhängeoption »mountproto«
Dieser Abschnitt betrifft nur NFS-Version-2- und -Version-3-Einhängungen, da NFS Version 4 kein separates Protokoll für Einhängeanfragen verwendet.

Der Linux-NFS-Client kann verschiedene Transporte zum Verbindungsaufbau mit einem Rpcbind-Dienst, einem Mountd-Dienst, dem »Network Lock Manager«- (NLM)-Dienst und dem NFS-Dienst des NFS-Servers verwenden. Der genaue durch den Linux-NFS-Client eingesetzte Transport hängt von den Einstellungen der Transporteinhängeoptionen ab, zu denen proto, mountproto, udp und tcp gehören.

Der Client schickt »Network Status Manager (NSM)«-Benachrichtigungen über UDP unabhängig davon, welche Transportoptionen festgelegt wurden, wartet aber auf die NSM-Benachrichtigungen des Servers sowohl auf UDP als auch TCP. Das Protokoll »NFS Access Control List (NFSACL)« nutzt den gleichen Transport wie der Haupt-NFS-Dienst.

Falls keine Transportoptionen festgelegt wurden, verwendet der Linux-NFS-Client standardmäßig UDP, um den Mountd-Dienst des Servers zu kontaktieren und TCP, um seine NLM- und NFS-Dienste zu kontaktieren.

Falls der Server diese Transporte für diese Dienste nicht unterstützt, versucht der Befehl mount(8) herauszufinden, was der Server unterstützt und versucht dann, die Einhängeanfrage erneut mit den herausgefundenen Transporten. Falls der Server keine vom Client unterstützten Transporte bekanntgibt, schlägt die Einhängeanfrage fehl. Falls die Option bg benutzt wird, bringt sich der Einhängebefehl in den Hintergrund und versucht die angegebene Einhängeanfragen weiter.

Wenn die Option proto, die Option udp oder die Option tcp aber nicht die Option mountproto festgelegt ist, wird der festgelegte Transport sowohl für den Kontakt zum Mountd-Dienst des Servers als auch für die NLM- und NFS-Dienste benutzt.

Falls die Option mountproto aber keine der Optionen proto, udp oder tcp festgelegt sind, wird der angegebene Transport für die initiale Mountd-Anfrage verwandt, der Befehl mount versucht aber zu ermitteln, was der Server für das NFS-Protokoll unterstützt. Dabei bevorzugt er TCP, falls beide Transporte unterstützt werden.

Falls beide Option mountproto und proto (oder udp oder tcp) angegeben sind dann wird der mit der Option mountproto festgelegte Transport für die anfängliche Mountd-Anfrage und der mit der Option proto (oder den Optionen udp oder tcp) festgelegte Transport für NFS verwandt, unabhängig von der Reihenfolge der Optionen. Falls diese Optionen festgelegt sind, erfolgt keine automatische Erkennung der Dienste.

Falls eine der Optionen proto, udp, tcp oder mountproto mehr als einmal auf der gleichen Befehlszeile festgelegt werden, dann tritt der Wert, der am weitesten rechts steht, in Kraft.

Verwendung von NFS über UDP auf Hochgeschwindigkeitsverbindungen
Die Verwendung von NFS über UDP auf Hochgeschwindigkeitsverbindungen wie Gigabit kann ohne Rückmeldung zu Datenverfälschung führen.

Das Problem kann durch hohe Lasten ausgelöst werden und wird durch Probleme in dem IP-Fragment-Wiederzusammenbau verursacht. NFS-Lese- und Schreibvorgänge übertragen typischerweise UDP-Pakete von 4 Kilobyte oder mehr, die in mehrere Fragmente zerteilt werden müssen, damit sie über eine Ethernet-Verbindung übertragen werden können, da diese standardmäßig Pakete auf 1500 byte begrenzt. Dieser Prozess passiert in der IP-Netzschicht und wird Fragmentierung genannt.

Um zusammengehörige Fragmente zu identifizieren, weist IP jedem Paket einen 16-bit-IP ID-Wert zu. Fragmente, die vom gleichen UDP-Paket erstellt wurden, werden die gleiche IP-Kennung haben. Das Empfangssystem sammelt dann diese Fragmente und kombiniert sie so, dass daraus das ursprüngliche UDP-Paket entsteht. Dieser Prozess heißt Wiederzusammenbau. Die Standardzeitüberschreitung für den Paketwiederzusammenbau ist 30 Sekunden. Falls der Netzwerkstapel nicht alle Fragmente für ein bestimmtes Paket innerhalb dieses Intervalls erhält, nimmt er an, dass fehlende Fragmente verloren gegangen sind und verwirft die bereits empfangenen.

Dies erzeugt bei Hochgeschwindigkeitsverbindungen ein Problem, da es möglich ist, mehr als 65536 Pakete innerhalb von 30 Sekunden zu übertragen. Tatsächlich kann bei umfangreichem NFS-Verkehr beobachtet werden, dass sich die IP-Kennungen nach rund 5 Sekunden wiederholen.

Das hat ernsthafte Effekte für den Wiederzusammenbau: Falls ein Fragment verloren geht und ein anderes Fragment von einem anderen Paket mit der gleichen IP-Kennung innerhalb der 30-Sekunden-Zeitüberschreitung eintrifft wird der Netzwerkstapel diese Fragmente zu einem neuen Paket zusammensetzen. Meistens werden Netzschichten oberhalb von IP diesen fehlerhaften Wiederzusammenbau erkennen. Im Falle von UDP wird die UDP-Prüfsumme, eine 16-Bit-Prüfsumme, normalerweise nicht korrekt sein und UDP wird das defekte Paket verwerfen.

Allerdings ist die UDP-Prüfsumme nur 16 Bit, so dass es eine Möglichkeit von 1 in 65536 gibt, dass die Prüfsumme passt, obwohl der Nutzinhalt vollkommen zufällig ist (was allerdings sehr oft nicht der Fall ist). Trifft dies zu, dann sind Daten ohne Rückmeldung defekt.

Diese Möglichkeit sollte sehr ernst genommen werden, zumindest auf Gigabit-Ethernet. Netzgeschwindigkeiten von 100 MBit/s sollten als weniger problematisch betrachtet werden, da bei den meisten Verkehrsmustern der Umlauf der IP-Kennung sehr viel länger als 30 Sekunden betragen wird.

Es wird daher nachdrücklich empfohlen, wo möglich NFS über TCP zu verwenden, da TCP keine Fragmentierung durchführt.

Wenn Sie unbedingt NFS über UDP über Gigabit-Ethernet verwenden müssen, können ein paar Dinge unternommen werden, um dem Problem entgegen zu wirken und die Wahrscheinlichkeit für Verfälschungen zu reduzieren:

Um einer Maschine auf Karten, die das unterstützen, zu ermöglichen, Jumbo Frames zu versenden, reicht es aus, die Schnittstelle für einen MTU-Wert von 9000 zu konfigurieren.

Niederigere Zeitüberschreitung für den Wiederzusammenbau:

Durch Absenken dieser Zeitüberschreitung unter die Zeit, die für den IP-Kennungszählerumlauf benötigt wird, kann auch der fehlerhafte Wiederzusammenbau der Fragmente vermieden werden. Um dies zu erreichen, schreiben Sie den neuen Zeitüberschreitungswert (in Sekunden) in die Datei /proc/sys/net/ipv4/ipfrag_time.

Ein Wert von 2 Sekunden reduziert die Wahrscheinlichkeit von IP-Kennungszusammenstößen auf einer einzelnen Gigabit-Verbindung deutlich, erlaubt dabei aber auch noch eine vernünftige Zeitüberschreitung beim Empfang von fragmentiertem Verkehr von weit entfernten Teilnehmern.

DATEN- UND METADATENKOHÄRENZ

Einige moderne Cluster-Dateisysteme stellen zwischen ihren Clients eine perfekte Zwischenspeicherkohärenz bereit. Es ist sehr teuer, eine perfekte Zwischenspeicherkohärenz zwischen verteilten NFS-Clients zu erreichen, besonders auf Weitverkehrsnetzen. Daher belässt es NFS bei einer schwächeren Zwischenspeicherkohärenz, die die Anforderungen der meisten gemeinsamen Dateinutzungsarten erfüllt.

»close-to-open«-Zwischenspeicherkohärenzsemantik
Typischerweise erfolgt das gemeinsame Benutzen von Dateien sequenziell. Zuerst öffnet Client A eine Datei, schreibt etwas hinein und schließt sie dann. Danach öffnet Client B die gleiche Datei und liest die Änderungen.

Wenn eine Anwendung eine auf einem NFS-3-Server gespeicherte Datei öffnet, überprüft der NFS-Client, ob die Datei noch auf dem Server existiert und dem Öffner erlaubt ist, indem er eine Anfrage GETATTR oder ACCESS sendet. Der NFS-Client sendet diese Anfragen unabhängig von der Frische der zwischengespeicherten Attribute der Datei.

Wenn die Anwendung die Datei schließt, schreibt der NFS-Client alle anhängenden Änderungen an der Datei zurück, so dass der nächste Öffner die Änderungen sehen kann. Dieses gibt dem NFS-Client eine Möglichkeit, alle Schreibfehler mittels des Rückgabewerts von close(2) mitzuteilen.

Das Verhalten der Prüfung zum Zeitpunkt des Öffnens und des Rückschreibens zum Zeitpunkt des Schließens wird als »close-to-open«-Zwischenspeicherkohärenzsemantik oder CTO bezeichnet. Sie kann für einen gesamten Einhängepunkt mit der Einhängeoption nocto deaktiviert werden.

Schwache Zwischenspeicherkohärenz
Es gibt immer noch Möglichkeiten für den Zwischenspeicher des Clients, abgelaufene Daten zu enthalten. Das NFS-Version-3-Protokoll führt die »schwache Zwischenspeicherkohärenz« ein (auch als WCC bekannt), die einen Weg beschreibt, mit der die Dateiattribute vor und nach einer Anfrage effizient überprüft werden können. Dies hilft einem Client, Änderungen, die durch andere Clients vorgenommen worden sein könnten, zu identifizieren.

Wenn ein Client viele parallele Aktionen einsetzt, die die gleiche Datei zur gleichen Zeit aktualisieren (beispielsweise während asynchronem verzögertem Schreiben), ist es immer noch schwierig, zu entscheiden, ob es diese Aktualisierungen des Clients oder Aktualisierungen auf einem anderen Client waren, die die Datei veränderten.

Attribut-Zwischenspeicherung
Verwenden Sie die Einhängeoption noac, um die Zwischenspeicherkohärenz für Attribute zwischen mehreren Clients zu erreichen. Fast jede Dateisystemaktion prüft Dateiattributinformationen. Die Clients halten diese Informationen für eine bestimmte Zeit im Zwischenspeicher, um Netz- und Server-Last zu reduzieren. Wenn noac aktiv ist, ist der Zwischenspeicher des Clients für Dateiattribute deaktiviert und daher muss jede Aktion, die die Dateiattribute prüft, zwingend zum Server gehen. Dies ermöglicht es einem Client, Änderungen sehr schnell zu erkennen, führt aber zu vielen zusätzlichen Netzaktionen.

Achtung: Verwechseln Sie die Option noac nicht mit »keine Daten-Zwischenspeicherung«. Die Einhängeoption noac hindert den Client daran, die Dateimetadaten zwischenzuspeichern, aber es gibt immer noch Ressourcenwettläufe, die zu Daten-Zwischenspeicher-Inkohärenzen zwischen Client und Server führen können.

Das NFS-Protokoll wurde nicht entwickelt, um echte Cluster-Dateisystem-Zwischenspeicherkohärenz zu unterstützen, ohne dass die Anwendungen eine Art von Serialisierung unterstützen. Falls zwischen den Clients eine absolute Zwischenspeicherkohärenz benötigt wird, sollten die Anwendungen das Sperren von Dateien einsetzen. Alternativ können Anwendungen ihre Dateien auch mit dem Schalter O_DIRECT öffnen, um das Zwischenspeichern der Daten komplett zu deaktivieren.

Dateizeitstempelverwaltung
NFS-Server sind dafür verantwortlich, die Datei- und Verzeichniszeitstempel (atime, ctime und mtime) zu verwalten. Wenn auf eine Datei zugegriffen oder diese auf dem NFS-Server aktualisiert wird, werden die Zeitstempel der Datei so aktualisiert, als ob sie relativ zu der Anwendung auf einem lokalen Dateisystem wären.

NFS-Clients speichern Dateiattribute, auch Zeitstempel, zwischen. Die Zeitstempel einer Datei werden auf den NFS-Clients aktualisiert, wenn seine Attribute von dem NFS-Server abgefragt werden. Daher kann es zu Verzögerungen kommen, bevor eine Zeitstempelaktualisierung auf dem NFS-Server für Anwendungen auf NFS-Clients sichtbar wird.

Um den POSIX-Dateisystemstandard zu erfüllen, verlässt sich der Linux-NFS-Client auf die NFS-Server, die Zeitstempel mtime und ctime der Datei korrekt aktuell zu halten. Um dies zu erreichen, schiebt er lokale Datenänderungen an den Server, bevor er mtime mittels Systemaufrufen wie stat(2) an Anwendungen meldet.

Der Linux-Client handhabt allerdings Aktualisierungen der atime lockerer. NFS-Clients halten eine gute Leistung, indem sie Daten zwischenspeichern, aber das bedeutet, dass Lesezugriffe von Anwendungen, die normalerweise die atime aktualisierten, nicht auf dem Server gespiegelt werden, wo die atime der Datei tatsächlich verwaltet wird.

Aufgrund dieses Zwischenspeicherverhaltens unterstützt der Linux-NFS-Client nicht die generischen Atime-bezogenen Einhängeoptionen. Siehe mount(8) für Details über diese Optionen.

Insbesondere haben die Einhängeoptionen atime/noatime, diratime/nodiratime, relatime/norelatime und strictatime/nostrictatime auf NFS-Einhängungen keinen Effekt.

/proc/mounts könnte berichten, dass die Einhängeoption relatime auf NFS-Einhängungen gesetzt ist, aber tatsächlich sind die atime-Semantiken immer wie hier beschrieben und nicht wie die relatime-Semantik.

Zwischenspeicherung von Verzeichniseinträgen
Der Linux-NFS-Client-Zwischenspeicher ist das Ergebnis aller »NFS LOOKUP«-Anfragen. Falls die angefragten Verzeichniseinträge auf dem Server existieren, wird das Ergebnis als positives Abfrageergebnis bezeichnet. Falls der angefragte Verzeichniseintrag nicht auf dem Server existiert (d.h. der Server ENOENT zurücklieferte), wird das Ergebnis als negatives Abfrageergebnis bezeichnet.

Um zu erkennen, wann Verzeichniseinträge auf dem Server hinzugefügt oder dort entfernt wurden, überwacht der Linux-NFS-Client die Mtime eines Verzeichnisses. Falls der Client eine Änderung in der Mtime des Verzeichnisses erkennt, beseitigt der Client alle zwischengespeicherten LOOKUP-Ergebnisse für dieses Verzeichnis. Da die Mtime des Verzeichnisses ein zwischengespeichertes Attribut ist, kann es einige Zeit dauern, bis der Client eine Änderung bemerkt. Siehe die Beschreibung der Einhängeoptionen acdirmin, acdirmax und noac für weitere Informationen darüber, wie lange die Mtime eines Verzeichnisses zwischengespeichert wird.

Das Zwischenspeichern von Verzeichniseinträgen verbessert die Leistung von Anwendungen, die Dateien nicht mit Anwendungen auf anderen Clients gemeinsam nutzen. Die Verwendung von zwischengespeicherten Informationen über Verzeichnisse kann allerdings Anwendungen durcheinanderbringen, die parallel auf mehreren Clients laufen und die die Erstellung und Entfernung von Dateien schnell erkennen müssen. Die Einhängeoption lookupcache erlaubt teilweise das Einstellen des Verhaltens der Verzeichniseintragszwischenspeicherung.

Vor Kernelveröffentlichung 2.6.28 verfolgte der Linux-NFS-Client nur positive Abfrageergebnisse. Dies ermöglichte Anwendungen, neue Verzeichniseinträge, die von anderen Clients erstellt wurden, schnell zu erkennen, und dabei immer noch einige der Leistungsvorteile des Zwischenspeichers zu genießen. Falls eine Anwendung von dem vorherigen Abfrageverhalten des Linux-NFS-Clients abhängt, können Sie lookupcache=positive verwenden.

Falls der Client seinen Zwischenspeicher ignoriert und jede Anwendungsnachschlageanfrage beim Server überprüft, kann der Client sofort erkennen, wenn ein neuer Verzeichniseintrag durch einen anderen Client entweder erstellt oder entfernt wurde. Sie können dieses Verhalten mittels lookupcache=none festlegen. Die zusätzlichen NFS-Anfragen, die benötigt werden, falls der Client Verzeichniseinträge nicht zwischenspeichert, kann eine Leistungseinbuße zur Folge haben. Deaktivieren des Zwischenspeicherns der Nachfragen sollte zu einer geringeren Leistungseinbuße führen als die Verwendung von noac und hat keinen Effekt darauf, wie der NFS-Client die Attribute von Dateien zwischenspeichert.

Die Einhängeoption »sync«
Der NFS-Client behandelt die Einhängeoption sync anders als einige andere Dateisysteme (lesen Sie mount(8) für eine Beschreibung der generischen Einhängeoptionen sync und async). Falls weder sync noch async festgelegt ist (oder falls die Option async festgelegt wurde) verzögert der NFS-Client das Versenden von Schreibanforderungen von Anwendungen an den Server, bis eines der folgenden Ereignisse auftritt:

Speicherdruck erzwingt die Zurückgewinnung von Systemspeicherressourcen.

Eine Anwendung schiebt explizit die Dateidaten mit sync(2), msync(2) oder fsync(3) raus.

Eine Anwendung schließt eine Datei mit close(2).

Die Datei wird mittels fcntl(2) gesperrt/entsperrt.

Mit anderen Worten, unter normalen Bedingungen können von einer Anwendung geschriebene Daten nicht sofort auf dem Server, der die Datei beherbergt, auftauchen.

Falls die Option sync am Einhängepunkt festgelegt wurde, werden bei jedem Systemaufruf, der Daten in Dateien unter diesem Einhängepunkt schreibt, diese erst auf den Server geschrieben, bevor der Systemaufruf die Steuerung an den Benutzerraum zurückgibt. Damit wird größere Datenzwischenspeicherkohärenz unter den Clients erreicht, allerdings unter signifikanten Leitungseinbußen.

Anwendungen können den Schalter »O_SYNC« von open verwenden, um zu erzwingen, dass Schreibanforderungen von Anwendungen für bestimmte Dateien sofort an den Server gesandt werden, ohne die Einhängeoption sync zu verwenden.

Verwendung von Dateisperren mit NFS
Das Protokoll »Network Lock Manager« ist ein separates Seitenbandprotokoll, das zur Verwaltung von Dateisperren in NFS-Version 2 und 3 verwandt wird. Um das Wiederherstellen von Sperren nach einem Systemneustart eines Clients oder Servers zu unterstützen, ist ein zweites Seitenbandprotokoll – bekannt als »Network Status Manager«-Protokoll – notwendig. In NFS Version 4 wird das Sperren direkt im Haupt-NFS-Protokoll unterstützt und die NLM- und NSM-Seitenbandprotokolle werden nicht verwandt.

Meistens werden die Dienste NLM und NSM automatisch gestartet und es wird keine spezielle Konfiguration benötigt. Konfigurieren Sie alle NFS-Clients mit den vollqualifizierten Rechnernamen, um sicherzustellen, dass NFS-Server die Clients finden und sie über Server-Neustarts informieren können.

NLM unterstützt nur empfohlene Sperren. Um NFS-Dateien zu sperren, verwenden Sie fcntl(2) mit den Befehlen F_GETLK und F_SETLK. Der NFS-Client wandelt via flock(2) erworbene Dateisperren in empfohlene Sperren um.

Wenn von Servern, die nicht das NLM-Protokoll unterstützen, oder wenn von einem NFS-Server durch eine Firewall, die den NLM-Dienste-Port blockiert, eingehängt wird, dann verwenden Sie die Einhängeoption nolock. NLM-Sperren müssen mit der Option nolock ausgeschaltet werden, wenn /var mit NFS verwandt wird, da /var Dateien enthält, die von der NLM-Implementierung unter Linux verwandt werden.

Es wird auch empfohlen, die Option nolock zu verwenden, um die Leistung von proprietären Anwendungen, die auf einem einzelnen Client laufen und extensiv Dateisperren verwenden, zu verbessern.

Zwischenspeicherfunktionalitäten in NFS Version 4
Das Zwischenspeicherverhalten für Daten und Metadaten bei Clients der NFS-Version 4 ist ähnlich zu dem von älteren Versionen. Allerdings fügt NFS Version 4 zwei Funktionalitäten hinzu, die das Zwischenspeicherverhalten verbessern: Attributänderung und Datei-Delegation.

Die Attributänderung ist ein neuer Teil der NFS-Datei- und -Verzeichnis-Metadaten, die Änderungen nachverfolgt. Sie ersetzt die Verwendung von Zeitstempeln der Dateiänderung, um Clients zu ermöglichen, die Gültigkeit der Inhalte ihrer Zwischenspeicher zu überprüfen. Attributänderungen sind allerdings unabhängig von der Zeitstempelauflösung sowohl auf dem Server als auch auf dem Client.

Eine Datei-Delegation ist ein Vertrag zwischen einem NFS-Version-4-Client und einem Server, der es dem Client erlaubt, eine Datei temporär so zu behandeln, als ob kein anderer Client darauf zugreifen würde. Der Server verspricht dem Client, ihn zu benachrichtigen (mittels einer Rückrufanfrage), falls ein anderer Client versucht, auf die Datei zuzugreifen. Sobald eine Datei dem Client delegiert wurde, kann der Client aggressiv die Daten und Metadaten der Datei zwischenspeichern, ohne den Server zu benachrichtigen.

Datei-Delegationen gibt es in zwei Varianten: read und write. Eine read-Delegation bedeutet, dass der Server den Client über jeden anderen Client informiert, der in die Datei schreiben möchte. Eine write-Delegation bedeutet, dass der Client sowohl über Lese- als auch Schreibzugreifende informiert wird.

Server gewähren Datei-Delegationen, wenn eine Datei geöffnet wird und können diese jederzeit zurückfordern, wenn ein anderer Client auf die Datei zugreifen möchte und dies im Widerspruch zu bereits gewährten Delegationen steht. Delegationen von Verzeichnissen werden nicht unterstützt.

Um Delegations-Rückrufe zu unterstützen, prüft der Server während des ursprünglichen Kontakts des Clients mit dem Server den Rückkehrpfad zum Client. Falls der Kontakt mit dem Client nicht aufgebaut werden kann, gewährt der Server einfach diesem Client keine Delegationen.

SICHERHEITSBETRACHTUNGEN

NFS-Server steuern den Zugriff auf Dateidaten, sie hängen aber von ihrer RPC-Implementierung ab, um die Authentifizierung von NFS-Anfragen bereitzustellen. Traditionelle NFS-Zugriffssteuerung ahmt die Standard-Modusbits-Zugriffssteuerung nach, die von lokalen Dateisystemen bereitgestellt wird. Traditionelle RPC-Authentifizierung verwendet eine Zahl, um jeden Benutzer darzustellen (gewöhnlich die UID des Benutzers), eine Zahl, um die Gruppe des Benutzers darzustellen (die GID des Benutzers) und eine Menge von bis zu 16 Hilfsgruppennummern, um weitere Gruppen darzustellen, bei denen der Benutzer ein Mitglied sein könnte.

Typischerweise erscheinen Dateidaten- und Benutzerkennungswerte unverschlüsselt (d.h. im Klartext) im Netz. Desweiteren verwenden NFS-Version 2 und 3 separate Seitenbandprotokolle zum Einhängen, Sperren und Entsperren von Dateien und zum Berichten des Systemstatus von Clients und Servern. Diese Hilfsprotokolle verwenden keine Authentifizierung.

NFS-Version 4 kombiniert diese Seitenbandprotokolle mit dem Haupt-NFS-Protokoll und führt zusätzlich fortschrittlichere Formen der Zugriffssteuerung, Authentifizierung und des Übertragungsdatenschutzes ein. Die NFS-Version-4-Spezifikation verlangt starke Authentifizierung und Sicherheitsvarianten, die pro-RPC-Integritätsprüfungen und Verschlüsselung bereitstellen. Da NFS Version 4 die Funktionen der Seitenbandprotokolle in das Haupt-NFS-Protokoll integriert, gelten die neuen Sicherheitsfunktionalitäten für alle NFS-Version-4-Aktionen inklusive Einhängen, Dateisperren und so weiter. RPCGSS-Authentifizierung kann auch mit NFS-Version 2 und 3 verwandt werden, allerdings schützt es nicht ihre Seitenbandprotokolle.

Die Einhängeoption sec legt die Sicherheitsvariante fest, die für Aktionen im Auftrag von Benutzern auf diesem NFS-Einhängepunkt gelten. Die Verwendung von sec=krb5 liefert einen kryptographischen Nachweis der Identität in jeder RPC-Anfrage. Dies stellt eine starke Überprüfung der Identität des Benutzers, der auf Daten auf dem Server zugreift, dar. Beachten Sie, dass neben der Hinzunahme dieser Einhängeoption weitere Konfiguration benötigt wird, um Kerberos-Sicherheit zu aktivieren. Lesen Sie die Handbuchseite rpc.gssd(8) für weitere Details.

Zwei zusätzliche Varianten der Kerberos-Sicherheit werden unterstützt: krb5i und krb5p. Die Sicherheitsvariante krb5i stellt eine kryptographisch starke Garantie dar, dass keine RPC-Anfrage verändert wurde. Die Sicherheitsvariante krb5p verschlüsselt jede RPC-Anfrage, um Datenoffenlegung während der Netzübertragung zu verhindern, allerdings müssen Sie Leistungseinbußen erwarten, wenn Sie Integritätsprüfung oder Verschlüsselung verwenden. Ähnliche Unterstützung für weitere Formen der kryptographischen Sicherheit sind ebenfalls verfügbar.

Dateisystemwechsel in NFS Version 4
Das NFS-Version-4-Protokoll erlaubt es einem Client, die Sicherheitsvariante neu auszuhandeln, wenn der Client in ein neues Dateisystem auf dem Server wechselt. Die neu ausgehandelte Variante betrifft nur Zugriffe auf dem neuen Dateisystem.

Solche Aushandlungen treten typischerweise auf, wenn ein Client von einem Pseudodateisystem des Servers in eines der vom Server exportierten physischen Dateisysteme wechselt. Diese haben oft restriktivere Sicherheitseinstellungen als das Pseudodateisystem.

NFS-Version-4-Ausleihe
In NFS Version 4 ist eine Ausleihe (»lease«) eine Zeitperiode, in der der Server dem Client unumkehrbar eine Dateisperre gewährt. Falls die Ausleihe ausläuft, darf der Server die Sperre zurückziehen. Clients erneuern ihre Ausleihe periodisch, um die Zurückziehung von Sperren zu vermeiden.

Nachdem ein NFS-Version-4-Server neustartet, teilt jeder Client dem Server mit, welche Dateien offen sind und welchen Sperrzustand unter seiner Ausleihe vorliegt, bevor die Arbeit fortgefahren werden kann. Falls der Client neu startet, löst der Server alle offenen und Sperrzustände, die mit der Ausleihe des Clients verbunden sind.

Während der Etablierung einer Ausleihe muss der Client sich daher gegenüber dem Server identifizieren. Um den Client von anderen zu unterscheiden, wird eine feste Zeichenkette verwandt und ein änderbarer Überprüfer zeigt an, wenn ein Client neu gestartet wurde.

Ein Client verwendet eine bestimmte Sicherheitsvariante und -Principal, wenn er Aktionen zum Aufbau der Ausleihe durchführt. Falls es passiert, dass zwei Clients die gleiche Identifizierungszeichenkette vorweisen, kann ein Server ihre Principials verwenden, um zu erkennen, dass dies verschiedene Clients sind und verhindern, dass ein Client der Ausleihe des anderen Clients in die Quere kommt.

Der Linux-NFS-Client etabliert eine Ausleihe für jeden Server. Ausleih-Verwaltungsaktionen, wie Ausleih-Erneuerung, werden nicht im Auftrag einer bestimmten Datei, Sperre, eines bestimmten Benutzers oder Einhängepunkts durchgeführt, sondern für den gesamten Client, dem die Ausleihe gehört. Diese Aktionen müssen die gleiche Sicherheitsvariante und -Principial verwenden, die zum Aufbau der Ausleihe verwandt wurden, selbst nach Neustarts von Clients.

Wenn auf einem Linux-NFS-Client Kerberos konfiguriert ist (d.h. es eine /etc/krb5.keytab auf diesem Client gibt), versucht der Client, eine Kerberos-Sicherheitsvariante für seine Ausleih-Verwaltungsaktionen zu verwenden. Dies bietet starke Authentifizierung des Clients zu jedem Server, den er kontaktiert. Standardmäßig verwendet der Client für diesen Zweck die Dienst-Principials host/ oder nfs/ in seiner /etc/krb5.keytab.

Falls der Client aber nicht der Server Kerberos konfiguriert hat oder falls der Client keine Schlüsseltabelle oder die benötigten Server-Principals hat, verwendet der Client AUTH_SYS und UID 0 für die Ausleih-Verwaltung.

Verwendung nichtprivilegierter Quell-Ports
NFS-Clients kommunizieren normalerweise über Netz-Sockets mit dem Server. Jedes Ende eines Sockets wird ein Port-Wert zugeordnet. Dieser ist einfach eine Nummer zwischen 1 und 65535, der die Socket-Endpunkte auf der gleichen IP-Adresse unterscheidet. Ein Socket ist eindeutig durch das Tupel Transportprotokoll (TCP oder UDP), dem Port-Wert und der IP-Adresse beider Endpunkte definiert.

Der NFS-Client kann jeden Quell-Port-Wert für seine Sockets auswählen, nimmt aber gewöhnlich einen privilegierten Port. Ein privilegierter Port-Wert ist kleiner als 1024. Nur ein Prozess mit Root-Rechten kann einen Socket mit einem privilegierten Quell-Port erstellen.

Der genaue Bereich der auswählbaren privilegierten Quell-Ports wird durch ein Sysctl-Paar ausgewählt, um gut bekannte Ports zu vermeiden, wie den von SSH verwandten Port. Das bedeutet, dass die Anzahl der für den NFS-Client verfügbaren Quell-Ports und damit die Anzahl der Socket-Verbindungen, die gleichzeitig verwandt werden können, praktisch auf nur einige Hundert begrenzt ist.

Wie oben beschrieben, verlässt sich das traditionelle Standard-NFS-Authentifizierungsschema, bekannt als AUTH_SYS, auf das Senden der lokalen UID und GID-Nummern, um Benutzer, die NFS-Anfragen stellen, zu identifizieren. Ein NFS-Server nimmt an, dass die UID und GID-Nummer in den NFS-Anfragen auf dieser Verbindung vom Client-Kernel oder einer anderen lokalen Autorität überprüft wurde, falls die Verbindung von einem privilegierten Port kommt. Dieses System ist leicht zu täuschen, aber in vertrauenswürdigen physischen Netzen zwischen vertrauenswürdigen Rechnern ist es vollkommen angemessen.

Grob gesprochen wird ein Socket für jeden NFS-Einhängepunkt verwandt. Falls ein Client auch nichtprivilegierte Quell-Ports verwenden könnte, wäre die Anzahl der erlaubten Sockets und damit die maximale Anzahl an gleichzeitigen Einhängepunkten viel größer.

Die Verwendung nichtprivilegierter Quell-Ports könnte die Server-Sicherheit etwas beeinträchtigen, da jeder Benutzer auf AUTH_SYS-Einhängepunkten bei NFS-Anfragen jetzt vorgeben kann, ein beliebiger anderer zu sein. Daher unterstützen NFS-Server dies standardmäßig nicht. Normalerweise erlauben sie dies über eine explizite Export-Option.

Um gute Sicherheit zu wahren und gleichzeitig so viele Einhängepunkte wie möglich zu erlauben, ist es am besten, nichtprivilegierte Ports nur zu erlauben, falls der Server und der Client beide eine starke Authentifizierung wie Kerberos verlangen.

Einhängen durch eine Firewall
Eine Firewall könnte zwischen einem NFS-Client und -Server liegen, oder der Client oder der Server könnte einige seiner eigenen Ports über IP-Filterregeln blockieren. Es ist weiterhin möglich, einen NFS-Server durch eine Firewall einzuhängen, allerdings könnten einige der automatischen Serverendpunktentdeckungsmechanismen des Befehls mount(8) nicht funktionieren. Daher müssen Sie dann spezifische Endpunktdetails über NFS-Einhängeoptionen bereitstellen.

NFS-Server betreiben normalerweise einen Portmapper oder einen Rpcbind-Daemon, um ihre Diensteendpunkte den Clients bekanntzugeben. Clients verwenden den Rpcbind-Daemon, um zu ermitteln:

Welchen Netzwerk-Port jeder RPC-basierte Dienst verwendet

Welches Transportprotokoll jeder RPC-basierte Dienst unterstützt

Der Rpcbind-Daemon verwendet eine gut bekannte Port-Nummer (111), damit Clients einen Diensteendpunkt finden. Obwohl NFS oft eine Standard-Port-Nummer (2049) verwendet, können Hilfsdienste wie der NLM-Dienst jede unbenutzte Port-Nummer zufällig auswählen.

Typische Firewall-Konfigurationen blockieren den gut bekannten Rpcbind-Port. Ohne den Rpcbind-Dienst kann der Administrator die Port-Nummer von Diensten mit Bezug zu NFS festlegen, so dass die Firewall Zugriff auf bestimmte NFS-Dienste-Ports erlauben kann. Client-Administratoren legen dann die Port-Nummer für den Mountd-Dienst mittels der Option mountport des Befehls mount(8) fest. Es kann auch notwendig sein, die Verwendung von TCP oder UDP zu erzwingen, falls die Firewall einen dieser Transporte blockiert.

NFS-Zugriffssteuerlisten
Solaris erlaubt NFS-Version-3-Clients direkten Zugriff auf die auf seinen lokalen Dateisystemen gespeicherten POSIX-Zugriffsteuerlisten. Dieses proprietäre Seitenbandprotokoll namens NFSACL stellt eine umfassendere Zugriffssteuerung als die Modusbits bereit. Linux implementiert dieses Protokoll zur Kompatibilität mit der Solaris-NFS-Implementierung. Das NFSACL-Protokoll wurde allerdings niemals ein Standardteil der NFS-Version-3-Spezifikation.

Die NFS-Version-4-Spezifikation verlangt eine neue Version der Zugriffssteuerlisten, die semantisch reicher als POSIX ACLs ist. NFS-Version-4-ACLs sind mit den POSIX ACLs nicht voll kompatibel, daher ist eine Übersetzung zwischen den beiden in Umgebungen, die POSIX ACLs und NFS Version 4 vermischen, notwendig.

DIE OPTION REMOUNT

Generische Einhängeoptionen wie rw und sync können bei NFS-Einhängepunkten mit der Option remount geändert werden. Siehe mount(8) für weitere Informationen über generische Einhängeoptionen.

Bis auf wenige Ausnahmen können NFS-spezifische Optionen nicht bei einer Neueinhängung geändert werden. Beispielsweise kann der unterliegende Transport oder die NFS-Version durch eine Neueinhängung nicht geändert werden.

Das Neueinhängen auf einem NFS-Dateisystem, das mit der Option noac eingehängt ist, kann unbeabsichtigte Konsequenzen haben. Die Option noac stellt eine Kombination der generischen Option sync und der NFS-spezifischen Option actimeo=0 dar.

Aushängen nach einem erneuten Einhängen
Für Einhängepunkte, die NFS Version 2 oder 3 verwenden, hängt der NFS-Unterbefehl umount davon ab, die ursprüngliche Menge der Einhängeoptionen zu kennen, die zur Ausführung der MNT-Aktion verwandt wurden. Diese Optionen werden durch den NFS-Unterbefehl mount auf Platte gespeichert und können durch erneutes Einhängen gelöscht werden.

Um sicherzustellen, dass die gespeicherten Einhängeoptionen während eines erneuten Einhängens nicht gelöscht werden, geben Sie während eines erneuten Einhängens entweder das lokale Einhängeverzeichnis oder den Rechnernamen und den Exportpfadnamen, aber nicht beide, an. Beispielsweise fügt

mount -o remount,ro /mnt

die Einhängeoption ro mit den bereits auf Platte gespeicherten, für den unter /mnt eingehängten NFS-Server zusammen.

DATEIEN

/etc/nfsmount.conf

Konfigurationsdatei für NFS-Einhängungen

FEHLER

Vor Version 2.4.7 unterstützte der Linux-NFS-Client NFS über TCP nicht.

Vor Linux 2.4.20 verwendete der Linux-NFS-Client eine Heuristik, um zu bestimmen, ob zwischengespeicherte Dateidaten noch gültig waren, statt die oben beschriebene, standardisierte »close-to-open«-Zwischenspeicherkohärenzsemantik zu verwenden.

Beginnend mit 2.4.22 setzt der Linux-NFS-Client einen Van-Jacobsen-basierten RTT-Abschätzer ein, um die Neuübertragungs-Zeitüberschreitungen zu bestimmen, wenn NFS über UDP verwandt wird.

Vor Version 2.6.0 unterstützte der Linux-NFS-Client die NFS-Version 4 nicht.

Vor 2.6.8 verwendete der Linux NFS-Client nur synchrone Lese- und Schreibzugriffe, wenn die Einstellungen für rsize und wsize kleiner als die Seitengröße des Systems waren.

Der Linux-NFS-Client unterstützt bestimmte optionale Funktionalitäten des NFS-Version-4-Protokolls, wie Sicherheitsaushandlungen, Server-Überweisungen und benannte Attribute, noch nicht.

SIEHE AUCH

fstab(5), mount(8), umount(8), mount.nfs(5), umount.nfs(5), exports(5), nfsmount.conf(5), netconfig(5), ipv6(7), nfsd(8), sm-notify(8), rpc.statd(8), rpc.idmapd(8), rpc.gssd(8), rpc.svcgssd(8), kerberos(1)

RFC 768 für die UDP-Spezifikation
RFC 793 für die TCP-Spezifikation
RFC 1094 für die NFS-Version-2-Spezifikation
RFC 1813 für die NFS-Version-3-Spezifikation
RFC 1832 für die XDR-Spezifikation
RFC 1833 für die RPC-Bind-Spezifikation
RFC 2203 für die RPCSEC-GSS-API-Protokoll-Spezifikation
RFC 3530 für die NFS-Version-4-Spezifikation

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von René Tschirley <gremlin [AT] cs.de>, Martin Schulze <joey [AT] infodrom.org>, Jochen Hein <jochen [AT] jochen.org>, Chris Leick <c.leick [AT] vollbio.de> und Helge Kreutzmann <debian [AT] helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an <debian-l10n-german [AT] lists.org>.