text: mount − Dateisystem einhängen
  Zum Einhängen von Dateisystemen sind geeignete Rechte erforderlich (Linux: CAP_SYS_ADMIN−Capability).
  Eine Bind−Einhängung erstellen: Einhängeschalter enthält MS_BIND.
  Reduziert die Aktualiserung der Inode−Zeitstempel (Atime, Mtime, Ctime) auf der Platte, indem diese Änderungen nur im Speicher verwaltet werden. Die Zeitstempel auf der Platte werden nur aktualisiert, wenn:
  Diese Einhängeoption reduziert die Schreibaktionen für die Aktualisierung der Inode−Zeitstempel signifikant, besonders für Mtime und Atime. Im Falle eines Systemabsturzes könnten die Atime− und Mtime−Felder allerdings bis zu 24 Stunden veraltet sein.
  Zufälliges Schreiben in vorreservierte Dateien sowie andere Fälle, in denen die Einhängeoption MS_STRICTATIME auch aktiviert ist, sind Beispiele für Betriebsbelastungen, bei denen diese Option deutlichen Vorteil bringen könnte. (Der Vorteil der Kombination von MS_STRICTATIME und MS_LAZYTIME besteht darin, dass stat(2) die korrekt aktualisierte Atime zurückliefern wird, aber Atime−Aktualisierungen nur in den oben aufgeführten Fällen auf Platte rausgeschrieben werden.)
  Die Bits set−user−ID und set−user−group−ID und Datei−Capabilities nicht berücksichtigen, wenn Programme von diesem Dateisystem ausgeführt werden.
  Wird zusammen mit MS_BIND verwandt, um eine rekursive Bind−Einhängung zu erstellen und im Zusammenhang mit Ausbreitungstypschaltern, um rekursiv den Ausbreitungstyp aller Einhängungen in einem Unterbaum zu ändern. Details sind weiter unten beschrieben.
  Die Anzeige bestimmter Warnungen (printk()) im Kernel−Protokoll unterdrücken. Dieser Schalter ersetzt den falsch benannten und veralteten Schalter MS_VERBOSE (verfügbar seit Linux 2.4.12), der die gleiche Bedeutung hat.
  Von Linux 2.4 aufwärts können die Schalter MS_NODEV, MS_NOEXEC und MS_NOSUID pro Einhängepunkt gesetzt werden. Von Linux 2.6.16 aufwärts können auch die Schalter MS_NOATIME und MS_NODIRATIME pro Einhängepunkt gesetzt werden. Außerdem kann der Schalter MS_RELATIME pro Einhängepunkt gesetzt werden. Seit Linux 2.6.16 kann MS_RDONLY sowohl auf einer pro−Einhängepunkt−Basis als auch auf dem unterliegenden Dateisystem (zurück)gesetzt werden. Das unterliegende Dateisystem wird nur schreibbar sein, falls weder das Dateisystem noch der Einhängepunkt als nur−lesbar gekennzeichnet sind.
  Die existierende Einhängung kann erneut eingehängt werden, indem MS_REMOUNT in den Einhängeschalter festgelegt wird. Dies erlaubt Ihnen, die Einhängeschalter und Daten von einer existierenden Einhängung zu ändern, ohne das Dateisystem aus− und wieder einzuhängen. Ziel sollte der gleiche Wert sein, wie beim anfänglichen Aufruf von mount() angegeben wurde; Quelle und Dateisystemtyp werden ignoriert.
  Die Argumente Einhängeschalter und Daten sollten den im originalen mount()−Aufruf verwendeten Werten entsprechen, außer für jene Parameter, die bewusst geändert werden. Eine weitere Ausnahme ist, dass MS_BIND beim erneuten Einhängen eine andere Bedeutung hat und daher nur aufgenommen werden sollte, wenn es explizit erwünscht ist.
  Seit Linux 3.17 erhält die Neueinhänge−Aktion die bestehenden Werte der Schalter MS_NOATIME, MS_NODIRATIME, MS_RELATIME und MS_STRICTATIME, falls keiner davon explizit angegeben wurde, statt als Vorgabe MS_RELATIME zu verwenden.
  Seit Linux 2.6.26 kann dieser Schalter mit MS_BIND verwandt werden, um nur die pro−Einhängungs−Schalter zu verändern. Dies ist besonders nützlich, um den »nur−lesbar«−Schalter auf einem Einhängepunkt (zurück−)zusetzen, ohne das unterliegende Dateisystem zu verändern. Wird Einhängeschalter als
  festgelegt, dann wird der Zugriff über diesen Einhängepunkt nur−lesbar, ohne andere Einhängepunkte zu beeinflussen.
  Eine Bind−Einhängung erstellen
  Falls Einhängeschalter MS_BIND (verfügbar seit Linux 2.4) enthält, dann wird eine Bind−Einhängung durchgeführt. Eine Bind−Einhängung macht eine Datei oder ein Verzeichnisunterbaum an einem anderen Punkt innerhalb der einzelnen Verzeichnishierarchie sichtbar. Bind−Einhängungen können Dateisystemgrenzen überwinden und sich über chroot(2)−Gefängnisse hinweg erstrecken.
  Die verbleibenden Bits im Argument Einhängeschalter werden außer MS_REC auch ignoriert. (Die Bind−Einhängung hat die gleichen Einhängeoptionen wie der unterliegende Einhängepunkt.) Lesen Sie allerdings die Diskussion zum erneuten Einhängen weiter oben für eine Methode, wie Sie eine bestehende Bind−Einhängung auf nur−lesend ändern.
  Wenn ein Verzeichnis bind−eingehängt ist, ist standardmäßig nur dieses Verzeichnis eingehängt; falls es Untereinhängungen unter dem Verzeichnisbaum gibt, sind diese nicht bind−eingehängt. Falls auch der Schalter MS_REC angegeben ist, dann wird eine rekursive Bind−Einhängung durchgeführt: Alle Untereinhängungen unter dem Unterbaum Quelle (außer nicht bind−einhängbaren Einhängungen) werden auch an dem entsprechenden Ort im Ziel−Unterbaum bind−eingehängt.
  Dieser Einhängepunkt wird privat. Ein− und Aushängeereignisse breiten sich nicht in oder aus diesem Einhängepunkt heraus aus.
  Diesen Einhängepunkt nicht bind−einhängbar machen. Dies ähnelt einer privaten Einhängung, zusätzlich kann diese Einhängung nicht bind−eingehängt werden. Wenn eine rekursive Bind−Einhängung (mount() mit den Schaltern MS_BIND und MS_REC) auf einem Verzeichnisunterbaum durchgeführt wird, werden alle Bind−Einhängungen innerhalb des Unterbaums automatisch abgeschnitten (d.h. nicht reproduziert), wenn der Unterbaum zum Erstellen des Zielbaumes reproduziert wird.
  Standardmäßig betrifft die Änderung des Ausbreitungstyps nur den Ziel−Einhängepunkt. Falls auch der Schalter MS_REC in Einhängeschalter festgelegt ist, dann wird der Ausbreitungstyp aller Einhängpunkte unter Ziel auch geändert.
  Die im Folgenden aufgeführten Fehlerwerte resultieren aus vom Dateisystemtyp unabhängigen Fehlern. Jeder Dateisystemtyp kann seine eigenen speziellen Fehler und sein eigenes spezielles Verhalten aufweisen. Lesen Sie den Linux−Kernel−Quellcode, um Einzelheiten zu erfahren.
  Es wurde versucht, ein nur−lesbares Dateisystem einzuhängen, ohne den Schalter MS_RDONLY zu verwenden.
  Quelle kann nicht neu nur−lesend eingehängt werden, da dort immer noch Dateien zum Schreiben offen sind.
  Eines der Zeiger−Argumente zeigt außerhalb des Adressraums der Benutzer.
  Es wurde versucht, ein nicht−bind−einhängbare Einhängung bind−einzuhängen.
  Die Major−Nummer des blockorientierten Gerätes Quelle liegt außerhalb des Bereichs.
  Die Definitionen von MS_DIRSYNC, MS_MOVE, MS_PRIVATE, MS_REC, MS_RELATIME, MS_SHARED, MS_SLAVE, MS_STRICTATIME und MS_UNBINDABLE wurden in der Version 2.12 in die Glibc−Header aufgenommen.
  Diese Funktion ist Linux−spezifisch und sollte nicht in Programmen benutzt werden, die portabel gehalten werden sollen.
  Das Argument Einhängeschalter hat die Magische Zahl 0xC0ED (MS_MGC_VAL) in den oberen 16 Bits. (Alle andere in BESCHREIBUNG vorgestellten Schalter liegen in den unteren 16 Bits von Einhängeschalter.). In Kernel−Versionen vor 2.4 war die Angabe von MS_MGC_VAL notwendig, aber seit Linux 2.4 ist dies nicht mehr notwendig und wird, falls angegeben, ignoriert.
  Vor Linux 2.4 würde ein Versuch mit EPERM fehlschlagen, ein Set−User−ID− oder Set−Group−ID−Programm auf einem Dateisystem auszuführen, das mit MS_NOSUID eingehängt ist. Seit Linux 2.4 werden die Bits Set−User−ID und Set−User−Group−ID in diesem Fall einfach stillschweigend ignoriert.
  Seit Kernel 2.4.19 stellt Linux Einhänge−Namensräume pro Prozess bereit. Ein Einhänge−Namensraum ist eine Zusammenstellung von eingehängten Dateisystemen, die für einen Prozess sichtbar sind. Einhängepunkt−Namensräume können (und werden gewöhnlich) gemeinsam von mehreren Prozessen benutzt und Änderungen am Namensraum (d.h. Ein− und Aushängen) durch einen Prozess sind für alle anderen Prozesse sichtbar, die den gleichen Namensraum gemeinsam verwenden. (Die Situation in Linux vor 2.4.19 kann so betrachtet werden, als ob ein einzelner Namensraum von jedem Prozess im System gemeinsam benutzt würde.)
  Ein Prozess kann einen privat eingehängten Namensraum erhalten, falls er unter Benutzung des Schalters CLONE_NEWNS von clone(2) erstellt wurde. In diesem Fall wird sein neuer Namensraum als eine Kopie des Namensraums des Prozesses, der clone(2) aufrief, initialisiert oder er ruft unshare(2) mit dem Schalter CLONE_NEWNS auf, was veranlasst, dass der Einhänge−Namensraum des Aufrufenden eine private Kopie des Namensraums erhält, der vorher mit anderen Prozessen gemeinsam benutzt wurde, so dass zukünftiges Ein− und Aushängen durch den Aufrufenden für andere Prozesse unsichtbar ist (außer Kindprozesse, die der Aufrufende hinterher erzeugt) und umgekehrt.
  Die Linux−spezifische Datei /proc/[PID]/mounts stellt die Liste der Einhängepunkte in dem Einhänge−Namensraum des Prozesses mit der angegebenen ID dar; lesen Sie proc(5), um Einzelheiten zu erfahren.