Provided by: manpages-de_2.14-1_all bug

BEZEICHNUNG

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

ÜBERSICHT

       /etc/fstab

BESCHREIBUNG

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

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

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

               Server:Pfad   /Einhängepunkt         Fstype              Option,Option,…t0 0

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

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

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

EINHÄNGEOPTIONEN

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

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

       nfsvers=n      Die NFS-Protokollnummer, die für den Kontakt  zum  NFS-Dienst  des  Servers
                      verwandt  wird.  Falls der Server die angefragte Version nicht unterstützt,
                      schlägt die Einhängeanfrage fehl. Falls diese Option nicht  angegeben  ist,
                      handelt  der  Client  eine  geeignete  Version mit dem Server aus, wobei er
                      zuerst Version 4, dann Version 3 und zum Schluss Version 2 versucht.

       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.

       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  automatischen Einhängeprogramm angegangen werden (siehe automount(8)
                      für Details).

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

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

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

                      Der Abschnitt SICHERHEITSBETRACHTUNGEN enthält wichtige Details.

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

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

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

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

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

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

       fsc/nofsc      aktiviert/deaktiviert das Zwischenspeichern von (nur lesbaren)  Datenseiten
                      auf   der   lokalen   Platte   mittels   der   FS-Cache-Einrichtung.  Siehe
                      cachefilesd(8)  und  <kernel_soruce>/Documentation/filesystems/caching  für
                      Details zur Einrichtung der FS-Cache-Einrichtung. Die Vorgabe ist nofsc.

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

       proto=NetID    Die NetID bestimmt den Transport, der zur Kommunikation mit dem  NFS-Server
                      verwandt  wird. Verfügbare Optionen sind udp, udp6, tcp, tcp6 und rdma. 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  festgelegt  werden.  Falls  der
                      Mountd-Dienst des Server über den festgelegten  Transport  nicht  verfügbar
                      ist, schlägt die Einhängeanfrage fehl.

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

       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)     festgelegt      ist,      verwendet      der      Client
                      »close-to-open«-Zwischenspeicherkohärenzsemantik.  Falls  die  Option nocto
                      festgelegt 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 Access Control Lists verwaltet.
                      NFSACL wurde nie zu einem Standardteil der NFS-Protokollspezifikation.

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

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

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

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

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

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

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

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

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

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

       proto=NetID    netid  bestimmt den Transport, der für die Kommunikation mit dem NFS-Server
                      verwandt  wird.  Unterstützte  Optionen  sind  tcp,  tcp6  und  rdma.  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.

       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 festgelegt ist, verwendet  der  NFS-Client
                      die  Standard-Portnummer  2049, ohne erst den Rpcbind-Dienst des Servers zu
                      prüfen. Dies erlaubt  es,  einem  NFS-Version-4-Client,  Kontakt  zu  einem
                      Server   aufzunehmen,  der  hinter  einer  Firewall,  die  Rpcbind-Anfragen
                      blockiert, liegt.

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

       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 festgelegt 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.

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

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

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

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

NFS4-DATEISYSTEMTYP

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

EINHÄNGEKONFIGURATIONSDATEI

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

BEISPIELE

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

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

               server:/export  /mnt  nfs   defaults                      0 0

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

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

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

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

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

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

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

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

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

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

TRANSPORTMETHODEN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       Jumbo Frames:  Viele Gigabit-Netzkarten sind in der Lage, Frames größer als die Begrenzung
                      des traditionellen Ethernet von 1500  byte  zu  übertragen,  typischerweise
                      9000  bytes. Werden Jumbo Frames von 9000 bytes verwandt, kann NFS über UDP
                      mit Seitengrößen von 8 K ohne Fragmentierung  betrieben  werden.  Natürlich
                      ist  das  nur  möglich,  falls  alle  beteiligten  Stationen  Jumbo  Frames
                      unterstützen.

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

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

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

DATEN- UND METADATENKOHÄRENZ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

              Speicherdruck erzwingt die Zurückgewinnung von Systemspeicherressourcen.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SICHERHEITSBETRACHTUNGEN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

              Welchen Netzwerk-Port jeder RPC-basierte Dienst verwendet

              Welches Transportprotokoll jeder RPC-basierte Dienst unterstützt

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

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

   NFS-Zugriffssteuerlisten
       Solaris  erlaubt  NFS-Version-3-Clients  direkten  Zugriff  auf  die  auf  seinen  lokalen
       Dateisystemen   gespeicherten   POSIX   Access   Control   Lists.    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 Access Control  Lists,  die
       semantisch  reicher  als  POSIX ACLs ist. NFS-Version-4-ACLs sind mit den POSIX ACLs nicht
       voll kompatibel, daher ist eine Übersetzung zwischen den beiden in Umgebungen,  die  POSIX
       ACLs und NFS Version 4 vermischen, notwendig.

DIE OPTION REMOUNT

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

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

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

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

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

               mount -o remount,ro /mnt

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

DATEIEN

       /etc/fstab     Dateisystemtabelle

       /etc/nfsmount.conf
                      Konfigurationsdatei für NFS-Einhängungen

FEHLER

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

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

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

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

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

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

SIEHE AUCH

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

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

ÜBERSETZUNG

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

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

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

                                         9. Oktober 2012                                   NFS(5)