Manpages

BEZEICHNUNG

file-hierarchy - Dateisystemhierarchie-Überblick

BESCHREIBUNG

Betriebssysteme, die das System und den Diensteverwalter von systemd(1) verwenden, sind auf einer von UNIX inspirierten und auf diesem basierenden Dateisystemhierarchie organisiert, genauer der in der Spezifikation Dateisystem-Hierarchie [1] und hier(7) mit verschiedenen Erweiterungen, teilweise in der XDG-Basisverzeichnisspezifikation [2] und XDG-Benutzerverzeichnisse [3] dokumentiert, festgelegten. Diese Handbuchseite beschreibt die verallgemeinerte, allerdings minimale und modernisierte Untermenge dieser Spezifikationen, die die Vorschläge und Begrenzungen, die Systemd in Bezug auf die Dateisystemhierarchie macht, genauer definiert.

Viele der hier beschriebenen Pfade können mit dem Werkzeug systemd-path(1) abgefragt werden.

ALLGEMEINE STRUKTUR

/

Die Wurzel des Dateisystems. Normalerweise schreibbar, aber dies wird nicht benötigt. Möglicherweise ein temporäres Dateisystem (»tmpfs«). Wird nicht mit anderen Rechnern gemeinsam benutzt (außer nur-lesbar).

/boot/

Die Systemstartpartition, wird zum Hochfahren des Systems verwandt. Auf EFI-Systemen ist dies möglicherweise die EFI-Systempartition (ESP), siehe auch systemd-gpt-auto-generator(8). Dieses Verzeichnis ist normalerweise streng an den lokalen Rechner gebunden und sollte als nur lesbar betrachtet werden, außer wenn ein neuer Kernel oder ein neues Systemstartprogramm installiert wird. Dieses Verzeichnis existiert nur auf Systemen, die auf physischer oder emulierter Hardware laufen, die Systemstartprogramme benötigen.

/efi/

Falls die Systemstartpartition /boot/ separat von der EFI-Systempartition (ESP), wird letztere hier eingehängt. Werkzeuge, die mit der EFI-Systempartition arbeiten müssen, sollten hier zuerst unter diesem Einhängepunkt schauen, und dann auf /boot/ zurückfallen, falls ersterer nicht geeignet ist (falls es beispielsweise kein Einhängepunkt ist oder nicht den korrekten Dateisystemtyp MSDOS_SUPER_MAGIC hat).

/etc/

Systemspezifische Konfiguration. Dieses Verzeichs kann, muss aber nicht nur lesbar sein. Häufig wird dieses System vorab mit vom Lieferanten bereitgestellten Konfigurationsdateien befüllt, aber Anwendungen sollten keine Annahmen darüber treffen, ob dieses Verzeichnis voll oder überhaupt befüllt ist, und sollten auf Vorgaben zurückfallen, falls die Konfiguration fehlt.

/home/

Der Ort für die Home-Verzeichnisse der normalen Benutzer. Möglicherweise von mehreren Systemen gemeinsam benutzt und niemals nur lesbar. Dieses Verzeichnis sollte nur für normale Benutzer verwandt werden, niemals für Systembenutzer. Dieses Verzeichnis und möglicherweise die darin enthaltenen Verzeichnisse könnten erst spät im Systemstartprozess oder sogar erst nach der Benutzeranmeldung verfügbar werden. Dieses Verzeichnis kann auf Netzwerkdateisystemen mit eingeschränkter Funktionalität abgelegt werden, daher sollten Anwendungen nicht davon ausgehen, dass die komplette Menge der Datei-APIs für dieses Verzeichnis verfügbar ist. Anwendungen sollten im Allgemeinen dieses Verzeichnis nicht direkt referenzieren, sondern über die pro Benutzer gültige Umgebungsvariable $HOME oder über das Home-Verzeichnisfeld der Benutzerdatenbank.

/root/

Das Home-Verzeichnis des Benutzers root. Das Home-Verzeichnis des Benutzers root liegt außerhalb von /home/, um sicherzustellen, dass der Benutzer root sich selbst dann anmelden kann, wenn /home/ nicht verfügbar und eingehängt ist.

/srv/

Der Ort, an dem allgemeine Server-Nutzdaten gespeichert werden, verwaltet vom Administrator. Es gibt keine Einschränkungen, wie dieses Verzeichnis intern organisiert wird. Im Allgemeinen schreibbar und möglicherweise von mehreren Systemen gemeinsam genutzt. Dieses Verzeichnis könnte erst spät während des Systemstarts verfügbar oder schreibbar werden.

/tmp/

Der Ort für kleine temporäre Dateien. Dieses Verzeichnis wird normalerweise als Instanz »tmpfs« eingehängt und sollte daher nicht für größere Dateien verwandt werden. (Verwenden Sie /var/tmp/ für größere Dateien.) Da dieses Verzeichnis für andere Benutzer des Systems zugreifbar ist, ist es wesentlich, dass in dieses Verzeichnis nur mit mkstemp(3), mkdtemp(3) und anderen verwandten Aufrufen geschrieben wird. Dieses Verzeichnis wird typischerweise beim Systemstart bereinigt. Auch werden Dateien, auf die nicht innerhalb einer bestimmten Zeit zugegriffen wird, normalerweise gelöscht. Falls Anwendungen erkennen, dass die Variable $TMPDIR gesetzt ist, sollten sie das darin festgelegte Verzeichnis gegenüber Referenzen auf /tmp/ bevorzugen (siehe environ(7) und IEEE Std 1003.1 [4] für Details). Für weitere Details über dieses Verzeichnis, siehe /tmp und /var/tmp sicher benutzen [5] .

LAUFZEITDATEN

/run/

Ein Dateisystem »tmpfs«, in das Systempakete Laufzeitdaten ablegen können. Dieses Verzeichnis wird beim Systemstart bereinigt und ist im Allgemeinen nur für privilegierte Programme schreibbar. Immer schreibbar.

/run/log/

Laufzeitsystemprotokolle. Systemkomponenten können private Protokolle in diesem Verzeichnis ablegen. Immer schreibbar, selbst wenn /var/log/ noch nicht zugreifbar sein sollte.

/run/user/

Enthält benutzerbezogene Laufzeitverzeichnisse, jede normalerweise individuell als Instanz »tmpfs« eingehängt. Immer schreibbar, wird bei jedem Systemstart und wenn sich der Benutzer abmeldet bereinigt. Benutzer-Code sollte dieses Verzeichnis nicht direkt sondern mittels der Umgebungsvariablen $XDG_RUNTIME_DIR referenzieren, wie dies in der XDG-Basisverzeichnisspezifikation [2] dokumentiert ist.

VOM LIEFERANTEN BEREITGESTELLTE BETRIEBSSYSTEMRESSOURCEN

/usr/

Vom Lieferanten bereitgestellte Betriebssystemressourcen. Normalerweise nur lesbar, aber dies ist nicht zwingend. Möglicherweise von mehreren Rechnern gemeinsam benutzt. Dieses Verzeichnis sollte vom Administrator nicht verändert werden, außer bei der Installation oder Entfernung von Paketen, die vom Lieferanten bereitgestellt wurden.

/usr/bin/

Ausführbare und Binärprogramme für Benutzerbefehle, die im Suchpfad $PATH auftauchen sollen. Es wird empfohlen, in diese Verzeichnisse nur Programme abzulegen, die sinnvollerweise aus einer Shell aufgrufen werden können (z.B. keine Daemon-Programme); andere Programme sollten stattdessen in Unterverzeichnissen von /usr/lib/ abgelegt werden.

/usr/include/

C- und C++-API-Header-Dateien von Systembibliotheken.

/usr/lib/

Statische, private Daten des Lieferanten, die zu allen Architekturen kompatibel sind (aber nicht notwendigerweise architekturunabhängig). Beachten Sie, dass dies interne Programme oder andere Programme, die nicht typischerweise von der Shell aus aufgerufen werden, beinhaltet. Solche Programme können für jede vom System unterstützte Architektur sein. Legen Sie in dieses Verzeichnis keine öffentlichen Bibliotheken, verwenden Sie stattdessen $libdir (siehe unten).

/lib/Arch-Kennung/

Ort zur Ablage dynamischer Bibliotheken, auch $libdir benannt. Die zu verwendende Architekturkennung ist in der Liste Multiarch-Architekturkennungen (Tupel) [6] definiert. Veraltete Orte für $libdir sind /lib/, /lib64/. Dieses Verzeichnis sollte nicht für paketspezifische Daten verwandt werden, außer diese Daten sind auch architekturabhängig. Um $libdir bezüglich der primären Architektur des Systems abzufragen, rufen Sie Folgendes auf:

# systemd-path system-library-arch

/usr/share/

Von mehreren Paketen gemeinsam benutzte Ressourcen, wie Dokumentation, Handbuchseiten, Zeitzoneninformationen, Schriften und andere Ressourcen. Normalerweise unterliegt der genaue Ort und das Format der unterhalb dieses Verzeichnisses gespeicherten Dateien Vorgaben, die die Interoperabilität sicherstellen.

/usr/share/doc/

Dokumentation für das Betriebssystem oder Systempakete.

/usr/share/factory/etc/

Depot für durch Lieferanten bereitgestellte Vorgabekonfigurationsdateien. Dieses Verzeichnis sollte mit unverfälschten Versionen sämtlicher vom Lieferanten bereitgestellten Konfigurationsdateien, die in /etc/ abgelegt werden könnten, bestückt werden. Dies ist nützlich, um die lokale Konfiguration eines Systems mit den Vorgaben des Lieferanten zu vergleichen und die lokalen Konfigurationen mit den Vorgaben zu bestücken.

/usr/share/factory/var/

Ähnlich /usr/share/factory/etc/, aber für Lieferantenversionen von Dateien in dem variablen, dauerhaften Datenverzeichnis /var/.

DAUERHAFTE VARIABLE SYSTEMDATEN

/var/

Dauerhafte, variable Systemdaten. Muss schreibbar sein. Dieses Verzeichnis kann mit vom Lieferanten bereitgestellten Daten vorbestückt sein, aber Anwendungen sollten in der Lage sein, notwendige Dateien und Verzeichnisse in dieser Unterhierarchie wieder herzustellen, falls sie fehlen, da das System hochfahren könnte, ohne dass dieses Verzeichnis bestückt ist. Dauerhaftigkeit wird empfohlen, ist aber optional, um kurzlebige Systeme zu unterstützen. Dieses Verzeichnis könnte erst spät beim Systemstart verfügbar oder schreibbar werden. Komponenten, die für den Betrieb während der frühen Systemstartphase benötigt werden, dürfen daher nicht bedingungslos von diesem Verzeichnis abhängen.

/var/cache/

Dauerhafte Systemzwischenspeicherdaten. Systemkomponenten können entbehrliche Daten in dieses Verzeichnis ablegen. Entleerung dieses Verzeichnisses sollte keine Auswirkung auf den Betrieb von Programmen haben, außer für erhöhte Laufzeit, notwendig, um diese Zwischenspeicher neu aufzubauen.

/var/lib/

Dauerhafte Systemdaten. Systemkomponenten können private Daten in dieses Verzeichnis ablegen.

/var/log/

Dauerhafte Systemprotokolle. Systemkomponenten können private Protokolle in dieses Verzeichnis ablegen, allerdings wird empfohlen, den Großteil der Protokollierung über Aufrufe von syslog(3) und sd_journal_print(3) durchzuführen.

/var/spool/

Dauerhafte System-Spool-Daten, wie Drucker- oder E-Mail-Warteschlangen.

/var/tmp/

Der Ort für größere und dauerhafte temporäre Dateien. Im Gegensatz zu /tmp/ wird in dieses Verzeichnis normalerweise ein dauerhaftes physisches Dateisystem eingehängt und kann größere Dateien akzeptieren. (Verwenden Sie /tmp für kleinere Dateien.) Dieses Verzeichnis wird typischerweise beim Systemstart nicht bereinigt, aber zeitbasiertes Aufräumen von Dateien, auf die in einer bestimmten Zeit nicht zugegriffen wurde, wird durchgeführt. Es gelten die gleichen Sicherheitseinschränkungen wie bei /tmp, und daher sollten nur mkstemp(3), mkdtemp(3) oder ähnliche Aufrufe zur Verwendung dieses Verzeichnisses eingesetzt werden. Falls Anwendungen erkennen, dass die Variable $TMPDIR gesetzt ist, sollten sie das darin festgelegte Verzeichnis gegenüber Referenzen auf /var/tmp bevorzugen (siehe environ(7) für Details). Für weitere Details über dieses Verzeichnis, siehe /tmp und /var/tmp sicher benutzen [5] .

VIRTUELLE KERNEL- UND API-DATEISYSTEME

/dev/

Das Wurzelverzeichnis für Geräteknoten. Normalerweise wird dieses Verzeichnis als »devtmpfs«-Instanz eingehängt, in Sandbox-/Container-Installationen kann es aber ein anderer Typ sein. Dieses Verzeichnis wird gemeinsam vom Kernel und systemd-udevd(8) verwaltet und andere Komponenten sollten nicht darein schreiben. Eine Reihe von virtuellen Dateisystemen für spezielle Zwecke könnten unterhalb dieses Verzeichnisses eingehängt sein.

/dev/shm/

Platz für gemeinsame Speichersegmente gemäß POSIX, wie sie von shm_open(3) erstellt werden. Dieses Verzeichnis wird beim Systemstart entleert und ist ein »tmpfs«-Dateisystem. Da alle Benutzer in diesem Verzeichnis Schreibrechte haben, sollte besondere Vorsicht walten gelassen werden, um Namenskollisionen und Verwundbarkeiten zu vermeiden. Für normale Benutzer werden gemeinsam benutzte Speichersegmente in diesem Verzeichnis normalerweise gelöscht, wenn sich der Benutzer abmeldet. Normalerweise ist es daher eine bessere Idee, Speicher-gemappte Dateien in /run/ (für Systemprogramme) oder in $XDG_RUNTIME_DIR (für Benutzerprogramme) statt gemeinsamen Speichersegementen gemäß POSIX zu verwenden, da diese Verzeichnisse nicht für das gesamte System schreibbar und daher nicht für Sicherheits-sensible Namenskollisionen verwundbar sind.

/proc/

Ein virtuelles Kerneldateisystem, das die Prozesslisten und andere Funktionalitäten offenlegt. Dieses Dateisystem ist hauptsächlich ein API als Schnittstelle für den Kernel und kein Ort, an dem normale Dateien gespeichert werden dürfen. Für Details siehe proc(5). Eine Reihe von virtuellen Dateisystemen für spezielle Zwecke könnten unterhalb dieses Verzeichnisses eingehängt sein.

/proc/sys/

Eine Hierarchie unter /proc/, die eine Reihe von Kerneleinstellern offenlegt. Die primäre Art, die Einstellungen in diesem API-Dateibaum zu konfigurieren, ist mittels sysctl.d(5)-Dateien. In Sandbox-/Container-Umgebungen ist dieses Verzeichnis im Allgemeinen nur lesbar eingehängt.

/sys/

Ein virtuelles Kerneldateisystem, das entdeckte Geräte und andere Funktionalitäten offenlegt. Dieses Dateisystem ist hauptsächlich ein API, um an den Kernel zu koppeln und kein Ort, an dem normale Dateien gespeichert werden dürfen. In Sandbox-/Container-Umgebungen ist dieses Verzeichnis im Allgemeinen nur lesbar eingehängt. Eine Reihe von virtuellen Dateisystemen für spezielle Zwecke könnten unterhalb dieses Verzeichnisses eingehängt sein.

KOMPATIBILITÄTS-SYMLINKS

/bin/, /sbin/, /usr/sbin/

Diese Kompatibilitätssymlinks zeigen auf /usr/bin/ und stellen sicher, dass Skripte und Programme, die diese veralteten Pfade referenzieren, korrekt ihre Programme finden.

/lib/

Diese Kompatibilitätssymlinks zeigen auf /lib/ und stellen sicher, dass Programme, die diesen veralteten Pfad referenzieren, korrekt ihre Ressourcen finden.

/lib64/

Auf einigen Architektur-ABIs zeigt dieser Kompatibilitätssymlink auf $libdir, um sicherzustellen, dass Programme, die diesen veralteten Pfad referenzieren, korrekt ihre dynamischen Lader finden. Dieser Symlink existiert nur auf Architekturen, deren ABI den dynamischen Lader in diesem Pfad ablegt.

/var/run/

Dieser Kompatibilitätssymlink zeigt auf /run/, um sicherzustellen, dass Programme, die diesen veralteten Pfad referenzieren, korrekt ihre Laufzeitdaten finden.

HOME-VERZEICHNIS

Benutzeranwendungen könnten Dateien und Verzeichnisse in dem Home-Verzeichnis des Benutzers ablegen wollen. Dies sollte der folgenden grundlegenden Struktur folgen. Hinweis: Einige dieser Verzeichnisse sind auch durch die XDG-Basisverzeichnisspezifikation [2] standardisiert (allerdings schwächer). Zusätzliche Orte für abstrakte Benutzerressourcen werden durch xdg-user-dirs [3] definiert.

~/.cache/

Dauerhafte Benutzerzwischenspeicherdaten. Benutzerprogramme können entbehrliche Daten in dieses Verzeichnis ablegen. Entleerung dieses Verzeichnisses sollte keine Auswirkung auf den Betrieb von Programmen haben, außer eine erhöhte Laufzeit, notwendig, um diese Zwischenspeicher neu aufzubauen. Falls eine Anwendung ein gesetztes $XDG_CACHE_HOME findet, sollte es das darin festgelegte Verzeichnis statt dieses Verzeichnisses verwenden.

~/.config/

Anwendungskonfiguration und -zustand. Wenn ein neuer Benutzer erstellt wird, wird dieses Verzeichnis leer sein oder überhaupt nicht existieren. Anwendungen sollten auf Vorgaben zurückfallen, falls ihre Konfiguration oder ihr Zustand in diesem Verzeichnis fehlt. Falls eine Anwendung ein gesetztes $XDG_CONFIG_HOME findet, sollte es das darin festgelegte Verzeichnis statt dieses Verzeichnisses verwenden.

~/.local/bin/

Programme, die im Suchpfad $PATH des Benutzers auftauchen sollen. Es wird empfohlen, in diese Verzeichnisse nur Programme abzulegen, die sinnvollerweise aus einer Shell aufgerufen werden können; andere Programme sollten stattdessen in Unterverzeichnissen von ~/.local/lib/ abgelegt werden. Bei der Ablage von architekturabhängigen Programmen sollte Sie an diesem Platz Vorsicht walten lassen, da diese problematisch sein könnten, falls das Home-Verzeichnis auf verschiedenen Rechnern mit verschiedenen Architekturen gemeinsam benutzt wird.

~/.local/lib/

Statische, private Lieferantendaten, die zu allen Architekturen kompatibel sind.

~/.local/lib/Architekturkennung/

Ort zur Ablage öffentlicher Laufzeitbibliotheken. Die zu verwendende Architekturkennzeichnung ist in der Liste Multiarch-Architekturkennungen (Tupel) [6] definiert.

~/.local/share/

Ressourcen, die von mehreren Paketen gemeinsam benutzt werden, wie Schriften oder Abbildungen. Normalerweise ist der genaue Ort und das Format der Dateien, die unterhalb dieses Verzeichnisses gespeichert werden, abhängig von der Spezifikation, die die Interoperabilität sicherstellt. Falls eine Anwendung ein gesetztes $XDG_DATA_HOME findet, sollte es das darin festgelegte Verzeichnis statt dieses Verzeichnisses verwenden.

NICHT PRIVILEGIERTER SCHREIBZUGRIFF

Nicht privilegierten Prozessen fehlt im Allgemeinen der Schreibzugriff auf den Großteil der Hierarchie.

Die Ausnahmen für normale Benutzer sind /tmp/, /var/tmp/, /dev/shm/ sowie das Home-Verzeichnis $HOME (normalerweise unterhalb von /home/) und das Laufzeitverzeichnis $XDG_RUNTIME_DIR (unterhalb von /run/user/) des Benutzers, die alle schreibbar sind.

Für nicht privilegierte Systemprozesse sind nur /tmp/, /var/tmp/ und /dev/shm/ schreibbar. Falls ein nicht privilegierter Systemprozess ein privates schreibbares Verzeichnis in /var/ oder /run/ benötigt, wird empfohlen, es entweder vor der Abgabe von Privilegien im Daemon-Code oder es mittels tmpfiles.d(5)-Fragementen während des Systemstarts oder mittels der Anweisungen StateDirectory= und RuntimeDirectory= in Dienste-Units (siehe systemd.unit(5) für Details) zu erzeugen.

KNOTENTYPEN

Unix-Dateisysteme unterstützen verschiedene Arten von Dateiknoten, einschließlich regulärer Dateien, Verzeichnisse, Symlinks, Zeichen- und Blockgeräteknoten, Sockets und FIFOs.

Es wird nachdrücklich empfohlen, dass /dev/ der einzige Ort ist, unterhalb dessen Geräteknoten abgelegt werden. Ähnlich sollte /run/ der einzige Ort sein, an dem Sockets und FIFOs abgelegt werden. Reguläre Dateien, Verzeichnisse und Symlinks können in allen Verzeichnissen verwandt werden.

SYSTEMPAKETE

Entwickler von Systempaketen sollten strengen Regeln beim Ablegen ihrer eigenen Dateien im Dateisystem folgen. Die nachfolgende Tabelle führt empfohlene Orte für bestimmte, vom Lieferanten bereitgestellte Dateien auf.

Tabelle 1. Ort für Lieferantendateien aus Systempaketen
Zusätzliche statische Lieferantendateien können in der Hierarchie /usr/share an die Orte, die durch verschiedene, zutreffende Spezifikationen festgelegt werden, installiert werden.

Während der Laufzeit und für lokale Konfiguration und Zustand sind zusätzliche Verzeichnisse definiert:

Tabelle 2. Ort für variable Dateien aus Systempaketen

BENUTZERPAKETE

Programme, die im Benutzerkontext laufen, sollten strengen Regeln bei der Ablage ihrer eigenen Dateien im Home-Verzeichnis des Benutzers folgen. Die nachfolgende Tabelle führt empfohlene Orte im Home-Verzeichnis für bestimmte Arten von Dateien des Lieferanten auf, falls die Anwendung im Home-Verzeichnis installiert ist. (Beachten Sie allerdings, dass Benutzeranwendungen, die systemweit installiert sind, den oben dargelegten Regeln bezüglich der Ablage der Lieferantendateien folgen sollten.)

Tabelle 3. Ort für Lieferantendateien aus Benutzerpaketen
Zusätzliche statische Lieferantendateien können in der Hierarchie ~/.local/share/ in den durch verschiedene relevante Spezifikationen definierten Orten abgelegt werden.

Während der Laufzeit und für lokale Konfiguration und Zustand sind zusätzliche Verzeichnisse definiert:

Tabelle 4. Ort für variable Dateien aus Benutzerpaketen

SIEHE AUCH

systemd(1), hier(7), systemd-path(1), systemd-gpt-auto-generator(8), sysctl.d(5), tmpfiles.d(5), pkg-config(1), systemd.unit(5)

ANMERKUNGEN

http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

https://www.freedesktop.org/wiki/Software/xdg-user-dirs/

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

https://systemd.io/TEMPORARY_DIRECTORIES

https://wiki.debian.org/Multiarch/Tuples

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian [AT] 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 [AT] lists.org>.