Provided by: manpages-de_4.21.0-2_all bug

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 239.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

       /tmp/
           Der Ort für kleine, temporäre Dateien. Dieses Verzeichnis wird normalerweise als
           »tmpfs«-Instanz eingehängt und sollte daher nicht für größere Dateien verwandt werden.
           (Verwenden Sie /var/tmp/ für größere Dateien.) Dieses Verzeichnis wird normalerweise
           beim Systemstart geleert. Es können auch Dateien, auf die innerhalb einer bestimmten
           Zeit nicht zugegriffen wurde, automatisch gelöscht werden.

           Falls Anwendungen die gesetzte Umgebungsvariable $TMPDIR finden, sollten Sie das darin
           festgelegte Verzeichnis statt /tmp/ verwenden (siehe environ(7) und IEEE Std 1003.1[4]
           für Details).

           Da auf /tmp/ von anderen Benutzern des Systems aus zugegriffen werden kann, ist es
           wesentlich, dass Dateien und Unterverzeichnisse unter diesem Verzeichnis nur mit
           mkstemp(3), mkdtemp(3) und ähnlichen Aufrufen erstellt werden. Für weitere Details
           siehe Sichere Verwendung von /tmp/ und /var/tmp/[5].

           Hinzugefügt in Version 215.

LAUFZEITDATEN

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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.

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

       /usr/include/
           C- und C++-API-Header-Dateien von Systembibliotheken.

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

       /usr/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 /usr/lib/, /usr/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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

       /usr/share/doc/
           Dokumentation für das Betriebssystem oder Systempakete.

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

DAUERHAFTE VARIABLE SYSTEMDATEN

       /var/
           Dauerhafte, variable Systemdaten. Während des normalen Betriebs des Systems
           beschreibbar. 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.

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

       /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, kurzlebigere
           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.

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

           Es gelten die gleichen Sicherheitseinschränkungen wie bei /tmp: mkstemp(3), mkdtemp(3)
           und ähnliche Aufrufe sollten verwandt werden. Für weitere Details über dieses
           Verzeichnis, siehe Sichere Verwendung von /tmp und /var/tmp[5].

           Hinzugefügt in Version 215.

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.

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

       /sys/fs/cgroup/
           Ein virtuelles Kerneldateisystem, das die Prozess-Control-Gruppen (Cgroups) offenlegt.
           Dieses Dateisystem ist eine API zu Schnittstellen im Kernel und kein Ort, an dem
           normale Dateien gespeichert werden dürfen. Auf aktuellen Systemen, die im
           Standardmodus »vereinigt« laufen, dient dieses Verzeichnis als der Einhängepunkt für
           das »cgroup2«-Dateisystem, das eine vereinigte Ggroup-Hierarchie für alle
           Ressourcen-Controller bereitstellt. Auf Systemen, die nicht-Standard-Konfigurationen
           verwenden, darf dieses Verzeichniss stattdessen ein Tmpfs-Dateisystem sein, das die
           Einhängepunkte für die verschiedenen »cgroup«- (v1-)-Ressourcen-Controller enthält; in
           diesen Konfigurationen wird »cgroup2« (falls überhaupt) unter /sys/fs/cgroup/unified/
           eingehängt, aber an Cgroup2 werden keine Ressourcen-Controller angehängt. In Sandbox-
           oder Container-Installationen kann dieses Verzeichnis entweder nicht existieren oder
           darf eine Untermenge der Funktionalität enthalten.

           Hinzugefügt in Version 251.

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.

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

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.

           Hinzugefügt in Version 215.

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

           Hinzugefügt in Version 215.

       ~/.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.

           Hinzugefügt in Version 215.

       ~/.local/lib/
           Statische, private Lieferantendaten, die zu allen Architekturen kompatibel sind.

           Hinzugefügt in Version 215.

       ~/.local/lib/Architekturkennung/
           Ort zur Ablage öffentlicher dynamischer Bibliotheken. Die zu verwendende
           Architekturkennzeichnung ist in der Liste Multiarch-Architekturkennungen (Tupel)[6]
           definiert.

           Hinzugefügt in Version 215.

       ~/.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.

           Hinzugefügt in Version 215.

       ~/.local/state/
           Anwendungszustand. Wenn ein neuer Benutzer erstellt wird, wird dieses Verzeichnis leer
           sein oder überhaupt nicht existieren. Anwendungen sollten auf Vorgaben zurückfallen,
           falls ihre ihr Zustand in diesem Verzeichnis fehlt. Falls eine Anwendung ein gesetztes
           $XDG_STATE_HOME findet, sollte es das darin festgelegte Verzeichnis statt dieses
           Verzeichnisses verwenden.

           Hinzugefügt in Version 254.

SCHREIBZUGRIFF

   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.

       /tmp/, /var/tmp/ und /dev/shm/ sollten nosuid und nodev eingehängt werden, wodurch Dateien
       mit set-user-id-Modus und Blockspezialgeräte auf diesen Dateisystemen nicht interpretiert
       werden. Im Allgemeinen ist es nicht möglich, sie mit noexec einzuhängen, da verschiedene
       Programme diese Verzeichnisse für dynamisch erstellten oder optimierten Code verwenden und
       mit diesem Schalter diese Anwendungsszenarien fehlschlagen würden. Auf
       Spezialinstallationen oder Systemen, auf denen sämtliche installierbare Software bekannt
       ist und diese Funktionalität nicht benötigt, ist die Verwendung dieses Schalters möglich.
       Siehe die Diskussion von nosuid/nodev/noexec in mount(8) und PROT_EXEC in mmap(2).

   Fehlen von Schreibzugriff auf schreibgeschützten Systemen und während der
       Systemwiederherstellung
       Wie oben angemerkt arbeiten einige Systeme mit schreibgeschützten /usr- und
       /etc-Hierarchien, möglicherweise wird der Schreibzugriff nur während Paket-Upgrades
       erlaubt. Andere Teile der Hierarchie werden im Allgemeinen lese- und schreibbar eingehängt
       (insbesondere /var und /var/tmp), könnten aber schreibgeschützt sein, wenn der Kernel die
       Dateisysteme in Folge eines Fehlers schreibgeschützt neu einhängt oder wenn das System
       schreibgeschützt zu Wiederherstellungszwecken gestartet wird. Soweit angemessen, sollten
       Anwendungen darauf vorbereitet sein, ohne Schreibzugriff zu arbeiten, so dass
       beispielsweise ein Fehler beim Schreiben nicht wesentlicher Daten nach /var/cache/ oder
       ein Fehler beim Erstellen einer angepassten Protokolldatei unter /var/log nicht dazu
       führt, dass die Anwendung nicht läuft.

       Das Verzeichnis /run/ ist seit der frühsten Systemstartphase verfügbar und kann immer
       beschrieben werden. Es sollte für alle Laufzeitdaten und -Sockets verwandt werden, so dass
       Schreibzugriff auf z.B. /etc oder /var nicht notwendig ist.

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 eigener 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
       ┌───────────────────────────────────┬──────────────────────────────────┐
       │VerzeichnisZweck                            │
       ├───────────────────────────────────┼──────────────────────────────────┤
       │/usr/bin/                          │ Paketprogramme, die im           │
       │                                   │ ausführbaren Suchpfad $PATH      │
       │                                   │ auftauchen sollen, für eine der  │
       │                                   │ unterstützten Architekturen, die │
       │                                   │ zum Betriebssystem kompatibel    │
       │                                   │ ist, kompiliert. Es wird nicht   │
       │                                   │ empfohlen, interne Programme     │
       │                                   │ oder Programme, die              │
       │                                   │ typischerweise nicht von der     │
       │                                   │ Shell aufgerufen werden, wie     │
       │                                   │ Daemon-Programme, hier           │
       │                                   │ abzulegen. Da dieses Verzeichnis │
       │                                   │ mit den meisten anderen Paketen  │
       │                                   │ des Systems gemeinsam benutzt    │
       │                                   │ wird, sollte besondere Sorgfalt  │
       │                                   │ darauf verwandt werden, für hier │
       │                                   │ abzulegende Dateien eindeutige   │
       │                                   │ Namen auszuwählen, die           │
       │                                   │ wahrscheinlich nicht in Konflikt │
       │                                   │ zu den Dateien anderer Pakete    │
       │                                   │ stehen.                          │
       ├───────────────────────────────────┼──────────────────────────────────┤
       │/usr/lib/Arch-Kennung/             │ Öffentliche dynamische           │
       │                                   │ Bibliotheken des Pakets. Wie     │
       │                                   │ oben sollten Sie sorgfältig bei  │
       │                                   │ der Verwendung zu generischer    │
       │                                   │ Namen sein und eindeutige Namen  │
       │                                   │ für Ihre hier abzulegenden       │
       │                                   │ Dateien wählen, um               │
       │                                   │ Namenskonflikte zu vermeiden.    │
       ├───────────────────────────────────┼──────────────────────────────────┤
       │/usr/lib/Paket/                    │ Private statische                │
       │                                   │ Lieferantenressourcen des        │
       │                                   │ Pakets, einschließlich privater  │
       │                                   │ Programme und Bibliotheken oder  │
       │                                   │ jede andere Art von              │
       │                                   │ rein-lesbaren Lieferantendaten.  │
       ├───────────────────────────────────┼──────────────────────────────────┤
       │/usr/lib/Architekturkennung/Paket/ │ Private weitere                  │
       │                                   │ Lieferantenressourcen des        │
       │                                   │ Pakets, die architekturabhängig  │
       │                                   │ sind und nicht von verschiedenen │
       │                                   │ Architekturen gemeinsam benutzt  │
       │                                   │ werden können. Beachten Sie,     │
       │                                   │ dass dies im Allgemeinen keine   │
       │                                   │ privaten Programme einschließt,  │
       │                                   │ da Programme einer bestimmten    │
       │                                   │ Architektur frei von jeder       │
       │                                   │ anderen unterstützten            │
       │                                   │ Systemarchitektur aufgerufen     │
       │                                   │ werden können.                   │
       ├───────────────────────────────────┼──────────────────────────────────┤
       │/usr/include/Paket/                │ Öffentliche C/C++-APIs von       │
       │                                   │ öffentlichen dynamischen         │
       │                                   │ Bibliotheken des Pakets.         │
       └───────────────────────────────────┴──────────────────────────────────┘

       Zusätzliche statische Lieferantendateien können in der Hierarchie /usr/share an die Orte,
       die durch verschiedene, zutreffende Spezifikationen festgelegt werden, installiert werden.

       Die folgenden Verzeichnisse müssen für durch das Paket für lokale Konfiguration und zur
       Laufzeit erstellte Dateien verwandt werden:

       Tabelle 2. Ort für variable Dateien aus Systempaketen
       ┌──────────────────┬──────────────────────────────────┐
       │VerzeichnisZweck                            │
       ├──────────────────┼──────────────────────────────────┤
       │/etc/Paket/       │ Systemspezifische Konfiguration  │
       │                  │ für das Paket. Es wird           │
       │                  │ empfohlen, standardmäßig sichere │
       │                  │ Rückfalloptionen zu verwenden,   │
       │                  │ falls diese Konfiguration fehlt, │
       │                  │ falls das möglich ist.           │
       │                  │ Alternativ kann ein              │
       │                  │ tmpfiles.d(5)-Fragment verwandt  │
       │                  │ werden, um die notwendigen       │
       │                  │ Dateien und Verzeichnisse von    │
       │                  │ /usr/share/factory/ während des  │
       │                  │ Systemstarts mittels der         │
       │                  │ Anweisungen »L« oder »C« zu      │
       │                  │ symlinken oder zu kopieren.      │
       ├──────────────────┼──────────────────────────────────┤
       │/run/Pakete/      │ Laufzeitdaten für das Paket.     │
       │                  │ Pakete müssen in der Lage sein,  │
       │                  │ die notwendigen                  │
       │                  │ Unterverzeichnisse in diesem     │
       │                  │ Baum selbst zu erstellen, da das │
       │                  │ Verzeichnis beim Systemstart     │
       │                  │ automatisch geleert wird.        │
       │                  │ Alternativ kann ein              │
       │                  │ tmpfiles.d(5)-Fragment verwandt  │
       │                  │ werden, um die notwendigen       │
       │                  │ Verzeichnisse während des        │
       │                  │ Systemstarts zu erstellen oder   │
       │                  │ die Anweisung RuntimeDirectory=  │
       │                  │ von Dienste-Units kann verwandt  │
       │                  │ werden, um sie beim Hochfahren   │
       │                  │ des Dienstes zu erstellen (siehe │
       │                  │ systemd.unit(5) für Details).    │
       ├──────────────────┼──────────────────────────────────┤
       │/run/log/Paket/   │ Laufzeitprotokolldaten für das   │
       │                  │ Paket. Wie oben muss das Paket   │
       │                  │ sicherstellen, dieses            │
       │                  │ Verzeichnis falls notwendig zu   │
       │                  │ erstellen, da es bei jedem       │
       │                  │ Systemstart bereinigt wird.      │
       ├──────────────────┼──────────────────────────────────┤
       │/var/cache/Paket/ │ Dauerhafte Zwischenspeicherdaten │
       │                  │ des Pakets. Falls dieses         │
       │                  │ Verzeichnis geleert wird, sollte │
       │                  │ die Anwendung beim nächsten      │
       │                  │ Aufruf korrekt arbeiten,         │
       │                  │ allerdings möglicherweise        │
       │                  │ verlangsamt, da sie alle lokalen │
       │                  │ Zwischenspeicherdateien neu      │
       │                  │ aufbauen muss. Die Anwendung     │
       │                  │ muss in der Lage sein, dieses    │
       │                  │ Verzeichnis wieder zu erstellen, │
       │                  │ falls es fehlt und notwendig     │
       │                  │ ist. Um ein leeres Verzeichnis   │
       │                  │ zu erstellen, kann ein           │
       │                  │ tmpfiles.d(5)-Fragment oder die  │
       │                  │ Anweisung CacheDirectory= von    │
       │                  │ Dienste-Units (siehe             │
       │                  │ systemd.unit(5)) verwandt        │
       │                  │ werden.                          │
       ├──────────────────┼──────────────────────────────────┤
       │/var/lib/Paket/   │ Dauerhafte private Daten des     │
       │                  │ Pakets. Dies ist der Hauptort,   │
       │                  │ um dauerhafte Daten abzulegen,   │
       │                  │ die nicht in die anderen         │
       │                  │ aufgeführten Kategorien fallen.  │
       │                  │ Pakete sollten in der Lage sein, │
       │                  │ die notwendigen                  │
       │                  │ Unterverzeichnisse in diesem     │
       │                  │ Baum selbst zu erstellen, da das │
       │                  │ Verzeichnis beim Systemstart     │
       │                  │ fehlen könnte. Um ein leeres     │
       │                  │ Verzeichnis zu erstellen, kann   │
       │                  │ ein tmpfiles.d(5)-Fragment oder  │
       │                  │ die Anweisung CacheDirectory=    │
       │                  │ von Dienste-Units (siehe         │
       │                  │ systemd.unit(5)) verwandt        │
       │                  │ werden.                          │
       ├──────────────────┼──────────────────────────────────┤
       │/var/log/Paket/   │ Dauerhafte Protokolldaten des    │
       │                  │ Pakets. Wie oben sollte das      │
       │                  │ Paket sicherstellen, das         │
       │                  │ Verzeichnis, falls notwendig,    │
       │                  │ möglicherweise mittels           │
       │                  │ tmpfiles.d(5) oder               │
       │                  │ LogsDirectory= (siehe            │
       │                  │ systemd.exec(5)) zu erstellen,   │
       │                  │ da es fehlen könnte.             │
       ├──────────────────┼──────────────────────────────────┤
       │/var/spool/Paket/ │ Dauerhafte                       │
       │                  │ Spool-/Warteschlangendaten des   │
       │                  │ Pakets. Wie oben sollte das      │
       │                  │ Paket sicherstellen, das         │
       │                  │ Verzeichnis, falls notwendig, zu │
       │                  │ erstellen, da es fehlen könnte.  │
       └──────────────────┴──────────────────────────────────┘

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. (Systemweit installierte
       Benutzeranwendungen sind von den oben dargestellten Regeln für Lieferantendateien
       abgedeckt.)

       Tabelle 3. Lieferantenpaketorte unter dem Home-Verzeichnis des Benutzers
       ┌───────────────────────────────────────┬──────────────────────────────────┐
       │VerzeichnisZweck                            │
       ├───────────────────────────────────────┼──────────────────────────────────┤
       │~/.local/bin/                          │ Paketprogramme, die im           │
       │                                       │ ausführbaren Suchpfad $PATH      │
       │                                       │ auftauchen sollen. Es wird nicht │
       │                                       │ empfohlen, interne Programme     │
       │                                       │ oder Programme, die              │
       │                                       │ typischerweise nicht von der     │
       │                                       │ Shell aufgerufen werden, wie     │
       │                                       │ Daemon-Programme, hier           │
       │                                       │ abzulegen. Da dieses Verzeichnis │
       │                                       │ mit den meisten anderen Paketen  │
       │                                       │ des Systems gemeinsam benutzt    │
       │                                       │ wird, sollte besondere Sorgfalt  │
       │                                       │ darauf verwandt werden, für hier │
       │                                       │ abzulegende Dateien eindeutige   │
       │                                       │ Namen auszuwählen, die           │
       │                                       │ wahrscheinlich nicht in Konflikt │
       │                                       │ zu den Dateien anderer Pakete    │
       │                                       │ stehen.                          │
       ├───────────────────────────────────────┼──────────────────────────────────┤
       │~/.local/lib/Architekturkennung/       │ Öffentliche dynamische           │
       │                                       │ Bibliotheken des Pakets. Wie     │
       │                                       │ oben sollten Sie sorgfältig bei  │
       │                                       │ der Verwendung übermäßig         │
       │                                       │ generischer Namen sein und       │
       │                                       │ eindeutige Namen für Ihre hier   │
       │                                       │ abzulegenden Dateien wählen, um  │
       │                                       │ Namenskonflikte zu vermeiden.    │
       ├───────────────────────────────────────┼──────────────────────────────────┤
       │~/.local/lib/Paket/                    │ Private, statische               │
       │                                       │ Lieferantenressourcen des        │
       │                                       │ Pakets, kompatibel zu allen      │
       │                                       │ Architekturen oder jede Art von  │
       │                                       │ rein lesbaren Lieferantendaten.  │
       ├───────────────────────────────────────┼──────────────────────────────────┤
       │~/.local/lib/Architekturkennung/Paket/ │ Private andere                   │
       │                                       │ Lieferantenressourcen des        │
       │                                       │ Pakets, die architekturabhängig  │
       │                                       │ sind und nicht auf verschiedenen │
       │                                       │ Architekturen gemeinsam benutzt  │
       │                                       │ werden können.                   │
       └───────────────────────────────────────┴──────────────────────────────────┘

       Zusätzliche statische Lieferantendateien können in der Hierarchie ~/.local/share/ abgelegt
       werden und dabei die im obigen Abschnitt »Vom Lieferanten bereitgestellte
       Betriebssystemressourcen« festgelegten Verzeichnisse spiegeln.

       Die folgenden Verzeichnisse müssen für durch das Paket für benutzerbezogene lokale
       Konfiguration und zur Laufzeit erstellte Dateien verwandt werden:

       Tabelle 4. Ort für variable Dateien aus Benutzerpaketen
       ┌────────────────────────┬──────────────────────────────────┐
       │VerzeichnisZweck                            │
       ├────────────────────────┼──────────────────────────────────┤
       │~/.config/Paket/        │ Benutzerbezogene Konfiguration   │
       │                        │ und Zustand für das Paket. Es    │
       │                        │ wird verlangt, sichere           │
       │                        │ Rückfallstandardwerte zu         │
       │                        │ verwenden, falls diese           │
       │                        │ Konfiguration fehlt.             │
       ├────────────────────────┼──────────────────────────────────┤
       │$XDG_RUNTIME_DIR/Paket/ │ Benutzerlaufzeitdaten für das    │
       │                        │ Paket.                           │
       ├────────────────────────┼──────────────────────────────────┤
       │~/.cache/Paket/         │ Dauerhafte Zwischenspeicherdaten │
       │                        │ des Pakets. Falls dieses         │
       │                        │ Verzeichnis geleert wird, sollte │
       │                        │ die Anwendung beim nächsten      │
       │                        │ Aufruf korrekt arbeiten,         │
       │                        │ allerdings möglicherweise        │
       │                        │ verlangsamt, da sie alle lokalen │
       │                        │ Zwischenspeicherdateien neu      │
       │                        │ aufbauen muss. Die Anwendung     │
       │                        │ muss in der Lage sein, dieses    │
       │                        │ Verzeichnis wieder zu erstellen, │
       │                        │ falls es fehlt und notwendig     │
       │                        │ ist.                             │
       └────────────────────────┴──────────────────────────────────┘

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

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

        2. XDG-Basisverzeichnisspezifikation
           https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

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

        4. IEEE Std 1003.1
           http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

        5. Sichere Verwendung von /tmp und /var/tmp
           https://systemd.io/TEMPORARY_DIRECTORIES

        6. Multiarch-Architekturkennungen (Tupel)
           https://wiki.debian.org/Multiarch/Tuples

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von 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⟩.