Provided by: manpages-de-dev_4.15.0-9_all 
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. Falls es keine Optionen gibt,
kann dieses Argument als NULL angegeben werden.
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;
(c) ein wiederhergestellter Inode aus dem Speicher entfernt wird; oder
(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
Die Bits set-user-ID und set-group-ID oder Datei-Capabilities nicht
berücksichtigen, wenn Programme aus diesem Dateisystem ausgeführt werden. Außerdem
erfordern SELinux-Domain-Übergänge das Zugriffsrecht nosuid_transition, welches
seinerseits das Regel-Capability nnp_nosuid_transition erfordert.
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ängungen, 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ängungen der zugeordneten Dateisysteme hinweg sichtbar sind (da die
superblockbezogenen Schalter von allen Einhängungenen 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 einer Einhängung (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ängungen 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 die
unterliegende Einhängung.) 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 eine Mehrfacheinhängung. Ein- und Aushängeereignisse, die direkt
unter dieser Einhängung sind, werden sich zu allen Einhängungen, die Mitglieder der
Peer-Gruppe dieser Einhängung sind, ausbreiten. Ausbreitung bedeutet hier, dass die
gleiche Ein- oder Aushängung automatisch unter allen anderen Einhängungen in der
Peer-Gruppe erfolgen wird. Umgekehrt werden Ein- und Aushängeereignisse, die unter
den Peer-Einhängungen stattfinden, sich zu dieser Einhängung ausbreiten.
MS_PRIVATE
Diese Einhängung wird privat. Ein- und Aushängeereignisse breiten sich nicht in
oder aus dieser Einhängung heraus aus.
MS_SLAVE
Wenn dies eine gemeinsame Einhängung ist, die ein Mitglied einer Peer-Gruppe ist,
die andere Mitglieder enthält, dann wird sie in eine Slave-Einhängung umgewandelt.
Falls dies eine gemeinsame Einhängung ist, die ein Mitglied einer Peer-Gruppe ist,
die keine anderen Mitglieder enthält, dann wird sie in eine private Einhängung
umgewandelt. Andernfalls bleibt der Ausbreitungstyp der Einhängung unverändert.
Wenn eine Einhängung ein Slave ist, breiten sich Ein- und Aushängeereignisse in
dieser Einhängung von der gemeinsamen (Master-)Peer-Gruppe aus, bei der sie früher
ein Mitglied war. Ein- und Aushängeereignisse unterhalb dieser Einhängung breiten
sich nicht zu einem Peer aus.
Eine Einhängung 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 die Ziel-Einhängung. Falls
auch der Schalter MS_REC in Einhängeschalter angegeben ist, dann wird der Ausbreitungstyp
aller Einhängungen 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 eine existierende Einhängung und Ziel den neuen
Ort an, zu dem die bestehende Einhängung 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.
Eine Bind-Einhängung erstellen
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 einer neuen Einhängung. Quelle gibt die Quelle für die neue Einhängung 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
gesetzt, um den Fehler anzuzeigen.
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 eine Einhängung, die 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 keine Einhängung
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.
EPERM Es wurde versucht, die Schalter MS_RDONLY, MS_NOSUID oder MS_NOEXEC oder einen der
»atime«-Schalter (MS_NOATIME, MS_NODIRATIME, MS_RELATIME) einer existierenden
Einhängung zu verändern (MS_REMOUNT), aber die Einhängung ist gesperrt; siehe
mount_namespaces(7).
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ängungen
Jede Einhängung hat eine Eltern-Einhängung. Die allgemeine elterliche Beziehung aller
Einhängungen definiert die einzelne Verzeichnishierarchie, wie sie Prozesse innerhalb
eines Einhänge-Namensraums sehen.
Die Eltern-Einhängung einer neuen Einhängung wird definiert, wenn die Einhängung erstellt
wird. Üblicherweise ist die Eltern-Einhängung einer neuen Einhängung die Einhängung 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ängungen 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ängungen in dem
Einhängenamensraum des Prozesses mit der festgelegten Kennung offen. Die Datei
/proc/[PID]/mountinfo legt sogar weitere Informationen über Einhängungen offen,
einschließlich des Ausbreitungstyps und der Einhängekennungsinformation, die es
ermöglichen, die Eltern-Kind-Beziehungen zwischen Einhängungen zu ermitteln. Siehe proc(5)
und mount_namespaces(7) für Details über diese Dateien.
SIEHE AUCH
mountpoint(1), chroot(2), ioctl_iflags(2), mount_settatr(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.13 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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨debian-l10n-german@lists.debian.org⟩.