Ubuntu Manpage: mount - Dateisystem einhängen

BEZEICHNUNG

       mount - Dateisystem einhängen

ÜBERSICHT

       #include <sys/mount.h>

       int mount(const char *Quelle, const char *Ziel,
                 const char *Dateisystemtyp,
                 unsigned long Einhängeschalter,
                 const void *Daten);

BESCHREIBUNG

mount() hängt das als Quelle angegebene Dateisystem (was oft ein Pfadname, der sich auf ein Gerät
bezieht, ist; es kann aber auch der Pfadname eines Verzeichnisses oder einer Datei oder eine
Platzhalterzeichenkette sein) an dem durch den Pfadnamen in Ziel angegebenen Ort (einem Verzeichnis oder
einer Datei) ein.

Zum Einhängen von Dateisystemen sind geeignete Rechte erforderlich (Linux: CAP_SYS_ADMIN-Capability).

Die Werte für das Argument dateisystemtyp, die der Kernel unterstützt, werden in /proc/filesystems
aufgelistet (z.B. »btrfs«, »ext4«, »jfs«, »xfs«, »vfat«, »fuse«, »tmpfs«, »cgroup«, »proc«, »mqueue«,
»nfs«, »cifs«, »iso9660« ). Weitere Typen könnten verfügbar werden, wenn geeignete Module geladen sind.

Das Argument Daten wird von den verschiedenen Dateisystemen interpretiert. Typischerweise ist es eine
Zeichenkette aus Optionen, die durch Kommata getrennt sind und die von diesem Dateisystem verstanden
werden. Lesen Sie mount(8), um weitere Einzelheiten über die verfügbaren Optionen für jeden
Dateisystemtyp zu erfahren.

Ein Aufruf von mount() führt eine aus einer Reihe von allgemeinen Aktionsarten durch, abhängig von den in
Einhängeschalter angegebenen Bits. Die Wahl der auszuführenden Aktion wird durch Testen der in
Einhängeschalter gesetzten Bits bestimmt, wobei die Tests in der hier aufgeführten Reihenfolge
abgearbeitet werden:

* Eine bestehende Einhängung neu einhängen: Einhängeschalter enthält MS_REMOUNT.

* Eine Bind-Einhängung erstellen: Einhängeschalter enthält MS_BIND.

* Den Ausbreitungstyp einer bestehenden Einhängung ändern: Einhängeschalter enthält einen aus MS_SHARED,
MS_PRIVATE, MS_SLAVE, MS_UNBINDABLE.

* Eine bestehende Einhängung an einen neuen Ort verschieben: Einhängeschalter enthält MS_MOVE.

* Eine neue Einhängung erstellen: Einhängeschalter enthält keinen der obigen Schalter.

Jede dieser Aktionen wird später auf dieser Seite genauer beschrieben. Wie weiter unten beschrieben ist,
können weitere Schalter in Einhängeschalter angegeben werden, um das Verhalten von mount() zu verändern.

Zusätzliche Einhängeschalter
Die folgende Liste beschreibt zusätzliche Schalter, die in Einhängeschalter angegeben werden können.
Beachten Sie, dass einige Aktionstypen einige oder alle dieser Schalter ignorieren, wie dies später auf
dieser Seite beschrieben ist.

MS_DIRSYNC (seit Linux 2.5.19)
Verzeichniswechsel auf diesem Dateisystem synchron ausführen. (Diese Eigenschaft kann für einzelne
Verzeichnisse oder Unterverzeichnisse durch Benutzung von chattr(1) erreicht werden.)

MS_LAZYTIME (seit Linux 4.0)
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:

(a) der Inode aus einem anderen Grund (neben den Dateizeitstempeln) aktualisiert werden muss;

(b) die Anwendung fsync(2), syncfs(2) oder sync(2) einsetzt;

(d) mehr als 24 Stunden vergangen sind, seitdem der Inode auf Platte geschrieben wurde.

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

MS_MANDLOCK
Zwingendes Sperren von Dateien auf diesem Dateisystem erlauben. (Zwingendes Sperren muss immer
noch für jede Datei eingeschaltet werden, wie es in fcntl(2) beschrieben ist.) Seit Linux 4.5
benötigt diese Einhängeoption die Capability CAP_SYS_ADMIN und einen Kernel, der mit der Option
CONFIG_MANDATORY_FILE_LOCKING konfiguriert wurde.

MS_NOATIME
Nicht die Zugriffszeiten für (alle Typen von) Dateien auf diesem Dateisystem aktualisieren.

MS_NODEV
Keinen Zugriff auf Geräte (Spezialdateien) auf diesem Dateisystem erlauben.

MS_NODIRATIME
Nicht die Zugriffszeiten für Verzeichnisse auf diesem Dateisystem aktualisieren. Dieser Schalter
stellt eine Untermenge der Funktionalität von MS_NOATIME bereit; sprich MS_NOATIME impliziert
MS_NODIRATIME.

MS_NOEXEC
Nicht erlauben, dass Programme von diesem Dateisystem ausgeführt werden.

MS_NOSUID
respektiert die Bits oder Datei-Capabilities »set-user-ID« und »set-group-ID« bei der Ausführung
von Programmen von diesem Dateisystem nicht.

MS_RDONLY
Dateisystem nur zum Lesen einhängen.

MS_REC (seit Linux 2.4.11)
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.

MS_RELATIME (seit Linux 2.6.20)
Wenn auf eine Datei auf diesem Dateisystem zugegriffen wird, nur die letzte Zugriffzeit der Datei
(atime) aktualisieren, falls der aktuelle Wert von »atime« kleiner oder gleich der letzten
Änderungszeit der Datei (mtime) oder der Zeit der letzten Statusänderung (ctime) ist. Diese Option
ist für Programme wie mutt(1) sinnvoll, die wissen müssen, ob eine Datei seit der letzten Änderung
gelesen wurde. Seit Linux 2.6.30 verhält sich der Kernel wie es dieser Schalter vorgibt (falls
nicht MS_NOATIME angegeben wurde) und der Schalter MS_STRICTATIME wird benötigt, um traditionelle
Semantiken zu erhalten. Zusätzlich wird seit Linux 2.6.30 die letzte Zugriffszeit der Datei immer
aktualisiert, wenn sie älter als einen Tag ist.

MS_SILENT (seit Linux 2.6.17)
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.

MS_STRICTATIME (seit Linux 2.6.30)
Die letzte Zugriffszeit (atime) immer aktualisieren, wenn auf Dateien auf diesem Dateisystem
zugegriffen wird (dies war das Standardverhalten vor Linux 2.6.30). Die Angabe dieses Schalters
überschreibt den Effekt der Schalter MS_NOATIME und MS_RELATIME.

MS_SYNCHRONOUS
Schreiben auf diesem Dateisystem synchronisieren (als ob der Schalter O_SYNC für open(2) für alle
offenen Dateien auf diesem Dateisystem angegeben worden wäre).

MS_NOSYMFOLLOW (seit Linux 5.10)
Beim Auflösen von Pfaden keinen Symlinks folgen. Symlinks können noch angelegt werden und
readlink(1), readlink(2), realpath(1) und realpath(3) werden noch korrekt funktionieren.

Seit Linux 2.4 können einige der obigen Schalter pro Einhängepunkt gesetzt werden, während andere für den
Superblock des eingehängten Dateisystems gelten, was bedeutet, dass alle Einhängungen des gleichen
Dateisystems diese Schalter gemeinsam benutzen (vorher waren alle Schalter superblockabhängig).

Die einhängepunktabhängigen Schalter haben folgende Bedeutung:

* Seit Linux 2.4: Die Schalter MS_NODEV, MS_NOEXEC und MS_NOSUID sind pro Einhängepunkt setzbar.

* Zusätzlich seit Linux 2.6.16: MS_NOATIME und MS_NODIRATIME.

* Zusätzlich seit Linux 2.6.20: MS_RELATIME.

Die folgenden Schalter sind pro Superblock: MS_DIRSYNC, MS_LAZYTIME, MS_MANDLOCK, MS_SILENT und
MS_SYNCHRONOUS. Die anfänglichen Einstellungen dieser Schalter werden bei der ersten Einhängung des
Dateisystems bestimmt und werden von allen nachfolgenden Einhängungen des gleichen Dateisystems
mitbenutzt. Als Folge davon können die Einstellungen dieser Schalter mittels einer Neueinhängungsaktion
(siehe unten) geändert werden. Solche Änderungen werden auf allen Einhängepunkten, die diesem Dateisystem
zugeordnet sind, sichtbar.

Seit Linux 2.6.16 kann MS_RDONLY sowohl auf einer einhängepunktabhängigen Basis als auch auf den
unterliegenden Dateisystemsuperblock (zurück)gesetzt werden. Das eingehängte Dateisystem wird nur
schreibbar sein, falls weder das Dateisystem noch der Einhängepunkt als nur-lesbar gekennzeichnet sind.

Eine existierende Einhängung erneut einhängen
Die existierende Einhängung kann erneut eingehängt werden, indem MS_REMOUNT in den Einhängeschaltern
angegeben 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.

Die Argumente 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.

Die folgenden Einhängeschalter können geändert werden: MS_LAZYTIME, MS_MANDLOCK, MS_NOATIME, MS_NODEV,
MS_NODIRATIME, MS_NOEXEC, MS_NOSUID, MS_RELATIME, MS_RDONLY, MS_STRICTATIME (der bewirkt, dass die
Schalter MS_NOATIME und MS_RELATIME bereinigt werden) und MS_SYNCHRONOUS. Versuche, die Einstellung der
Schalter MS_DIRSYNC und MS_SILENT während einer wiederholten Einhängung zu ändern, werden ohne
Rückmeldung ignoriert. Beachten Sie, dass Änderungen der superblockbezogenen Schalter über alle
Einhängepunkte der zugeordneten Dateisysteme hinweg sichtbar sind (da die superblockbezogenen Schalter
von allen Einhängepunkten gemeinsam benutzt werden).

Seit Linux 3.17 hält die Neueinhänge-Aktion die bestehenden Werte der Schalter MS_NOATIME, MS_NODIRATIME,
MS_RELATIME und MS_STRICTATIME bei, falls keiner davon explizit angegeben wurde, statt als Vorgabe
MS_RELATIME zu verwenden.

Seit Linux 2.6.26 kann der Schalter MS_REMOUNT mit MS_BIND verwandt werden, um nur die
einhängepunktabhängigen 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

MS_REMOUNT | MS_BIND | MS_RDONLY

angegeben, 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 Argumente Dateisystemtyp und Daten werden ignoriert.

Die verbleibenden Bits (außer das unten beschriebene MS_REC) im Argument Einhängeschalter werden 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.

Den Ausbreitungstyp einer bestehenden Einhängung ändern
Falls Einhängeschalter einen aus MS_SHARED, MS_PRIVATE, MS_SLAVE, MS_UNBINDABLE (alle seit Linux 2.6.15
verfügbar) enthält, dann wird der Ausbreitungstyp einer bestehenden Einhängung geändert. Falls mehr als
einer dieser Schalter angegeben wird, entsteht ein Fehler.

Die einzigen anderen Schalter, die beim Ändern des Ausbreitungstyps verwandt werden können, sind MS_REC
(nachfolgend beschrieben) und MS_SILENT (der stillschweigend ignoriert wird).

Die Argumente Quelle, Dateisystemtyp und Daten werden ignoriert.

Die Ausbreitungstypschalter haben folgende Bedeutung:

MS_SHARED
Damit wird dies ein Mehrfacheinhängepunkt. Ein- und Aushängeereignisse, die direkt unter diesem
Einhängepunkt sind, werden sich zu allen Einhängepunkten, die Mitglieder der Peer-Gruppe dieser
Einhängung sind. Ausbreitung bedeutet hier, dass die gleiche Ein- oder Aushängung automatisch
unter allen anderen Einhängepunkten in der Peer-Gruppe erfolgen wird. Umgekehrt werden Ein- und
Aushängeereignisse, die unter den Peer-Einhängepunkten stattfinden, sich zu diesem Einhängepunkt
ausbreiten.

MS_PRIVATE
Dieser Einhängepunkt wird privat. Ein- und Aushängeereignisse breiten sich nicht in oder aus
diesem Einhängepunkt heraus aus.

MS_SLAVE
Wenn dies ein gemeinsamer Einhängepunkt ist, der ein Mitglied einer Peer-Gruppe, die andere
Mitglieder enthält, ist, dann wird er in eine Slave-Einhängung umgewandelt. Falls dies ein
gemeinsamer Einhängepunkt ist, der ein Mitglied einer Peer-Gruppe, die keine anderen Mitglieder
enthält, ist, dann wird er in eine private Einhängung umgewandelt. Andernfalls bleibt der
Ausbreitungstyp des Einhängepunkts unverändert.

Wenn ein Einhängepunkt ein Slave ist, breiten sich Ein- und Aushängeereignisse in diesen
Einhängepunkt von der gemeinsamen (Master-)Peer-Gruppe aus, bei der er früher ein Mitglied war.
Ein- und Aushängeereignisse unterhalb dieses Einhängepunktes breiten sich nicht zu einem Peer aus.

Ein Einhängepunkt kann ein Slave einer anderen Peer-Gruppe sein und gleichzeitig die Ein- und
Aushängeereignisse gemeinsam mit einer Peer-Gruppe nutzen, bei der er Mitglied ist.

MS_UNBINDABLE
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 nicht-bind-einhängbaren Einhängepunkte 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 angegeben ist, dann wird der Ausbreitungstyp aller Einhängepunkte
unter Ziel auch geändert.

Für weitere Details bezüglich Einhängeausbreitungstypen (einschließlich der neuen Einhängungen
zugewiesenen Vorgabeausbreitungstypen) siehe mount_namespaces(7).

Verschieben einer Einhängung
Falls Einhängeschalter den Schalter MS_MOVE enthält (verfügbar seit Linux 2.4.18), dann wird ein
Unterbaum verschoben. Quelle gibt einen existierenden Einhängepunkt und Ziel den neuen Ort an, zu dem der
bestehende Einhängpunkt hin verlegt werden soll. Das Verschieben ist atomar: Das Unterbaum wird zu keinem
Zeitpunkt ausgehängt.

Die verbliebenen Bits im Argument Einhängeschalter werden ignoriert, wie auch die Argumente
Dateisystemtyp und Daten.

Erstellung eines neuen Einhängepunktes
Falls kein Schalter aus MS_REMOUNT, MS_BIND, MS_MOVE, MS_SHARED, MS_PRIVATE, MS_SLAVE und MS_UNBINDABLE
in Einhängeschalter angegeben ist, führt mount() seine Vorgabeaktion aus: Erstellung eines neuen
Einhängepunktes. Quelle gibt die Quelle für den neuen Einhängepunkt an und Ziel gibt das Verzeichnis an,
an dem der Einhängepunkt erstellt werden soll.

Die Argumente Dateisystemtyp und Daten werden eingesetzt und weitere Bits können in Einhängeschalter
angegeben werden, um das Verhalten des Aufrufs zu verändern.

RÜCKGABEWERT

       Bei Erfolg wird Null zurückgegeben. Bei  einem  Fehler  wird  -1  zurückgegeben  und  errno  entsprechend
       gesetzt.

FEHLER

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.

EACCES Eine Komponente eines Pfades war nicht durchsuchbar. (Siehe auch path_resolution(7).)

EACCES Es wurde versucht, ein nur-lesbares Dateisystem einzuhängen, ohne den Schalter MS_RDONLY zu
verwenden.

Das Dateisystem kann aus verschiedenen Gründen nur lesbar sein. Dazu gehören: es liegt auf einer
nur lesbaren optischen Platte, es liegt auf einem Gerät mit einem physischen Schalter, der auf der
Einstellung »nur lesbar« steht, die Dateisystemimplementierung wurde ohne Schreibunterstützung
kompiliert oder es wurden Fehler erkannt, als das Dateisystem erstmalig eingehängt wurde, so dass
es nur lesbar markiert wurde und nicht erneut schreibbar eingehängt werden kann (bis die Fehler
behoben wurden).

Einige Dateisysteme liefern bei einem Versuch, ein nur lesbares Dateisystem einzuhängen,
stattdessen den Fehler EROFS.

EACCES Das Blockgerät Quelle befindet sich auf einem Dateisystem, das mit der Option MS_NODEV eingehängt
wurde.

EBUSY Es wurde versucht, eine neue Einhängung auf einen existierenden Einhängepunkt, der in diesem
Einhängenamensraum mit den gleichen Quelle und Ziel erzeugt worden war, zu stapeln.

EBUSY Quelle kann nicht nur-lesend neu eingehängt werden, da dort immer noch Dateien zum Schreiben offen
sind.

EFAULT Eines der Zeiger-Argumente zeigt außerhalb des Adressraums der Benutzer.

EINVAL Quelle hat einen ungültigen Superblock.

EINVAL Eine Neueinhängungsaktion (MS_REMOUNT) wurde versucht, aber Quelle war nicht bereits auf Ziel
eingehängt.

EINVAL Eine Verschiebeaktion (MS_MOVE) wurde versucht, aber der Einhängebaum unter Quelle enthält nicht
bindbare Einhängungen und Ziel ist ein Einhängepunkt, der den Ausbreitungstyp MS_SHARED hat.

EINVAL Eine Verschiebeaktion (MS_MOVE) wurde versucht, aber die Elterneinhängung von Quelle hat den
Ausbreitungstyp MS_SHARED.

EINVAL Eine Verschiebeaktion (MS_MOVE) wurde versucht, aber Quelle war kein Einhängepunkt oder war »/«.

EINVAL Es wurde eine Bind-Aktion (MS_BIND) angefordert, wobei Quelle sich auf einen magischen
Einhängenamensraum-Link bezog (d.h. einen magischen Link /proc/[PID]/ns/mnt oder eine
Bind-Einhängung auf solch einen Link) und der Ausbreitungstyp der übergeordneten Einhängung von
Ziel war MS_SHARED, aber die Ausbreitung der angeforderten Bind-Einhängung könnte zu einer
zirkulären Abhängigkeit führen, die verhindern könnte, dass der Einhänge-Namensraum jemals wieder
freigegeben werden könnte.

EINVAL mountflags enthält mehr als einen aus MS_SHARED, MS_PRIVATE, MS_SLAVE und MS_UNBINDABLE.

EINVAL mountflags enthält MS_SHARED, MS_PRIVATE, MS_SLAVE oder MS_UNBINDABLE und enthält auch einen von
MS_REC oder MS_SILENT verschiedenen Schalter.

EINVAL Es wurde versucht, ein nicht-bind-einhängbare Einhängung bind-einzuhängen.

EINVAL In einem nicht privilegierten Einhängenamensraum (d.h. einem Einhängenamensraum, der einem
Benutzernamensraum gehört, der durch einen nicht privilegierten Benutzer erstellt wurde) wurde
eine Bind-Einhängeaktion (MS_BIND) ohne Angabe von (MS_REC) versucht, womit der Dateisystembaum
unterhalb einer der Untereinhängungen des Bind-eingehängten Verzeichnisses offengelegt worden
wäre.

ELOOP Bei der Auflösung des Pfadnamens wurden zu viele Links gefunden.

ELOOP Es wurde eine Verschiebeaktion versucht und Ziel liegt unterhalb von Quelle.

EMFILE (Falls kein blockorientiertes Gerät benötigt wird:) Die Tabelle der Platzhaltergeräte ist voll.

ENAMETOOLONG
Ein Pfadname war länger als MAXPATHLEN.

ENODEV Der Dateisystemtyp ist nicht im Kernel konfiguriert.

ENOENT Ein Pfadname war leer oder hatte eine nichtvorhandene Komponente.

ENOMEM Der Kernel konnte keine freie Seite reservieren, um Dateinamen oder Daten hinein zu kopieren.

ENOTBLK
Die Quelle ist kein blockorientiertes Gerät (und ein Gerät war erforderlich).

ENOTDIR
Das Ziel oder ein Präfix der Quelle ist kein Verzeichnis.

ENXIO Die Major-Nummer des blockorientierten Gerätes Quelle liegt außerhalb des Bereichs.

EPERM Der Aufrufende verfügt nicht über die erforderlichen Rechte.

EROFS Es wurde versucht, ein nur-lesbares Dateisystem einzuhängen, ohne den Schalter MS_RDONLY zu
verwenden. Siehe EACCES oben.

VERSIONEN

       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.

KONFORM ZU

       Diese Funktion ist Linux-spezifisch und sollte nicht in Programmen benutzt werden, die portabel  gehalten
       werden sollen.

ANMERKUNGEN

Seit Linux 2.4 kann ein einzelnes Dateisystem an mehreren Einhängepunkten eingehängt sein und mehrere
Einhängungen können auf dem gleichen Einhängepunkt gestapelt werden.

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.

Der Originalschalter MS_SYNC wurde in 1.1.69 in MS_SYNCHRONOUS umbenannt, als ein anderer MS_SYNC zu
<mman.h> hinzugefügt wurde.

Vor Linux 2.4 würde ein Versuch, ein Set-User-ID- oder Set-Group-ID-Programm auf einem Dateisystem
auszuführen, das mit MS_NOSUID eingehängt ist, mit EPERM fehlschlagen. Seit Linux 2.4 werden die Bits
Set-User-ID und Set-User-Group-ID in diesem Fall einfach stillschweigend ignoriert.

Einhänge-Namensräume
Seit Kernel 2.4.19 stellt Linux Einhänge-Namensräume 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 mitverwenden. (Die Situation in Linux vor 2.4.19 kann so betrachtet
werden, als ob ein einzelner Namensraum von jedem Prozess im System mitbenutzt würde.)

Ein Kindprozess, der durch fork(2) erzeugt wurde, nutzt den Einhängenamensraum seines Elternprozesses;
der Einhängenamensraum wird über ein execve(2) beibehalten.

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.

Für weitere Details über Einhänge-Namensräume, siehe mount_namespaces(7).

Elterliche Beziehung zwischen Einhängepunkten
Jeder Einhängepunkt hat einen Eltern-Einhängepunkt. Die allgemeine elterliche Beziehung aller
Einhängepunkte definiert die einzelne Verzeichnishierarchie, wie sie Prozesse innerhalb eines
Einhänge-Namensraums sehen.

Der Eltern-Einhängepunkt eines neuen Einhängepunkts wird definiert, wenn der Einhängepunkt erstellt wird.
Üblicherweise ist der Eltern-Einhängepunkt eines neuen Einhängepunkts der Einhängepunkt des Dateisystems,
welches das Verzeichnis oder die Datei enthält, an dem oder der die neue Einhängung geschieht. In dem
Fall, in dem der Eltern-Einhängepunkt einer neuen Einhängung über die oberste Ebene einer existierenden
Einhängung gesetzt wird, ist der Eltern-Einhängepunkt der neuen Einhängung die vorherige Einhängung, die
an diesem Ort gesetzt war.

Die elterliche Beziehung zwischen Einhängepunkten können Sie in der Datei /proc/[PID]/mountinfo
herausfinden (siehe unten).

/proc/[PID]/mounts und /proc/[PID]/mountinfo
Die Linux-spezifische Datei /proc/[PID]/mounts legt die Liste der Einhängepunkte in dem
Einhängenamensraum des Prozesses mit der festgelegten Kennung offen. Die Datei /proc/[PID]/mountinfo legt
sogar weitere Informationen über Einhängepunkte offen, einschließlich des Ausbreitungstyps und der
Einhängekennungsinformation, die es ermöglichen, die Eltern-Kind-Beziehungen zwischen Einhängepunkten zu
ermitteln. Siehe proc(5) und mount_namespaces(7) für Details über diese Dateien.

SIEHE AUCH

       mountpoint(1),     chroot(2),    ioctl_iflags(2),    pivot_root(2),    umount(2),    mount_namespaces(7),
       path_resolution(7), findmnt(8), lsblk(8), mount(8), umount(8)

KOLOPHON

       Diese Seite ist Teil der Veröffentlichung  5.10  des  Projekts  Linux-man-pages.  Eine  Beschreibung  des
       Projekts, Informationen, wie Fehler gemeldet werden können sowie die aktuelle Version dieser Seite finden
       sich unter https://www.kernel.org/doc/man-pages/.

ÜBERSETZUNG

       Die  deutsche  Übersetzung  dieser  Handbuchseite  wurde  von  Patrick Rother <krd@gulu.net>, Chris Leick
       <c.leick@vollbio.de>,   Mario   Blättermann   <mario.blaettermann@gmail.com>   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  die
       Mailingliste der Übersetzer.

Linux                                           21. Dezember 2020                                       MOUNT(2)