Provided by: manpages-de_4.15.0-9_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/hard Bestimmt das Wiederherstellungsverhalten des NFS-Clients nachdem es zu
einer Zeitüberschreitung für eine NFS-Anfrage kam. Falls keine der Optionen
angegeben ist (oder falls die Option hard angegeben ist), werden
NFS-Anfragen unendlich oft erneut versucht. Falls die Option soft angegeben
ist, lässt der NFS-Client eine NFS-Anfrage nach retrans
Übertragungsversuchen fehlschlagen. Dadurch liefert der NFS-Client einen
Fehler 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 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.
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.
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.
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 »-« von
mount.nfs.
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.
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
Einhängeoption. 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)