| MOUNT(2) | Linux-Programmierhandbuch | MOUNT(2) |
mount - Dateisystem einhängen
#include <sys/mount.h>
int mount(const char *Quelle, const char *Ziel,
const char *Dateisystemtyp,
unsigned long Einhängeschalter,
const void *Daten);
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:
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.
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.
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:
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.
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.
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.
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:
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).
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.
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.
Bei Erfolg wird Null zurückgegeben. Bei einem Fehler wird -1 zurückgegeben und errno entsprechend gesetzt.
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.
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.
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.
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).
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).
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.
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)
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/.
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.
| 21. Dezember 2020 | Linux |