nfs - Format und Optionen in der fstab-Datei für das
nfs-Dateisystem
/etc/fstab
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
- /etc/fstab
- Dateisystemtabelle
- /etc/nfsmount.conf
- Konfigurationsdatei für NFS-Einhängungen
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.
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
Die deutsche Übersetzung dieser Handbuchseite wurde von René
Tschirley <
[email protected]>, Martin Schulze
<
[email protected]>, Jochen Hein <
[email protected]>, Chris Leick
<
[email protected]> und Helge Kreutzmann <
[email protected]>
erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
GNU
General Public License Version 3 oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken
Sie bitte eine E-Mail an die
Mailingliste
der Übersetzer