NFS(5) File Formats Manual NFS(5) BEZEICHNUNG nfs - Format und Optionen in der fstab-Datei fur das nfs-Dateisystem UBERSICHT /etc/fstab BESCHREIBUNG NFS ist ein von Sun Microsystems 1984 entwickeltes Internet Standardprotokoll. Es wurde zur gemeinsamen Dateibenutzung auf Systemen im lokalen Netz entwickelt. Abhangig von der Kernelkonfiguration kann der Linux-NFS-Client die NFS-Versionen 3, 4.0, 4.1 oder 4.2 unterstutzen. Der Befehl mount(8) fugt ein Dateisystem an einem angegebenen Einhangepunkt zu der Namensraumhierarchie des Systems hinzu. Die Datei /etc/fstab beschreibt, wie mount(8) die Dateinamenshierarchie des Systems aus verschiedenen unabhangigen Dateisystemen (darunter von NFS-Servern exportierten) zusammenbauen soll. Jede Zeile in der Datei /etc/fstab beschreibt ein einzelnes Dateisystem, seinen Einhangepunkt und eine Menge an Standardeinhangeoptionen fur diesen Einhangepunkt. Fur NFS-Dateisystemeinhangungen gibt eine Zeile in der Datei /etc/fstab folgende Informationen an: den Servernamen, den Pfadnamen des exportierten und einzuhangenden Server-Verzeichnisses, das als Einhangepunkt dienende lokale Verzeichnis und eine Liste von Einhangeoptionen, die die Art des Einhangens und die Reaktion des NFS-Clients beim Zugriff auf Dateien unterhalb dieses Einhangepunktes steuern. Das funfte und sechste Feld auf jeder Zeile wird von NFS nicht verwandt und enthalt per Konvention jeweils die Ziffer Null. Beispiel: Server:Pfad /Einhangepunkt Fstype Option,Option,t0 0 Der Rechnername und die exportierten Pfadnamen werden durch einen Doppelpunkt getrennt, wahrend die Einhangeoptionen 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 mussen von einem Schnittstellenidentifikator begleitet werden. Siehe ipv6(7) fur Details zur Angabe von rohen IPv6-Adressen. Das Feld fstype enthalt >>nfs<<. Die Verwendung des Dateityps >>nfs4<< in /etc/fstab wird missbilligt. EINHANGEOPTIONEN Schauen Sie in mount(8) fur eine Beschreibung der generischen Einhangeoptionen, die fur alle Dateisysteme verfugbar sind. Falls Sie keine Einhangeoption angeben mussen, verwenden Sie die generische Option defaults in /etc/fstab. Optionen, die von allen Versionen unterstutzt werden Diese Optionen sind fur die Verwendung mit allen NFS-Versionen gultig. nfsvers=n Die NFS-Protokollnummer, die fur den Kontakt zum NFS-Dienst des Servers verwandt wird. Falls der Server die angefragte Version nicht unterstutzt, schlagt die Einhangeanfrage fehl. Falls diese Option nicht angegeben ist, versucht der Client 4.2 zuerst, handelt sich dann runter, bis er eine vom Server unterstutzte Version findet. vers=n Diese Option ist eine Alternative zu der Option nfsvers. Sie ist fur die Kompatibilitat zu anderen Betriebssystemen enthalten. soft / softerr / hard Bestimmt das Wiederherstellungsverhalten des NFS-Clients nachdem es zu einer Zeituberschreitung fur eine NFS-Anfrage kam. Falls keine Option angegeben ist (oder falls die Option hard angegeben ist), werden NFS-Anfragen unendlich oft erneut versucht. Falls entweder die Option soft oder softerr angegeben ist, lasst der NFS-Client eine NFS-Anfrage nach retrans Ubertragungsversuchen fehlschlagen. Dadurch liefert der NFS-Client den Fehler EIO (fur die Option soft) oder ETIMEDOUT (fur die Option softerr) an die aufrufende Anwendung zuruck. Nebenbemerkung: Eine sogenannte >>weiche<< Zeituberschreitung kann in bestimmten Fallen zu stiller Datenverfalschung fuhren. Verwenden Sie daher die Option soft oder softerr nur, wenn die Reaktionsfahigkeit des Clients wichtiger als die Datenintegritat ist. Die Verwendung von NFS uber TCP oder die Erhohung des Wertes der Option retrans kann einige der Risiken des Einsatzes der Option soft oder softerr verringern. softreval / nosoftreval Falls der NFS-Server nicht verfugbar ist, konnte es nutzlich sein, dass NFS-Clients Pfade und Attribute weiterhin aus dem Zwischenspeicher bereitstellen, nachdem retrans Versuche, den Zwischenspeicher erneut zu bestatigen, wegen Zeituberschreitungen fehlschlugen. Dies konnte beispielsweise hilfreich sein, wenn versucht wird, einen Dateisystembaum von einem Server, der permanent nicht verfugbar ist, auszuhangen. Es ist moglich, softreval mit der Einhangeoption soft zu kombinieren. In diesem Fall erfolgt eine Zeituberschreitung fur Aktionen, die nicht aus dem Zwischenspeicher bedient werden konnen, sowie ein Fehler nach retrans Versuchen. Die Kombination mit der Vorgabeeinhangeoption hard impliziert, dass Aktionen, die nicht im Zwischenspeicher liegen, zu Wiederholungen fuhren, bis vom Server eine Antwort erhalten wird. Hinweis: Die Vorgabeeinhangeoption ist nosoftreval. Diese erlaubt keinen Ruckgriff auf den Zwischenspeicher, wenn die Neubestatigung fehlschlagt, sondern folgt stattdessen dem durch die Einhangeoptionen hard oder soft vorgegebenen Verhalten. intr/nointr Diese Aktion wird fur Ruckwartskompatibilitat 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. Fur NFS uber TCP betragt der Standardwert fur timeo 600 (60 Sekunden). Der NFS-Client fuhrt einen linearen Ruckschritt aus: Nach jeder Neuubertragung wird die Zeituberschreitung um timeo bis zum Maximum von 600 Sekunden erhoht. Fur NFS uber UDP verwendet der Client einen adaptiven Algorithmus, um die angemessenen Werte fur eine Zeituberschreitung (Timeput) fur haufig verwandte Anfragetypen (wie READ- und WRITE-Anfragen) abzuschatzen, verwendet allerdings die Einstellung timeo fur 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 Neuubertragung verdoppelt der NFS-Client die Zeituberschreitung fur diese Anfrage bis zu einem maximalen Wert fur die Zeituberschreitung von 60 Sekunden. retrans=n Die Anzahl der Versuche, die der NFS-Client eine Anfrage erneut unternimmt, bevor er weitere Wiederherstellungsmassnahmen 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 (abhangig davon, ob die Einhangeoption 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 tatsachliche Datenmenge jeder NFS-READ-Anfrage ist identisch zu oder kleiner als die Einstellung von rsize. Die grosste von dem Linux-NFS-Client unterstutzte 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 grosser als 1048576 durch 1048576. Falls ein angegebener Wert in den unterstutzten Bereich fallt, aber kein Vielfaches von 1024 ist, wird er auf das nachste Vielfache von 1024 abgerundet. Falls der Wert rsize nicht angegeben ist oder falls der angegebene Wert fur rsize grosser als das maximale sowohl vom Server oder vom Client unterstutzte ist, handeln der Client und der Server den grossten Wert fur rsize aus, den beide unterstutzen. Die Einhangeoption 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 tatsachliche Datenmenge jeder NFS-WRITE-Anfrage ist identisch zu oder kleiner als die Einstellung von wsize. Die grosste von dem Linux-NFS-Client unterstutzte Schreibe-Datenmenge ist 1.048.576 Bytes (ein Megabyte). Ahnlich wie rsize ist der Wert von wsize ein positives, ganzzahliges Vielfaches von 1024. Werte von wsize kleiner als 1024 werden durch 4096 ersetzt; Werte grosser als 1048576 durch 1048576. Falls ein angegebener Wert in den unterstutzten Bereich fallt, aber kein Vielfaches von 1024 ist, wird er auf das nachste Vielfache von 1024 abgerundet. Falls ein Wert von wsize nicht angegeben ist oder der angegebene Wert von wsize grosser als das maximal vom Client oder Server unterstutzbare ist, werden der Client und Server den grossten Wert von wsize aushandeln, den beide unterstutzen konnen. Die Einhangeoption 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 Wahlt 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 erhohen, speichern NFS-Clients Dateiattribute zwischen. Alle paar Sekunden pruft ein NFS-Client die Version des Servers von jedem Dateiattribut auf Aktualisierungen. Anderungen, die auf dem Server innerhalb dieser kurzen Intervalle passieren, bleiben unerkannt, bis der Server durch den Client erneut gepruft wird. Die Option noac verhindert, dass Clients Dateiattribute zwischenspeichern, so dass Anwendungen schneller Dateianderungen auf dem Server erkennen konnen. Zusatzlich zur Verhinderung des Zwischenspeicherns von Dateiattributen durch den Client zwingt die Option noac Anwendungen dazu, Schreibvorgange synchron durchzufuhren, so dass lokale Anderungen an einer Datei auf dem Server sofort sichtbar werden. Damit konnen andere Clients schnell neue Schreibvorgange erkennen, wenn sie die Dateiattribute uberprufen. Die Verwendung der Option noac stellt grossere Koharenz der Zwischenspeicher unter NFS-Clients, die auf die gleiche Datei zugreifen, sicher, fuhrt aber zu einem grossen Leistungseinbruch. Stattdessen wird eine gezieltere Verwendung von Dateisperren empfohlen. Der Abschnitt DATEN- UND METADATENKOHARENZ enthalt eine detaillierte Diskussion dieses Zielkonflikts. acregmin=n Die minimale Zeit in Sekunden, die Attribute einer regularen 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 METADATENKOHARENZ fur eine komplette Besprechung des Zwischenspeicherns von Attributen. acregmax=n Die maximale Zeit in Sekunden, die Attribute einer regularen 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 METADATENKOHARENZ fur 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 METADATENKOHARENZ fur 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 METADATENKOHARENZ fur eine komplette Besprechung des Zwischenspeicherns von Attributen. actimeo=n Die Angabe von actimeo setzt die Grossen acregmin, acregmax, acdirmin und acdirmax auf den gleichen Wert. Falls diese Option nicht angegeben ist verwendet der NFS-Client die oben aufgefuhrten Vorgaben fur jede dieser Optionen. bg/fg Bestimmt, wie sich der Befehl mount(8) verhalt, falls ein Versuch des Einhangens eines exportierten Verzeichnisses fehlschlagt. Die Option fg fuhrt dazu, dass mount(8) sich mit einem Fehlerstatus beendet, falls irgend ein Teil der Einhangeanfrage in eine Zeituberschreitung lauft oder fehlschlagt. Dies wird >>Vordergrund<<-Einhangung genannt und ist das Standardverhalten, falls weder die Einhangeoption fg noch bg angegeben ist. Falls die Option bg angegeben ist, wird eine Zeituberschreitung oder ein Fehlschlag dazu fuhren, dass der Befehl mount(8) mit Fork einen Kindprozess startet, der weiter versucht, das exportierte Dateisystem einzuhangen. Der Elternprozess kommt sofort mit einem Exit-Code von Null zuruck. Dies ist als >>Hintergrund<<-Einhangung bekannt. Falls das lokale Einhangeverzeichnis fehlt, verhalt sich der Befehl mount(8), als ob eine Zeituberschreitung aufgetreten ware. Dies erlaubt in /etc/fstab angegebene verschachtelte NFS-Einhangungen in beliebiger Reihenfolge wahrend des Systemstarts fortzufahren, selbst falls einige NFS-Server noch nicht verfugbar sind. Alternativ konnen diese Probleme mit einem Selbsteinhangeprogramm angegangen werden (siehe automount(8) fur 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) ausgerustet sind, konnen mehrere Verbindungen zur Lastverteilung die Gesamtleistung erhohen. In diesen Fallen erlaubt die Option nconnect dem Benutzer die Angabe der Verbindungsanzahl, die zwischen dem Client und dem Server aufgebaut werden sollen (bis zur Begrenzung von 16). Beachten Sie, dass die Option nconnect auch bei einigen pNFS-Laufwerken zur Angabe der Anzahl der einzurichtenden Verbindungen zu den Daten-Servern verwandt werden kann. rdirplus/nordirplus Wahlt 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-Einhangungen, um kleine Verzeichnisse zu lesen. Einige Anwendungen arbeiten besser, falls der Client nur READDIR-Anfragen fur alle Verzeichnisse verwendet. retry=n Die Anzahl an Minuten, die der Befehl mount(8) versucht, eine NFS-Einhangungsaktion im Vordergrund oder im Hintergrund durchzufuhren, bevor er aufgibt. Falls diese Option nicht angegeben ist, ist der Standardwert fur Vordergrundeinhangungen 2 Minuten und fur Hintergrundeinhangungen 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 durchgefuhrten Versuche beeinflusst, nicht die durch jeden Versuch hervorgerufene Verzogerung. Fur UDP benotigt jeder Versuch die durch die Optionen timeo und retrans bestimmte Zeit, die standardmassig 7 Sekunden ist. Fur TCP ist die Vorgabe 3 Minuten, aber System-TCP-Verbindungszeituberschreitungen begrenzen manchmal die Zeituberschreitung fur jede Neuubertragung auf rund 2 Minuten. sec=Varianten Eine durch Doppelpunkt getrennte Liste von einem oder mehreren Sicherheitsvarianten, die beim Zugriff auf Dateien auf dem eingehangten Export verwandt werden sollen. Falls der Server keine dieser Varianten unterstutzt, schlagt die Einhangeaktion fehl. Falls sec= nicht angegeben ist, versucht der Client eine Sicherheitsvariante zu finden, die sowohl vom Client als auch vom Server unterstutzt wird. Gultige Varianten sind none, sys, krb5, krb5i und krb5p. Der Abschnitt SICHERHEITSBETRACHTUNGEN enthalt Details. sharecache/nosharecache Bestimmt, wie die Daten- und Attributszwischenspeicher des Clients gemeinsam benutzt werden, wenn die exportierten Verzeichnisse gleichzeitig mehr als einmal eingehangt werden. Die Verwendung des gleichen Zwischenspeichers reduziert die Speicheranforderungen auf dem Client und prasentiert Anwendungen identische Dateiinhalte, wenn auf die gleiche Datei aus der Ferne uber verschiedene Einhangepunkte aus zugegriffen wird. Falls keine der Optionen oder falls die Option sharecache angegeben ist, wird ein einzelner Zwischenspeicher fur alle Einhangepunkte, die auf den gleichen Export zugreifen, verwandt. Falls die Option nosharecache angegeben ist, dann bekommt dieser Einhangepunkt einen separaten Zwischenspeicher. Beachten Sie, dass die Einhangeoptionen von dem ersten Einhangepunkt auch fur folgende gleichzeitige Einhangungen 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 konnen. resvport/noresvport Gibt an, ob der NFS-Client einen privilegierten Quell-Port fur die Kommunikation mit dem NFS-Server fur diesen Einhangepunkt 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 unterstutzt. Die Verwendung von nichtprivilegierten Quell-Ports hilft bei der Erhohung der auf dem Client maximal erlaubten Anzahl an NFS-Einhangepunkten. Allerdings muss der NFS-Server so konfiguriert sein, dass er Clients erlaubt, sich uber nichtprivilegierte Quell-Ports zu verbinden. Der Abschnitt SICHERHEITSBETRACHTUNGEN enthalt wichtige Details. lookupcache=Modus Gibt an, wie der Kernel seinen Zwischenspeicher von Verzeichniseintragen fur einen angegebenen Einhangepunkt verwaltet. Modus kann entweder all, none, pos oder positive sein. Diese Option wird durch Kernel 2.6.28 und neuer unterstutzt. 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 Verzeichniseintragen gultig sind, bis die zwischengespeicherten Attribute des Elternverzeichnisses verfallen. Falls pos oder positive angegeben ist, nimmt der Client an, dass positive Eintrage gultig sind, bis die zwischengespeicherten Attribute des Elternverzeichnisses verfallen, uberpruft aber immer negative Eintrage, bevor eine Anwendung sie verwenden kann. Falls none angegeben ist, uberpruft der Client beide Arten von Verzeichniszwischenspeichereintragen, bevor eine Anwendung sie verwenden kann. Dies ermoglicht 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 METADATENKOHARENZ enthalt 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 /Documentation/filesystems/caching fur Details zur Einrichtung der FS-Cache-Einrichtung. Die Vorgabe ist nofsc. sloppy Die Option sloppy ist eine Alternative zur Angabe der Option >>-s<< von mount.nfs. xprtsec=Richtlinie Legt die Verwendung der Transportebenenabsicherung fest, um den NFS-Netzwerkverkehr im Auftrag dieses Einhangepunktes abzusichern. Richtlinie kann entweder none, tls oder mtls sein. Falls none angegeben ist, wird die Transportebenensicherheit zwangsweise ausgeschaltet, selbst falls der NFS-Server Transportebenensicherheit unterstutzt. Falls tls angegeben ist, verwendet der Client RPC-mit-TLS, um Vertrauenswurdigkeit wahrend der Ubertragung sicherzustellen. Falls mtls angegeben ist, verwendet der Client RPC-mit-TLS, um sich zu authentifizieren und Vertrauenswurdigkeit wahrend der Ubertragung sicherzustellen. Falls entweder tls oder mtls angegeben ist und der Server RPC-mit-TLS nicht unterstutzt oder die Authentifizierung unter Gleichrangingen fehlschlagt, schlagt der Einhangeversuch fehl. Falls die Option xprtsec= nicht festgelegt wurde, hangt das Standardverhalten von der Kernelversion ab, ist aber normalerweise zu xprtsec=none aquivalent. Optionen nur fur NFS-Version 2 und 3 Verwenden Sie diese Optionen, zusammen mit den Optionen in den obigen Unterabschnitten, nur fur NFS Version 2 und 3. proto=NetID Die NetID bestimmt den Transport, der zur Kommunikation mit dem NFS-Server verwandt wird. Verfugbare Optionen sind udp, udp6, tcp, tcp6, rdma und rdma6. Die in 6 endenden verwenden IPv6-Adressen und sind nur bei eingebauter Unterstutzung fur TI-RPC verfugbar. Die anderen verwenden IPv4-Adressen. Jedes Transportprotokoll verwendet andere Vorgaben fur die Einstellungen von retrans und timeo. Lesen Sie die Beschreibungen dieser Einhangeoptionen fur Details. Diese Einhangungsoption steuert, wie der NFS-Client Anfragen an den Server ubertragt und zusatzlich, 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 uber UDP verwenden. Falls die Einhangeoption proto nicht angegeben ist, findet der Befehl mount(8) heraus, welche Protokolle der Server unterstutzt und wahlt fur jeden Dienst ein angemessenes Protokoll. Lesen Sie den Abschnitt TRANSPORTMETHODEN fur weitere Details. udp Die Option udp ist eine Alternative zur Angabe von proto=udp. Sie ist zur Kompatibilitat mit anderen Betriebssystemen enthalten. Lesen Sie den Abschnitt TRANSPORTMETHODEN unten, bevor Sie NFS uber UDP verwenden. tcp Die Option tcp ist eine Alternative zur Angabe von proto=tcp. Sie ist zur Kompatibilitat 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 verfugbar ist, schlagt die Einhangeanfrage 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 Einhangeanfrage schlagt fehl, falls der Rpcbind-Dienst des Servers nicht verfugbar 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 verfugbar ist. mountport=n Der numerische Wert des Mountd-Ports des Servers. Falls der Mountd-Dienst des Servers nicht auf dem Port verfugbar ist, schlagt die Einhangeanfrage 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 Einhangeanfrage schlagt fehl, falls der Rpcbind-Dienst des Servers nicht verfugbar 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 verfugbar ist. Diese Option kann bei Einhangen 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 ubertragen, wenn er diese Einhangeanfrage durchfuhrt und spater, wenn der diesen Einhangepunkt aushangt. 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 Einhangen eines NFS-Servers durch eine Firewall, die bestimmte Transporte blockiert, verwendet werden. Falls es in Kombination mit der Option proto verwandt wird, konnen verschiedene Transporte fur Mountd-Anfragen und fur NFS-Anfragen angegeben werden. Falls der Mountd-Dienst des Server uber den angegebenen Transport nicht verfugbar ist, schlagt die Einhangeanfrage fehl. Lesen Sie den Abschnitt TRANSPORTMETHODEN fur Informationen, wie die Einhangeoption mountproto mit der Einhangeoption 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 lauft. mountvers=n Die fur den Kontakt zum Mountd des Servers zu verwendende PRC-Versionsnummer. Falls diese Option nicht angegeben ist, verwendet der Client eine der gewunschten NFS-Version angemessene Versionsnummer. Diese Option ist nutzlich, falls mehrere NFS-Dienste auf dem selben Rechner in der Ferne laufen. namlen=n Die maximale Lange der Pfadnamenkomponente bei dieser Einhangung. Falls diese Option nicht angegeben ist, wird die maximale Lange mit dem Server ausgehandelt. Meistens ist die maximale Lange 255 Zeichen. Einige altere Versionen von NFS unterstutzten diese Aushandlung nicht. Mittels dieser Option wird sichergestellt, dass pathconf(3) in diesen Fallen die geeignete maximale Komponentenlange an Anwendungen meldet. lock/nolock Wahlt 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 fur diesen Einhangepunkt verwandt. Beim Verwenden der Option nolock konnen Anwendungen Dateien sperren, aber diese Sperren stellen einen exklusiven Zugriff nur gegenuber 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 Einhangen von /var verwandt wird, da /var Dateien enthalt, die von der NLM-Implementierung von Linux verwandt werden. Die Verwendung der Option nolock ist auch notwendig, wenn Exporte auf NFS-Servern eingehangt werden, die das NLM-Protokoll nicht unterstutzen. cto/nocto Wahlt aus, ob die >>close-to-open<< (Schliessen-bis-Offnen) Zwischenspeicherkoharenzsemantik verwandt wird. Falls keine Option (oder falls cto) angegeben ist, verwendet der Client >>close-to-open<<-Zwischenspeicherkoharenzsemantik. Falls die Option nocto angegeben ist, verwendet der Client eine nicht standardisierte Heuristik, um zu bestimmen, wann sich Dateien auf dem Server geandert haben. Der Einsatz der Option nocto kann die Leistung fur rein-lesbare Einhangungen erhohen. Er sollte aber nur verwandt werden, wenn sich die Daten auf dem Server nur gelegentlich andern. Der Abschnitt DATEN- UND METADATENKOHARENZ enthalt eine detailliertere Diskussion des Verhaltens dieser Option. acl/noacl Wahlt aus, ob bei diesem Einhangepunkt das NFSACL-Seitenbandprotokoll verwandt werden soll. Das NFSACL-Seitenbandprotokoll ist ein in Solaris implementiertes proprietares 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 unterstutzt wird und verwendet es, falls der Server es unterstutzt. Falls die Aushandlung zu Problemen auf dem Client oder Server fuhrt, konnte die Deaktivierung des NFSACL-Seitenbandprotokolls notwendig sein. Der Abschnitt SICHERHEITSBETRACHTUNGEN enthalt weitere Details. local_lock=Mechanismus Gibt an, ob lokale Sperren fur 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 unterstutzt. Der Linux-NFS-Client bietet eine Moglichkeit, Sperren lokal durchzufuhren. Das bedeutet, dass Anwendungen Dateien sperren konnen. Allerdings bieten solche Sperren nur Ausschlussrechte gegenuber 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 herkommliches Flock-Verhalten zu unterstutzen, das dem von NFS-Clients < 2.6.12 ahnlich ist, benutzen Sie >>local_lock=flock<<. Diese Option wird benotigt, wenn NFS-Einhangungen uber 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 fuhren. Hinweis: Falls sie zusammen verwandt werden, wird die Einhangeoption >>local_lock<< durch die Einhangeoption >>nolock<>lock<< ausser Kraft gesetzt. Optionen nur fur NFS-Version 4 Verwenden Sie diese Optionen zusammen mit den Optionen in dem ersten obigen Unterabschnitt fur NFS-Version 4 oder neuer. proto=NetID netid bestimmt den Transport, der fur die Kommunikation mit dem NFS-Server verwandt wird. Unterstutzte Optionen sind tcp, tcp6, rdma und rdma6. tcp6 verwendet IPv6-Adressen und ist nur verfugbar, falls Unterstutzung fur TI-RPC eingebaut ist. Die beiden anderen verwenden IPv4-Adressen. Alle NFS-Version-4-Server mussen TCP unterstutzen. Daher verwendet der NFS-Version-4-Client das TCP-Protokoll, falls diese Option nicht angegeben ist. Lesen Sie den Abschnitt TRANSPORTMETHODEN fur weitere Details. minorversion=n Gibt die Unterversionsnummer des Protokolls an. NFSv4 fuhrt >>Unterversionen<< ein, bei denen NFS-Protokollerweiterungen ohne Erhohung der NFS-Protokollversionsnummer eingefuhrt werden konnen. 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 Funktionalitaten, 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 verfugbar ist, schlagt die Einhangeanfrage fehl. Falls diese Einhangeoption nicht angegeben ist, verwendet der NFS-Client die Standard-Portnummer 2049, ohne erst den Rpcbind-Dienst des Servers zu prufen. 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 Einhangeanfrage schlagt fehl, falls der Rpcbind-Dienst des Servers nicht verfugbar, der NFS-Dienst nicht in dem Rpcbind-Dienst registriert oder der NFS-Dienst auf dem bekanntgegebenen Port nicht verfugbar ist. cto/nocto Wahlt aus, ob fur diesen Einhangepunkt >>close-to-open<<-Zwischenspeicherkoharenzsemantik fur NFS-Verzeichnisse verwandt wird. Falls weder cto noch nocto angegeben sind, ist die Vorgabe, >>close-to-open<<-Zwischenspeicherkoharenzsemantik fur Verzeichnisse zu verwenden. Das Zwischenspeichern von Dateidaten wird durch diese Option nicht beeinflusst. Der Abschnitt DATEN- UND METADATENKOHARENZ enthalt 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-Ruckrufanfrage fur Dateien auf diesem Einhangepunkt durchzufuhren, an. Falls der Server keine Ruckrufverbindungen zu Clients aufbauen kann, kann sich die Leistung verringern oder Dateizugriffe konnen zeitweise hangen. Ein Wert von IPv4_ANY (0.0.0.0) oder aquivalente IP6-any-Adresse kann angegeben werden. Damit wird dem NFS-Server signalisiert, dass dieser NFS-Client keine Delegationen mochte. Falls diese Option nicht angegeben ist, versucht der Befehl mount(8) die geeigneten Ruckrufadressen automatisch zu ermitteln. Dieser automatische Ermittlungsprozess ist allerdings nicht perfekt. Falls mehrere Client-Netzschnittstellen, spezielle Routing-Optionen oder atypische Netztopologien vorhanden sind, ist es moglicherweise nicht trivial, die genaue Adresse fur Ruckrufe zu ermitteln. NFS-Protokollversionen 4.1 und 4.2 verwenden Client-etablierte TCP-Verbindungen fur Ruckrufanfragen und benotigen daher nicht, dass sich der Server mit dem Client verbindet. Diese Option betrifft daher nur NFS-Version-4.0-Einhangungen. migration/nomigration Wahlt aus, ob der Client eine Identifizierungszeichenkette verwendet, die mit dem >>NFSv4 Transparent State Migration (TSM)<< kompatibel ist. Falls der eingehangte Server NFSv4-Migration mit TSM unterstutzt, geben Sie die Option migration an. Einige Server-Funktionalitaten funktionieren im Angesicht einer Migrations-kompatiblen Identifizierungszeichenkette nicht richtig. Die Option nomigration erhalt 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 konnen nicht transparent migriert werden, wenn er sich selbst mit einer traditionellen Identifizierungszeichenkette identifiziert. Diese Einhangeoption hat bei NFSv4-Versionen, deren Unternummer grosser als Null ist, keinen Effekt. Bei diesen wird immer eine TSM-kompatible Identifizierungszeichenkette verwandt. max_connect=n Wahrend nconnect eine Begrenzung fur die Anzahl der Verbindungen setzt, die mit einer angegeben Server-IP etabliert werden konnen, erlaubt die Option max_connect dem Benutzer, die maximale Anzahl an Verbindungen an verschiedene Server-IPs, die zum gleichen NFSv4.1+-Server gehoren (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 verfugbaren Transporte fur diesen RPC-Client hinzufugen, statt den neu erstellten Netzwerktransport zu verwerfen. trunkdiscovery / notrunkdiscovery Wenn der Client ein neues Dateisystem auf einem NFSv4.1+-Server entdeckt, wird die Einhangeoption trunkdiscovery ihn dazu veranlassen, ein GETATTR fur das Attribut fs_locations zu senden. Falls er eine Antwort erhalt, deren Lange nicht Null ist, wird er durch die Antwort durchlaufen und fur jeden Serverort eine Verbindung etablieren, eine EXCHANGE_ID senden und auf Sitzungsbundelung prufen. Falls der Bundelungstest erfolgreich ist, wird die Verbindung zu der bestehenden Gruppe an Transporten fur den Server hinzugefugt, abhangig von der in der Option max_connect festgelegten Begrenzung. Die Vorgabe ist notrunkdiscovery. NFS4-DATEISYSTEMTYP Der Dateisystemtyp nfs4 ist eine alte Syntax fur die Angabe der Verwendung von NFSv4. Er kann noch mit allen NFSv4-spezifischen und allgemeinen Optionen ausser der nfsvers-Einhangeoption verwandt werden. EINHANGEKONFIGURATIONSDATEI Falls der Befehl >>mount<< entsprechend konfiguriert ist, konnen alle in den vorhergehenden Kapiteln beschriebenen Einhangeoptionen auch in der Datei /etc/nfsmount.conf konfiguriert werden. Siehe nfsmount.conf(5) fur Details. BEISPIELE Um mit NFS-Version 3 einzuhangen, verwenden Sie den nfs-Dateisystemtyp und geben Sie die Einhangeoption nfsvers=3 an. Um mit NFS-Version 4 einzuhangen, verwenden Sie entweder den nfs-Dateisystemtyp mit der Einhangeoption nfsvers=4 oder den Dateisystemtyp nfs4. Das folgende Beispiel aus der Datei /etc/fstab fuhrt dazu, dass der Befehl >>mount<< vernunftige Vorgaben fur das NFS-Verhalten aushandelt. server:/export /mnt nfs defaults 0 0 Dieses Beispiel zeigt, wie NFS-Version 4 uber TCP mit Kerberos 5 gegenseitiger Authentifizierung einzuhangen ist: server:/export /mnt nfs4 sec=krb5 0 0 Dieses Beispiel zeigt, wie NFS-Version 4 uber TCP mit Kerberos 5 Datenschutz- oder Datenintegritatsmodus einzuhangen ist: server:/export /mnt nfs4 sec=krb5p:krb5i 0 0 Dieses Beispiel kann zum Einhangen von /usr uber 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 eingehangt 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, kummert sich um die Authentifizierung pro Anfrage, passt Anfrageparameter auf verschiedene Byte-Endianess auf dem Client und Server an und ubertragt Anfragen erneut, die im Netz oder auf dem Server verloren gegangen sind. RPC-Anfragen und -Antworten fliessen uber einen Netztransport. Meistens kann der Befehl mount(8), der NFS-Client und der NFS-Server die korrekten Transport- und Datentransfergrosseneinstellungen fur einen Einhangepunkt automatisch aushandeln. In einigen Fallen lohnt es sich aber, diese Einstellungen explizit mit Einhangeoptionen anzugeben. Traditionell verwenden NFS-Clients exklusiv den UDP-Transport fur die Ubertragung von Anfragen an Server. Obwohl die Implementierung einfach ist, hat NFS uber UDP viele Einschrankungen, die einen reibungslosen Betrieb und gute Leistung in einigen typischen Einsatzumgebungen verhindern. Selbst ein unbedeutender Paketverlust fuhrt zu dem Verlust ganzer NFS-Anfragen. Daher sind Neuubertragungszeituberschreitungen normalerweise im Subsekundenbereich, damit Clients sich schnell von verlorengegangenen Anfragen erholen konnen. Dies kann aber zu zusatzlichem Netzverkehr und Serverlast fuhren. UDP kann jedoch in spezialisierten Einstellungen ziemlich effektiv sein, bei denen die MTU des Netzes im Vergleich zur Datentransfergrosse von NFS gross ist (wie in Netzwerkumgebungen, die Jumbo-Ethernet-Frames aktivieren). In derartigen Umgebungen wird empfohlen, die Einstellungen rsize und wsize so einzuschranken, 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-Grosse zum Verlust einer ganzen grossen Lese- oder Schreibabfrage fuhrt. 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 Netzunzuverlassigkeit hervorgerufene Datenverfalschung. TCP ist oft eine Voraussetzung, um einen Server durch eine Firewall einzuhangen. Unter normalen Umstanden verwirft das Netz viel haufiger Pakete, als dies der NFS-Server tut. Daher ist eine aggressive Zeituberschreitung fur die Wiederubertragung unnotig. Typische Einstellungen fur die Zeituberschreitung fur NFS uber TCP liegen zwischen einer und zehn Minuten. Nachdem ein Client seine Neuubertragungen (dem Wert der Einhangeoption retrans) ausgeschopft 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 fur zuverlassigen Datentransfer sorgt, konnen rsize und wsize standardmassig auf die grossten Werte erlaubt werden, die vom Client und Server unterstutzt werden, unabhangig von der MTU-Grosse des Netzes. Verwendung der Einhangeoption >>mountproto<< Dieser Abschnitt betrifft nur NFS-Version-3-Einhangungen, da NFS Version 4 kein separates Protokoll fur Einhangeanfragen 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 hangt von den Einstellungen der Transporteinhangeoptionen ab, zu denen proto, mountproto, udp und tcp gehoren. Der Client schickt >>Network Status Manager (NSM)<<-Benachrichtigungen uber UDP unabhangig 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 standardmassig UDP, um den Mountd-Dienst des Servers zu kontaktieren und TCP, um seine NLM- und NFS-Dienste zu kontaktieren. Falls der Server diese Transporte fur diese Dienste nicht unterstutzt, versucht der Befehl mount(8) herauszufinden, was der Server unterstutzt und versucht dann, die Einhangeanfrage erneut mit den herausgefundenen Transporten. Falls der Server keine vom Client unterstutzten Transporte bekanntgibt, schlagt die Einhangeanfrage fehl. Falls die Option bg benutzt wird, bringt sich der Einhangebefehl in den Hintergrund und versucht die angegebene Einhangeanfragen weiter. Wenn die Option proto, die Option udp oder die Option tcp aber nicht die Option mountproto angegeben ist, wird der angegebene Transport sowohl fur den Kontakt zum Mountd-Dienst des Servers als auch fur die NLM- und NFS-Dienste benutzt. Falls die Option mountproto aber keine der Optionen proto, udp oder tcp angegeben sind, wird der angegebene Transport fur die initiale Mountd-Anfrage verwandt, der Befehl mount versucht aber zu ermitteln, was der Server fur das NFS-Protokoll unterstutzt. Dabei bevorzugt er TCP, falls beide Transporte unterstutzt werden. Falls beide Option mountproto und proto (oder udp oder tcp) angegeben sind dann wird der mit der Option mountproto angegebene Transport fur die anfangliche Mountd-Anfrage und der mit der Option proto (oder den Optionen udp oder tcp) angegebene Transport fur NFS verwandt, unabhangig 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 uber UDP auf Hochgeschwindigkeitsverbindungen Die Verwendung von NFS uber UDP auf Hochgeschwindigkeitsverbindungen wie Gigabit kann ohne Ruckmeldung zu Datenverfalschung fuhren. Das Problem kann durch hohe Lasten ausgelost werden und wird durch Probleme in dem IP-Fragment-Wiederzusammenbau verursacht. NFS-Lese- und Schreibvorgange ubertragen typischerweise UDP-Pakete von 4 Kilobyte oder mehr, die in mehrere Fragmente zerteilt werden mussen, damit sie uber eine Ethernet-Verbindung ubertragen werden konnen, da diese standardmassig Pakete auf 1500 byte begrenzt. Dieser Prozess passiert in der IP-Netzschicht und wird Fragmentierung genannt. Um zusammengehorige 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 ursprungliche UDP-Paket entsteht. Dieser Prozess heisst Wiederzusammenbau. Die Standardzeituberschreitung fur den Paketwiederzusammenbau ist 30 Sekunden. Falls der Netzwerkstapel nicht alle Fragmente fur ein bestimmtes Paket innerhalb dieses Intervalls erhalt, nimmt er an, dass fehlende Fragmente verloren gegangen sind und verwirft die bereits empfangenen. Dies erzeugt bei Hochgeschwindigkeitsverbindungen ein Problem, da es moglich ist, mehr als 65536 Pakete innerhalb von 30 Sekunden zu ubertragen. Tatsachlich kann bei umfangreichem NFS-Verkehr beobachtet werden, dass sich die IP-Kennungen nach rund 5 Sekunden wiederholen. Das hat ernsthafte Effekte fur den Wiederzusammenbau: Falls ein Fragment verloren geht und ein anderes Fragment von einem anderen Paket mit der gleichen IP-Kennung innerhalb der 30-Sekunden-Zeituberschreitung 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-Prufsumme, eine 16-Bit-Prufsumme, normalerweise nicht korrekt sein und UDP wird das defekte Paket verwerfen. Allerdings ist die UDP-Prufsumme nur 16 Bit, so dass es eine Moglichkeit von 1 in 65536 gibt, dass die Prufsumme passt, obwohl der Nutzinhalt vollkommen zufallig ist (was allerdings sehr oft nicht der Fall ist). Trifft dies zu, dann sind Daten ohne Ruckmeldung defekt. Diese Moglichkeit 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 langer als 30 Sekunden betragen wird. Es wird daher nachdrucklich empfohlen, wo moglich NFS uber TCP zu verwenden, da TCP keine Fragmentierung durchfuhrt. Wenn Sie unbedingt NFS uber UDP uber Gigabit-Ethernet verwenden mussen, konnen ein paar Dinge unternommen werden, um dem Problem entgegen zu wirken und die Wahrscheinlichkeit fur Verfalschungen zu reduzieren: Jumbo Frames: Viele Gigabit-Netzkarten sind in der Lage, Frames grosser als die Begrenzung des traditionellen Ethernet von 1500 byte zu ubertragen, typischerweise 9000 bytes. Werden Jumbo Frames von 9000 bytes verwandt, kann NFS uber UDP mit Seitengrossen von 8 K ohne Fragmentierung betrieben werden. Naturlich ist das nur moglich, falls alle beteiligten Stationen Jumbo Frames unterstutzen. Um einer Maschine auf Karten, die das unterstutzen, zu ermoglichen, Jumbo Frames zu versenden, reicht es aus, die Schnittstelle fur einen MTU-Wert von 9000 zu konfigurieren. Niederigere Zeituberschreitung fur den Wiederzusammenbau: Durch Absenken dieser Zeituberschreitung unter die Zeit, die fur den IP-Kennungszahlerumlauf benotigt wird, kann auch der fehlerhafte Wiederzusammenbau der Fragmente vermieden werden. Um dies zu erreichen, schreiben Sie den neuen Zeituberschreitungswert (in Sekunden) in die Datei /proc/sys/net/ipv4/ipfrag_time. Ein Wert von 2 Sekunden reduziert die Wahrscheinlichkeit von IP-Kennungszusammenstossen auf einer einzelnen Gigabit-Verbindung deutlich, erlaubt dabei aber auch noch eine vernunftige Zeituberschreitung beim Empfang von fragmentiertem Verkehr von weit entfernten Teilnehmern. DATEN- UND METADATENKOHARENZ Einige moderne Cluster-Dateisysteme stellen zwischen ihren Clients eine perfekte Zwischenspeicherkoharenz bereit. Es ist sehr teuer, eine perfekte Zwischenspeicherkoharenz zwischen verteilten NFS-Clients zu erreichen, besonders auf Weitverkehrsnetzen. Daher belasst es NFS bei einer schwacheren Zwischenspeicherkoharenz, die die Anforderungen der meisten gemeinsamen Dateinutzungsarten erfullt. >>close-to-open<<-Zwischenspeicherkoharenzsemantik Typischerweise erfolgt das gemeinsame Benutzen von Dateien sequenziell. Zuerst offnet Client A eine Datei, schreibt etwas hinein und schliesst sie dann. Danach offnet Client B die gleiche Datei und liest die Anderungen. Wenn eine Anwendung eine auf einem NFS-3-Server gespeicherte Datei offnet, uberpruft der NFS-Client, ob die Datei noch auf dem Server existiert und dem Offner erlaubt ist, indem er eine Anfrage GETATTR oder ACCESS sendet. Der NFS-Client sendet diese Anfragen unabhangig von der Frische der zwischengespeicherten Attribute der Datei. Wenn die Anwendung die Datei schliesst, schreibt der NFS-Client alle anhangenden Anderungen an der Datei zuruck, so dass der nachste Offner die Anderungen sehen kann. Dieses gibt dem NFS-Client eine Moglichkeit, alle Schreibfehler mittels des Ruckgabewerts von close(2) mitzuteilen. Das Verhalten der Prufung zum Zeitpunkt des Offnens und des Ruckschreibens zum Zeitpunkt des Schliessens wird als >>close-to-open<<-Zwischenspeicherkoharenzsemantik oder CTO bezeichnet. Sie kann fur einen gesamten Einhangepunkt mit der Einhangeoption nocto deaktiviert werden. Schwache Zwischenspeicherkoharenz Es gibt immer noch Moglichkeiten fur den Zwischenspeicher des Clients, abgelaufene Daten zu enthalten. Das NFS-Version-3-Protokoll fuhrt die >>schwache Zwischenspeicherkoharenz<< ein (auch als WCC bekannt), die einen Weg beschreibt, mit der die Dateiattribute vor und nach einer Anfrage effizient uberpruft werden konnen. Dies hilft einem Client, Anderungen, die durch andere Clients vorgenommen worden sein konnten, zu identifizieren. Wenn ein Client viele parallele Aktionen einsetzt, die die gleiche Datei zur gleichen Zeit aktualisieren (beispielsweise wahrend asynchronem verzogertem Schreiben), ist es immer noch schwierig, zu entscheiden, ob es diese Aktualisierungen des Clients oder Aktualisierungen auf einem anderen Client waren, die die Datei veranderten. Attribut-Zwischenspeicherung Verwenden Sie die Einhangeoption noac, um die Zwischenspeicherkoharenz fur Attribute zwischen mehreren Clients zu erreichen. Fast jede Dateisystemaktion pruft Dateiattributinformationen. Die Clients halten diese Informationen fur eine bestimmte Zeit im Zwischenspeicher, um Netz- und Server-Last zu reduzieren. Wenn noac aktiv ist, ist der Zwischenspeicher des Clients fur Dateiattribute deaktiviert und daher muss jede Aktion, die die Dateiattribute pruft, zwingend zum Server gehen. Dies ermoglicht es einem Client, Anderungen sehr schnell zu erkennen, fuhrt aber zu vielen zusatzlichen Netzaktionen. Achtung: Verwechseln Sie die Option noac nicht mit >>keine Daten-Zwischenspeicherung<<. Die Einhangeoption noac hindert den Client daran, die Dateimetadaten zwischenzuspeichern, aber es gibt immer noch Ressourcenwettlaufe, die zu Daten-Zwischenspeicher-Inkoharenzen zwischen Client und Server fuhren konnen. Das NFS-Protokoll wurde nicht entwickelt, um echte Cluster-Dateisystem-Zwischenspeicherkoharenz zu unterstutzen, ohne dass die Anwendungen eine Art von Serialisierung unterstutzen. Falls zwischen den Clients eine absolute Zwischenspeicherkoharenz benotigt wird, sollten die Anwendungen das Sperren von Dateien einsetzen. Alternativ konnen Anwendungen ihre Dateien auch mit dem Schalter O_DIRECT offnen, um das Zwischenspeichern der Daten komplett zu deaktivieren. Dateizeitstempelverwaltung NFS-Server sind dafur 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 waren. 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 Verzogerungen kommen, bevor eine Zeitstempelaktualisierung auf dem NFS-Server fur Anwendungen auf NFS-Clients sichtbar wird. Um den POSIX-Dateisystemstandard zu erfullen, verlasst 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 Datenanderungen 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 tatsachlich verwaltet wird. Aufgrund dieses Zwischenspeicherverhaltens unterstutzt der Linux-NFS-Client nicht die generischen Atime-bezogenen Einhangeoptionen. Siehe mount(8) fur Details uber diese Optionen. Insbesondere haben die Einhangeoptionen atime/noatime, diratime/nodiratime, relatime/norelatime und strictatime/nostrictatime auf NFS-Einhangungen keinen Effekt. /proc/mounts konnte berichten, dass die Einhangeoption relatime auf NFS-Einhangungen gesetzt ist, aber tatsachlich sind die atime-Semantiken immer wie hier beschrieben und nicht wie die relatime-Semantik. Zwischenspeicherung von Verzeichniseintragen Der Linux-NFS-Client-Zwischenspeicher ist das Ergebnis aller >>NFS LOOKUP<<-Anfragen. Falls die angefragten Verzeichniseintrage 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 zurucklieferte), wird das Ergebnis als negatives Abfrageergebnis bezeichnet. Um zu erkennen, wann Verzeichniseintrage auf dem Server hinzugefugt oder dort entfernt wurden, uberwacht der Linux-NFS-Client die Mtime eines Verzeichnisses. Falls der Client eine Anderung in der Mtime des Verzeichnisses erkennt, beseitigt der Client alle zwischengespeicherten LOOKUP-Ergebnisse fur dieses Verzeichnis. Da die Mtime des Verzeichnisses ein zwischengespeichertes Attribut ist, kann es einige Zeit dauern, bis der Client eine Anderung bemerkt. Siehe die Beschreibung der Einhangeoptionen acdirmin, acdirmax und noac fur weitere Informationen daruber, wie lange die Mtime eines Verzeichnisses zwischengespeichert wird. Das Zwischenspeichern von Verzeichniseintragen verbessert die Leistung von Anwendungen, die Dateien nicht mit Anwendungen auf anderen Clients gemeinsam nutzen. Die Verwendung von zwischengespeicherten Informationen uber Verzeichnisse kann allerdings Anwendungen durcheinanderbringen, die parallel auf mehreren Clients laufen und die die Erstellung und Entfernung von Dateien schnell erkennen mussen. Die Einhangeoption lookupcache erlaubt teilweise das Einstellen des Verhaltens der Verzeichniseintragszwischenspeicherung. Vor Kernelveroffentlichung 2.6.28 verfolgte der Linux-NFS-Client nur positive Abfrageergebnisse. Dies ermoglichte Anwendungen, neue Verzeichniseintrage, die von anderen Clients erstellt wurden, schnell zu erkennen, und dabei immer noch einige der Leistungsvorteile des Zwischenspeichers zu geniessen. Falls eine Anwendung von dem vorherigen Abfrageverhalten des Linux-NFS-Clients abhangt, konnen Sie lookupcache=positive verwenden. Falls der Client seinen Zwischenspeicher ignoriert und jede Anwendungsnachschlageanfrage beim Server uberpruft, kann der Client sofort erkennen, wenn ein neuer Verzeichniseintrag durch einen anderen Client entweder erstellt oder entfernt wurde. Sie konnen dieses Verhalten mittels lookupcache=none festlegen. Die zusatzlichen NFS-Anfragen, die benotigt werden, falls der Client Verzeichniseintrage nicht zwischenspeichert, kann eine Leistungseinbusse zur Folge haben. Deaktivieren des Zwischenspeicherns der Nachfragen sollte zu einer geringeren Leistungseinbusse fuhren als die Verwendung von noac und hat keinen Effekt darauf, wie der NFS-Client die Attribute von Dateien zwischenspeichert. Die Einhangeoption >>sync<< Der NFS-Client behandelt die Einhangeoption sync anders als einige andere Dateisysteme (lesen Sie mount(8) fur eine Beschreibung der generischen Einhangeoptionen sync und async). Falls weder sync noch async angegeben ist (oder falls die Option async angegeben wurde) verzogert der NFS-Client das Versenden von Schreibanforderungen von Anwendungen an den Server, bis eines der folgenden Ereignisse auftritt: Speicherdruck erzwingt die Zuruckgewinnung von Systemspeicherressourcen. Eine Anwendung schiebt explizit die Dateidaten mit sync(2), msync(2) oder fsync(3) raus. Eine Anwendung schliesst eine Datei mit close(2). Die Datei wird mittels fcntl(2) gesperrt/entsperrt. Mit anderen Worten, unter normalen Bedingungen konnen von einer Anwendung geschriebene Daten nicht sofort auf dem Server, der die Datei beherbergt, auftauchen. Falls die Option sync am Einhangepunkt angegeben wurde, werden bei jedem Systemaufruf, der Daten in Dateien unter diesem Einhangepunkt schreibt, diese erst auf den Server geschrieben, bevor der Systemaufruf die Steuerung an den Benutzerraum zuruckgibt. Damit wird grossere Datenzwischenspeicherkoharenz unter den Clients erreicht, allerdings unter signifikanten Leitungseinbussen. Anwendungen konnen den Schalter >>O_SYNC<< von open verwenden, um zu erzwingen, dass Schreibanforderungen von Anwendungen fur bestimmte Dateien sofort an den Server gesandt werden, ohne die Einhangeoption 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 unterstutzen, ist ein zweites Seitenbandprotokoll - bekannt als >>Network Status Manager<<-Protokoll - notwendig. In NFS Version 4 wird das Sperren direkt im Haupt-NFS-Protokoll unterstutzt und die NLM- und NSM-Seitenbandprotokolle werden nicht verwandt. Meistens werden die Dienste NLM und NSM automatisch gestartet und es wird keine spezielle Konfiguration benotigt. Konfigurieren Sie alle NFS-Clients mit den vollqualifizierten Rechnernamen, um sicherzustellen, dass NFS-Server die Clients finden und sie uber Server-Neustarts informieren konnen. NLM unterstutzt 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 unterstutzen, oder wenn von einem NFS-Server durch eine Firewall, die den NLM-Dienste-Port blockiert, eingehangt wird, dann verwenden Sie die Einhangeoption nolock. NLM-Sperren mussen mit der Option nolock ausgeschaltet werden, wenn /var mit NFS verwandt wird, da /var Dateien enthalt, die von der NLM-Implementierung unter Linux verwandt werden. Es wird auch empfohlen, die Option nolock zu verwenden, um die Leistung von proprietaren Anwendungen, die auf einem einzelnen Client laufen und extensiv Dateisperren verwenden, zu verbessern. Zwischenspeicherfunktionalitaten in NFS Version 4 Das Zwischenspeicherverhalten fur Daten und Metadaten bei Clients der NFS-Version 4 ist ahnlich zu dem von alteren Versionen. Allerdings fugt NFS Version 4 zwei Funktionalitaten hinzu, die das Zwischenspeicherverhalten verbessern: Attributanderung und Datei-Delegation. Die Attributanderung ist ein neuer Teil der NFS-Datei- und -Verzeichnis-Metadaten, die Anderungen nachverfolgt. Sie ersetzt die Verwendung von Zeitstempeln der Dateianderung, um Clients zu ermoglichen, die Gultigkeit der Inhalte ihrer Zwischenspeicher zu uberprufen. Attributanderungen sind allerdings unabhangig von der Zeitstempelauflosung 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 temporar so zu behandeln, als ob kein anderer Client darauf zugreifen wurde. Der Server verspricht dem Client, ihn zu benachrichtigen (mittels einer Ruckrufanfrage), 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 uber jeden anderen Client informiert, der in die Datei schreiben mochte. Eine write-Delegation bedeutet, dass der Client sowohl uber Lese- als auch Schreibzugreifende informiert wird. Server gewahren Datei-Delegationen, wenn eine Datei geoffnet wird und konnen diese jederzeit zuruckfordern, wenn ein anderer Client auf die Datei zugreifen mochte und dies im Widerspruch zu bereits gewahrten Delegationen steht. Delegationen von Verzeichnissen werden nicht unterstutzt. Um Delegations-Ruckrufe zu unterstutzen, pruft der Server wahrend des ursprunglichen Kontakts des Clients mit dem Server den Ruckkehrpfad zum Client. Falls der Kontakt mit dem Client nicht aufgebaut werden kann, gewahrt der Server einfach diesem Client keine Delegationen. SICHERHEITSBETRACHTUNGEN NFS-Server steuern den Zugriff auf Dateidaten, sie hangen 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 (gewohnlich 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 konnte. Typischerweise erscheinen Dateidaten- und Benutzerkennungswerte unverschlusselt (d.h. im Klartext) im Netz. Desweiteren verwenden NFS-Version 2 und 3 separate Seitenbandprotokolle zum Einhangen, 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 fuhrt zusatzlich fortschrittlichere Formen der Zugriffssteuerung, Authentifizierung und des Ubertragungsdatenschutzes ein. Die NFS-Version-4-Spezifikation verlangt starke Authentifizierung und Sicherheitsvarianten, die pro-RPC-Integritatsprufungen und Verschlusselung bereitstellen. Da NFS Version 4 die Funktionen der Seitenbandprotokolle in das Haupt-NFS-Protokoll integriert, gelten die neuen Sicherheitsfunktionalitaten fur alle NFS-Version-4-Aktionen inklusive Einhangen, Dateisperren und so weiter. RPCGSS-Authentifizierung kann auch mit NFS-Version 2 und 3 verwandt werden, allerdings schutzt es nicht ihre Seitenbandprotokolle. Die Einhangeoption sec legt die Sicherheitsvariante fest, die fur Aktionen im Auftrag von Benutzern auf diesem NFS-Einhangepunkt gelten. Die Verwendung von sec=krb5 liefert einen kryptographischen Nachweis der Identitat in jeder RPC-Anfrage. Dies stellt eine starke Uberprufung der Identitat des Benutzers, der auf Daten auf dem Server zugreift, dar. Beachten Sie, dass neben der Hinzunahme dieser Einhangeoption weitere Konfiguration benotigt wird, um Kerberos-Sicherheit zu aktivieren. Lesen Sie die Handbuchseite rpc.gssd(8) fur weitere Details. Zwei zusatzliche Varianten der Kerberos-Sicherheit werden unterstutzt: krb5i und krb5p. Die Sicherheitsvariante krb5i stellt eine kryptographisch starke Garantie dar, dass keine RPC-Anfrage verandert wurde. Die Sicherheitsvariante krb5p verschlusselt jede RPC-Anfrage, um Datenoffenlegung wahrend der Netzubertragung zu verhindern, allerdings mussen Sie Leistungseinbussen erwarten, wenn Sie Integritatsprufung oder Verschlusselung verwenden. Ahnliche Unterstutzung fur weitere Formen der kryptographischen Sicherheit sind ebenfalls verfugbar. 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 gewahrt. Sobald die Ausleihe ablauft, darf der Server diese Sperren zuruckziehen. Clients erneuern ihre Ausleihe periodisch, um die Zuruckziehung 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, lost der Server alle offenen und Sperrzustande, 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-Identitatszeichenkette mit dem Modulparameter nfs4.nfs4_unique_id erganzen, 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 Identitatszeichenkette 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 Einhangepunkts durchgefuhrt, sondern fur den Client, dem die Ausleihe gehort. Ein Client verwendet eine konsistente Identitatszeichenkette, Sicherheitsvariante und Principal auch uber 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 fur seine Ausleih-Verwaltungsaktionen zu verwenden. Kerberos bietet sichere Authentifizierung jedes Clients an. Standardmassig verwendet der Client fur 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 Schlusseltabelle oder die benotigten Server-Principals hat, verwendet der Client AUTH_SYS und UID 0 fur die Ausleih-Verwaltung. Verwendung nichtprivilegierter Quell-Ports NFS-Clients kommunizieren normalerweise uber 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 fur seine Sockets auswahlen, nimmt aber gewohnlich 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 auswahlbaren privilegierten Quell-Ports wird durch ein Sysctl-Paar ausgewahlt, um gut bekannte Ports zu vermeiden, wie den von SSH verwandten Port. Das bedeutet, dass die Anzahl der fur den NFS-Client verfugbaren Quell-Ports und damit die Anzahl der Socket-Verbindungen, die gleichzeitig verwandt werden konnen, praktisch auf nur einige Hundert begrenzt ist. Wie oben beschrieben, verlasst 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 Autoritat uberpruft wurde, falls die Verbindung von einem privilegierten Port kommt. Dieses System ist leicht zu tauschen, aber in vertrauenswurdigen physischen Netzen zwischen vertrauenswurdigen Rechnern ist es vollkommen angemessen. Grob gesprochen wird ein Socket fur jeden NFS-Einhangepunkt verwandt. Falls ein Client auch nichtprivilegierte Quell-Ports verwenden konnte, ware die Anzahl der erlaubten Sockets und damit die maximale Anzahl an gleichzeitigen Einhangepunkten viel grosser. Die Verwendung nichtprivilegierter Quell-Ports konnte die Server-Sicherheit etwas beeintrachtigen, da jeder Benutzer auf AUTH_SYS-Einhangepunkten bei NFS-Anfragen jetzt vorgeben kann, ein beliebiger anderer zu sein. Daher unterstutzen NFS-Server dies standardmassig nicht. Normalerweise erlauben sie dies uber eine explizite Export-Option. Um gute Sicherheit zu wahren und gleichzeitig so viele Einhangepunkte wie moglich zu erlauben, ist es am besten, nichtprivilegierte Ports nur zu erlauben, falls der Server und der Client beide eine starke Authentifizierung wie Kerberos verlangen. Einhangen durch eine Firewall Eine Firewall konnte zwischen einem NFS-Client und -Server liegen, oder der Client oder der Server konnte einige seiner eigenen Ports uber IP-Filterregeln blockieren. Es ist weiterhin moglich, einen NFS-Server durch eine Firewall einzuhangen, allerdings konnten einige der automatischen Serverendpunktentdeckungsmechanismen des Befehls mount(8) nicht funktionieren. Daher mussen Sie dann spezifische Endpunktdetails uber NFS-Einhangeoptionen 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 unterstutzt Der Rpcbind-Daemon verwendet eine gut bekannte Port-Nummer (111), damit Clients einen Diensteendpunkt finden. Obwohl NFS oft eine Standard-Port-Nummer (2049) verwendet, konnen Hilfsdienste wie der NLM-Dienst jede unbenutzte Port-Nummer zufallig auswahlen. 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 fur 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 proprietare Seitenbandprotokoll namens NFSACL stellt eine umfassendere Zugriffssteuerung als die Modusbits bereit. Linux implementiert dieses Protokoll zur Kompatibilitat 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 Ubersetzung zwischen den beiden in Umgebungen, die POSIX ACLs und NFS Version 4 vermischen, notwendig. DIE OPTION REMOUNT Generische Einhangeoptionen wie rw und sync konnen bei NFS-Einhangepunkten mit der Option remount geandert werden. Siehe mount(8) fur weitere Informationen uber generische Einhangeoptionen. Bis auf wenige Ausnahmen konnen NFS-spezifische Optionen nicht bei einer Neueinhangung geandert werden. Beispielsweise kann der unterliegende Transport oder die NFS-Version durch eine Neueinhangung nicht geandert werden. Das Neueinhangen auf einem NFS-Dateisystem, das mit der Option noac eingehangt ist, kann unbeabsichtigte Konsequenzen haben. Die Option noac stellt eine Kombination der generischen Option sync und der NFS-spezifischen Option actimeo=0 dar. Aushangen nach einem erneuten Einhangen Fur Einhangepunkte, die NFS Version 2 oder 3 verwenden, hangt der NFS-Unterbefehl umount davon ab, die ursprungliche Menge der Einhangeoptionen zu kennen, die zur Ausfuhrung der MNT-Aktion verwandt wurden. Diese Optionen werden durch den NFS-Unterbefehl mount auf Platte gespeichert und konnen durch erneutes Einhangen geloscht werden. Um sicherzustellen, dass die gespeicherten Einhangeoptionen wahrend eines erneuten Einhangens nicht geloscht werden, geben Sie wahrend eines erneuten Einhangens entweder das lokale Einhangeverzeichnis oder den Rechnernamen und den Exportpfadnamen, aber nicht beide, an. Beispielsweise fugt mount -o remount,ro /mnt die Einhangeoption ro mit den bereits auf Platte gespeicherten, fur den unter /mnt eingehangten NFS-Server zusammen. DATEIEN /etc/fstab Dateisystemtabelle /etc/nfsmount.conf Konfigurationsdatei fur NFS-Einhangungen ANMERKUNGEN Vor Version 2.4.7 unterstutzte der Linux-NFS-Client NFS uber TCP nicht. Vor Linux 2.4.20 verwendete der Linux-NFS-Client eine Heuristik, um zu bestimmen, ob zwischengespeicherte Dateidaten noch gultig waren, statt die oben beschriebene, standardisierte >>close-to-open<<-Zwischenspeicherkoharenzsemantik zu verwenden. Beginnend mit 2.4.22 setzt der Linux-NFS-Client einen Van-Jacobsen-basierten RTT-Abschatzer ein, um die Neuubertragungs-Zeituberschreitungen zu bestimmen, wenn NFS uber UDP verwandt wird. Vor Version 2.6.0 unterstutzte 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 fur rsize und wsize kleiner als die Seitengrosse des Systems waren. Die Unterstutzungen fur Protokollversionen des Linux-Clients hangen 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 fur die UDP-Spezifikation RFC 793 fur die TCP-Spezifikation RFC 1813 fur die NFS-Version-3-Spezifikation RFC 1832 fur die XDR-Spezifikation RFC 1833 fur die RPC-Bind-Spezifikation RFC 2203 fur die RPCSEC-GSS-API-Protokoll-Spezifikation RFC 7530 fur die NFS-version-4.0-Spezifikation RFC 5661 fur die Spezifikation der NFS-Version 4.1. RFC 7862 fur die NFS-Version-4.2-Spezifikation UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Rene Tschirley , Martin Schulze , Jochen Hein , Chris Leick und Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . 9. Oktober 2012 NFS(5)