Provided by: manpages-de_4.23.1-1_all 
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 zur gemeinsamen
Dateibenutzung auf Systemen im lokalen Netz entwickelt. Abhängig von der Kernelkonfiguration kann der
Linux-NFS-Client die NFS-Versionen 3, 4.0, 4.1 oder 4.2 unterstützen.
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:
Server:Pfad /Einhängepunkt Fstype 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. nfsvers=n Die NFS-Protokollnummer, die für den Kontakt zum NFS-Dienst des Servers verwandt wird. Falls der Server die angefragte Version nicht unterstützt, schlägt die Einhängeanfrage fehl. Falls diese Option nicht angegeben ist, versucht der Client 4.2 zuerst, handelt sich dann runter, bis er eine vom Server unterstützte Version findet. vers=n Diese Option ist eine Alternative zu der Option nfsvers. Sie ist für die Kompatibilität zu anderen Betriebssystemen enthalten. soft / softerr / hard Bestimmt das Wiederherstellungsverhalten des NFS-Clients nachdem es zu einer Zeitüberschreitung für eine NFS-Anfrage kam. Falls keine Option angegeben ist (oder falls die Option hard angegeben ist), werden NFS-Anfragen unendlich oft erneut versucht. Falls entweder die Option soft oder softerr angegeben ist, lässt der NFS-Client eine NFS-Anfrage nach retrans Übertragungsversuchen fehlschlagen. Dadurch liefert der NFS-Client den Fehler EIO (für die Option soft) oder ETIMEDOUT (für die Option softerr) an die aufrufende Anwendung zurück. Nebenbemerkung: Eine sogenannte »weiche« Zeitüberschreitung kann in bestimmten Fällen zu stiller Datenverfälschung führen. Verwenden Sie daher die Option soft oder softerr 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 oder softerr verringern. softreval / nosoftreval Falls der NFS-Server nicht verfügbar ist, könnte es nützlich sein, dass NFS-Clients Pfade und Attribute weiterhin aus dem Zwischenspeicher bereitstellen, nachdem retrans Versuche, den Zwischenspeicher erneut zu bestätigen, wegen Zeitüberschreitungen fehlschlugen. Dies könnte beispielsweise hilfreich sein, wenn versucht wird, einen Dateisystembaum von einem Server, der permanent nicht verfügbar ist, auszuhängen. Es ist möglich, softreval mit der Einhängeoption soft zu kombinieren. In diesem Fall erfolgt eine Zeitüberschreitung für Aktionen, die nicht aus dem Zwischenspeicher bedient werden können, sowie ein Fehler nach retrans Versuchen. Die Kombination mit der Vorgabeeinhängeoption hard impliziert, dass Aktionen, die nicht im Zwischenspeicher liegen, zu Wiederholungen führen, bis vom Server eine Antwort erhalten wird. Hinweis: Die Vorgabeeinhängeoption ist nosoftreval. Diese erlaubt keinen Rückgriff auf den Zwischenspeicher, wenn die Neubestätigung fehlschlägt, sondern folgt stattdessen dem durch die Einhängeoptionen hard oder soft vorgegebenen Verhalten. intr/nointr Diese Aktion wird für Rückwärtskompatibilität bereitgestellt. Sie wird nach Kernel 2.6.25 ignoriert. timeo=n Die Zeit in Zehntelsekunden, die der NFS-Client auf eine Antwort wartet, bevor er eine NFS-Anfrage erneut versucht. 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. retrans=n Die Anzahl der Versuche, die der NFS-Client eine Anfrage erneut unternimmt, bevor er weitere Wiederherstellungsmaßnahmen einleitet. Falls die Option retrans nicht angegeben ist, versucht der NFS-Client jede UDF-Anfrage drei Mal und jede TCP-Anfrage zweimal. 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). rsize=n Die maximale Anzahl von Bytes, die der NFS-Client beim Lesen von Daten aus einer Datei auf einem NFS-Server in jeder Netz-READ-Anfrage empfangen kann. Die tatsächliche Datenmenge jeder NFS-READ-Anfrage ist identisch zu oder kleiner als die Einstellung von rsize. Die größte von dem Linux-NFS-Client unterstützte Lese-Datenmenge ist 1.048.576 Bytes (ein Megabyte). 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. wsize=n Die maximale Anzahl von Bytes, die der NFS-Client beim Schreiben von Daten in eine Datei auf einem NFS-Server in jeder Netz-WRITE-Anfrage senden kann. Die tatsächliche Datenmenge jeder NFS-WRITE-Anfrage ist identisch zu oder kleiner als die Einstellung von wsize. Die größte von dem Linux-NFS-Client unterstützte Schreibe-Datenmenge ist 1.048.576 Bytes (ein Megabyte). Ä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. ac/noac Wählt aus, ob der Client Dateiattribute zwischenspeichern darf. Falls keine Option angegeben ist (oder falls ac angegeben ist), speichert der Client Dateiattribute zwischen. 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. acregmin=n Die minimale Zeit in Sekunden, die Attribute einer regulären Datei vom NFS-Client zwischengespeichert, bevor frische Informationen vom Server angefordert werden sollen. Falls diese Option nicht angegeben ist, verwendet der NFS-Client ein Minimum von 3 Sekunden. Siehe den Abschnitt DATEN- UND METADATENKOHÄRENZ für eine komplette Besprechung des Zwischenspeicherns von Attributen. acregmax=n Die maximale Zeit in Sekunden, die Attribute einer regulären Datei vom NFS-Client zwischengespeichert, bevor frische Informationen vom Server angefordert werden sollen. Falls diese Option nicht angegeben ist, verwendet der NFS-Client ein Maximum von 60 Sekunden. Siehe den Abschnitt DATEN- UND METADATENKOHÄRENZ für eine komplette Besprechung des Zwischenspeicherns von Attributen. acdirmin=n Die minimale Zeit in Sekunden, die Attribute eines Verzeichnisses vom NFS-Client zwischengespeichert, bevor frische Informationen vom Server angefordert werden sollen. Falls diese Option nicht angegeben ist, verwendet der NFS-Client ein Minimum von 30 Sekunden. Siehe den Abschnitt DATEN- UND METADATENKOHÄRENZ für eine komplette Besprechung des Zwischenspeicherns von Attributen. acdirmax=n Die maximale Zeit in Sekunden, die Attribute eines Verzeichnisses vom NFS-Client zwischengespeichert, bevor frische Informationen vom Server angefordert werden sollen. Falls diese Option nicht angegeben ist, verwendet der NFS-Client ein Maximum von 60 Sekunden. Siehe den Abschnitt DATEN- UND METADATENKOHÄRENZ für eine komplette Besprechung des Zwischenspeicherns von Attributen. actimeo=n Die Angabe von actimeo setzt die Größen acregmin, acregmax, acdirmin und acdirmax auf den gleichen Wert. Falls diese Option nicht angegeben ist verwendet der NFS-Client die oben aufgeführten Vorgaben für jede dieser Optionen. bg/fg Bestimmt, wie sich der Befehl mount(8) verhält, falls ein Versuch des Einhängens eines exportierten Verzeichnisses fehlschlägt. Die Option fg führt dazu, dass mount(8) sich mit einem Fehlerstatus beendet, falls irgend ein Teil der Einhängeanfrage in eine Zeitüberschreitung läuft oder fehlschlägt. Dies wird »Vordergrund«-Einhängung genannt und ist das Standardverhalten, falls weder die Einhängeoption fg noch bg angegeben ist. 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). nconnect=n Beim Einsatz eines verbindungsorientierten Protokolls wie TCP kann es manchmal von Vorteil sein, mehrere Verbindungen zwischen Client und Server einzurichten. Falls beispielsweise Ihre Clients und/oder Server mit mehreren Netzwerkschnittstellenkarten (NICs) ausgerüstet sind, können mehrere Verbindungen zur Lastverteilung die Gesamtleistung erhöhen. In diesen Fällen erlaubt die Option nconnect dem Benutzer die Angabe der Verbindungsanzahl, die zwischen dem Client und dem Server aufgebaut werden sollen (bis zur Begrenzung von 16). Beachten Sie, dass die Option nconnect auch bei einigen pNFS-Laufwerken zur Angabe der Anzahl der einzurichtenden Verbindungen zu den Daten-Servern verwandt werden kann. 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. retry=n Die Anzahl an Minuten, die der Befehl mount(8) versucht, eine NFS-Einhängungsaktion im Vordergrund oder im Hintergrund durchzuführen, bevor er aufgibt. Falls diese Option nicht angegeben ist, ist der Standardwert für Vordergrundeinhängungen 2 Minuten und für Hintergrundeinhängungen 10000 Minuten (80 Minuten weniger als eine Woche). Falls ein Wert von 0 angegeben ist, wird der Befehl mount(8) sich sofort nach dem ersten Fehler beenden. 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. sec=Varianten Eine durch Doppelpunkt getrennte Liste von einem oder mehreren Sicherheitsvarianten, die beim Zugriff auf Dateien auf dem eingehängten Export verwandt werden sollen. Falls der Server keine dieser Varianten unterstützt, schlägt die Einhängeaktion fehl. Falls sec= nicht angegeben ist, versucht der Client eine Sicherheitsvariante zu finden, die sowohl vom Client als auch vom Server unterstützt wird. Gültige Varianten sind none, sys, krb5, krb5i und krb5p. Der Abschnitt SICHERHEITSBETRACHTUNGEN enthält Details. 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 Gibt an, 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 Gibt an, 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. fsc/nofsc aktiviert/deaktiviert das Zwischenspeichern von (nur lesbaren) Datenseiten auf der lokalen Platte mittels der FS-Cache-Einrichtung. Siehe cachefilesd(8) und <kernel_source>/Documentation/filesystems/caching für Details zur Einrichtung der FS-Cache-Einrichtung. Die Vorgabe ist nofsc. sloppy Die Option sloppy ist eine Alternative zur Angabe der Option »-s« von mount.nfs. xprtsec=Richtlinie Legt die Verwendung der Transportebenenabsicherung fest, um den NFS-Netzwerkverkehr im Auftrag dieses Einhängepunktes abzusichern. Richtlinie kann entweder none, tls oder mtls sein. Falls none angegeben ist, wird die Transportebenensicherheit zwangsweise ausgeschaltet, selbst falls der NFS-Server Transportebenensicherheit unterstützt. Falls tls angegeben ist, verwendet der Client RPC-mit-TLS, um Vertrauenswürdigkeit während der Übertragung sicherzustellen. Falls mtls angegeben ist, verwendet der Client RPC-mit-TLS, um sich zu authentifizieren und Vertrauenswürdigkeit während der Übertragung sicherzustellen. Falls entweder tls oder mtls angegeben ist und der Server RPC-mit-TLS nicht unterstützt oder die Authentifizierung unter Gleichrangingen fehlschlägt, schlägt der Einhängeversuch fehl. Falls die Option xprtsec= nicht festgelegt wurde, hängt das Standardverhalten von der Kernelversion ab, ist aber normalerweise zu xprtsec=none äquivalent. 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. proto=NetID Die NetID bestimmt den Transport, der zur Kommunikation mit dem NFS-Server verwandt wird. Verfügbare Optionen sind udp, udp6, tcp, tcp6, rdma und rdma6. Die in 6 endenden verwenden IPv6-Adressen und sind nur bei eingebauter Unterstützung für TI-RPC verfügbar. Die anderen verwenden IPv4-Adressen. 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. udp Die Option udp ist eine Alternative zur Angabe von proto=udp. Sie ist zur Kompatibilität mit anderen Betriebssystemen enthalten. Lesen Sie den Abschnitt TRANSPORTMETHODEN unten, bevor Sie NFS über UDP verwenden. tcp Die Option tcp ist eine Alternative zur Angabe von proto=tcp. Sie ist zur Kompatibilität mit anderen Betriebssystemen enthalten. rdma Die Option rdma ist eine Alternative zur Angabe von proto=rdma. port=n Der numerische Wert des Dienste-Ports des NFS-Servers. Falls der NFS-Dienst des Servers nicht auf dem Port verfügbar ist, schlägt die Einhängeanfrage fehl. 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. mountport=n Der numerische Wert des Mountd-Ports des Servers. Falls der Mountd-Dienst des Servers nicht auf dem Port verfügbar ist, schlägt die Einhängeanfrage fehl. 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 angegeben werden. Falls der Mountd-Dienst des Server über den angegebenen 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. mounthost=Name Der Rechnername des Rechners, der Mountd betreibt. Falls diese Option nicht angegeben ist, nimmt der Befehl mount(8) an, dass der Dienst Mountd auf dem gleichen Rechner wie der NFS-Dienst läuft. mountvers=n Die für den Kontakt zum Mountd des Servers zu verwendende PRC-Versionsnummer. Falls diese Option nicht angegeben ist, verwendet der Client eine der gewünschten NFS-Version angemessene Versionsnummer. Diese Option ist nützlich, falls mehrere NFS-Dienste auf dem selben Rechner in der Ferne laufen. namlen=n Die maximale Länge der Pfadnamenkomponente bei dieser Einhängung. Falls diese Option nicht angegeben ist, wird die maximale Länge mit dem Server ausgehandelt. Meistens ist die maximale Länge 255 Zeichen. 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. lock/nolock Wählt aus, ob das NLM-Seitenbandprotokoll zum Sperren von Dateien auf dem Server verwandt wird. Falls keine der Optionen (oder lock) angegeben ist, wird NLM-Sperrung für diesen Einhängepunkt verwandt. Beim Verwenden der Option nolock können Anwendungen Dateien sperren, aber diese Sperren stellen einen exklusiven Zugriff nur gegenüber anderen Anwendungen auf dem gleichen Client sicher. Anwendungen in der Ferne sind von diesen Sperren nicht betroffen. 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. cto/nocto Wählt aus, ob die »close-to-open« (Schließen-bis-Öffnen) Zwischenspeicherkohärenzsemantik verwandt wird. Falls keine Option (oder falls cto) angegeben ist, verwendet der Client »close-to-open«-Zwischenspeicherkohärenzsemantik. Falls die Option nocto angegeben ist, verwendet der Client eine nicht standardisierte Heuristik, um zu bestimmen, wann sich Dateien auf dem Server geändert haben. 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. acl/noacl Wählt aus, ob bei diesem Einhängepunkt das NFSACL-Seitenbandprotokoll verwandt werden soll. Das NFSACL-Seitenbandprotokoll ist ein in Solaris implementiertes proprietäres Protokoll, das Zugriffssteuerlisten verwaltet. NFSACL wurde nie zu einem Standardteil der NFS-Protokollspezifikation. Falls weder die Option acl noch noacl angegeben 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 Gibt an, 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 ersten obigen Unterabschnitt für NFS-Version 4 oder neuer. proto=NetID netid bestimmt den Transport, der für die Kommunikation mit dem NFS-Server verwandt wird. Unterstützte Optionen sind tcp, tcp6, rdma und rdma6. tcp6 verwendet IPv6-Adressen und ist nur verfügbar, falls Unterstützung für TI-RPC eingebaut ist. Die beiden anderen verwenden IPv4-Adressen. 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. minorversion=n Gibt die Unterversionsnummer des Protokolls an. NFSv4 führt »Unterversionen« ein, bei denen NFS-Protokollerweiterungen ohne Erhöhung der NFS-Protokollversionsnummer eingeführt werden können. Vor Kernel 2.6.38 war die Unterversionsnummer immer Null und diese Option wird nicht erkannt. Nach diesem Kernel aktiviert die Angabe von »minorversion=1« eine Reihe von fortschrittlichen Funktionalitäten, wie NFSv4-Sitzungen. Neuere Kernel erlauben die Angabe der Unterversionsnummer mittels der Option vers=. Beispielsweise ist die Angabe vers=4.1 identisch zur Angabe vers=4,minorversion=1. port=n Der numerische Wert des Dienste-Ports des NFS-Servers. Falls der NFS-Dienst des Servers nicht auf dem Port verfügbar ist, schlägt die Einhängeanfrage fehl. Falls diese Einhängeoption nicht angegeben 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. cto/nocto Wählt aus, ob für diesen Einhängepunkt »close-to-open«-Zwischenspeicherkohärenzsemantik für NFS-Verzeichnisse verwandt wird. Falls weder cto noch nocto angegeben sind, ist die Vorgabe, »close-to-open«-Zwischenspeicherkohärenzsemantik für Verzeichnisse zu verwenden. 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. Ein Wert von IPv4_ANY (0.0.0.0) oder äquivalente IP6-any-Adresse kann angegeben werden. Damit wird dem NFS-Server signalisiert, dass dieser NFS-Client keine Delegationen möchte. Falls diese Option nicht angegeben 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. NFS-Protokollversionen 4.1 und 4.2 verwenden Client-etablierte TCP-Verbindungen für Rückrufanfragen und benötigen daher nicht, dass sich der Server mit dem Client verbindet. Diese Option betrifft daher nur NFS-Version-4.0-Einhängungen. 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 angegeben 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. max_connect=n Während nconnect eine Begrenzung für die Anzahl der Verbindungen setzt, die mit einer angegeben Server-IP etabliert werden können, erlaubt die Option max_connect dem Benutzer, die maximale Anzahl an Verbindungen an verschiedene Server-IPs, die zum gleichen NFSv4.1+-Server gehören (Sitzungs-Trunk-Verbindungen), bis zu einer Schranke von 16 festzulegen. Wenn ein Client ermittelt, dass es eine Client-Kennung zu einem bereits bestehenden Server etabliert, wird der Client diese Verbindung zu der Liste der verfügbaren Transporte für diesen RPC-Client hinzufügen, statt den neu erstellten Netzwerktransport zu verwerfen. trunkdiscovery / notrunkdiscovery Wenn der Client ein neues Dateisystem auf einem NFSv4.1+-Server entdeckt, wird die Einhängeoption trunkdiscovery ihn dazu veranlassen, ein GETATTR für das Attribut fs_locations zu senden. Falls er eine Antwort erhält, deren Länge nicht Null ist, wird er durch die Antwort durchlaufen und für jeden Serverort eine Verbindung etablieren, eine EXCHANGE_ID senden und auf Sitzungsbündelung prüfen. Falls der Bündelungstest erfolgreich ist, wird die Verbindung zu der bestehenden Gruppe an Transporten für den Server hinzugefügt, abhängig von der in der Option max_connect festgelegten Begrenzung. Die Vorgabe ist notrunkdiscovery.
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 mit NFS-Version 3 einzuhängen, verwenden Sie den nfs-Dateisystemtyp und geben Sie die Einhängeoption
nfsvers=3 an. 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
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 anzugeben.
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-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 angegeben 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 angegeben 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 angegeben ist,
wird der angegebene 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 angegeben 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 angegebene Transport für die anfängliche Mountd-Anfrage und der mit der Option proto (oder den
Optionen udp oder tcp) angegebene Transport für NFS verwandt, unabhängig von der Reihenfolge der
Optionen. Falls diese Optionen angegeben sind, erfolgt keine automatische Erkennung der Dienste.
Falls eine der Optionen proto, udp, tcp oder mountproto mehr als einmal auf der gleichen Befehlszeile
angegeben 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:
Jumbo Frames: Viele Gigabit-Netzkarten sind in der Lage, Frames größer als die Begrenzung des
traditionellen Ethernet von 1500 byte zu übertragen, typischerweise 9000 bytes. Werden
Jumbo Frames von 9000 bytes verwandt, kann NFS über UDP mit Seitengrößen von 8 K ohne
Fragmentierung betrieben werden. Natürlich ist das nur möglich, falls alle beteiligten
Stationen Jumbo Frames unterstützen.
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 angegeben ist (oder falls die Option async angegeben 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 angegeben 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 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 Periode, in der der Server einem Client unumkehrbar
Dateisperren gewährt. Sobald die Ausleihe abläuft, darf der Server diese Sperren 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
ein Client neu startet, löst der Server alle offenen und Sperrzustände, die mit der Ausleihe des Clients
verbunden sind.
Wenn eine Ausleihe etabliert wird, muss der Client sich daher beim Server identifizieren. Jeder Client
zeigt eine beliebige Zeichenkette vor, um sich von anderen Clients zu unterscheiden. Der
Client-Administrator kann die Vorgabe-Identitätszeichenkette mit dem Modulparameter nfs4.nfs4_unique_id
ergänzen, um Kollisionen mit den Identifikationszeichenketten anderer Clients zu vermeiden.
Ein Client verwendet auch eine eindeutige Sicherheitsvariante und -Principal, wenn es eine Ausleihe
etabliert. Falls zwei Clients die gleiche Identitätszeichenkette vorweisen, kann ein Server die
Client-Principals verwenden, um zwischen beiden zu unterscheiden, und damit auf sichere Weise verhindern,
dass Clients sich gegenseitig mit ihren Ausleihen in die Quere kommen.
Der Linux-NFS-Client etabliert eine Ausleihe auf jeden NFS-Version-4-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 Client, dem die Ausleihe gehört. Ein Client
verwendet eine konsistente Identitätszeichenkette, Sicherheitsvariante und Principal auch über
Systemneustarte hinweg, um sicherzustellen, dass der Server schnell ausgelaufene Ausleihstati
wiedererlangt.
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. Kerberos bietet sichere Authentifizierung jedes Clients an.
Standardmäßig verwendet der Client für diesen Zweck die Dienst-Principials host/ oder nfs/ in seiner
/etc/krb5.keytab, wie dies in rpc.gssd(8) dargestellt ist.
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/fstab Dateisystemtabelle /etc/nfsmount.conf Konfigurationsdatei für NFS-Einhängungen
ANMERKUNGEN
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.
Die Unterstützungen für Protokollversionen des Linux-Clients hängen davon ab, ob der Kernel mit den
Optionen CONFIG_NFS_V2, CONFIG_NFS_V3, CONFIG_NFS_V4, CONFIG_NFS_V4_1 und CONFIG_NFS_V4_2 gebaut wurde.
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 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 7530 für die NFS-version-4.0-Spezifikation RFC 5661 für die Spezifikation der NFS-Version 4.1. RFC 7862 für die NFS-Version-4.2-Spezifikation
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von René Tschirley <gremlin@cs.tu-berlin.de>, Martin Schulze <joey@infodrom.org>, Jochen Hein <jochen@jochen.org>, Chris Leick <c.leick@vollbio.de> und Helge Kreutzmann <debian@helgefjell.de> erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩. 9. Oktober 2012 NFS(5)