/usr — Unix System Resources

Was ist /usr?

/usr enthält den Userspace eines Linux-Systems — alles, was zur Distribution gehört, vom Compiler über die Shell bis zum Desktop-Environment. Auf einer Standard-Installation füllt /usr typischerweise 80–95 % des Root-Filesystems: ein Server-Image hat selten mehr als 1–2 GB außerhalb von /usr, ein Desktop-System mit GNOME oder KDE leicht 8–15 GB allein in /usr.

Der FHS-Standard (3.0, Kapitel 4) schreibt zwei Kerneigenschaften fest:

1. /usr enthält shareable, read-only Daten — also Software und Ressourcen, die von mehreren Maschinen gemeinsam genutzt werden könnten und sich zur Laufzeit nicht ändern.
2. Innerhalb von /usr liegen Programme, Bibliotheken und Dokumentation architektur-spezifisch oder architektur-unabhängig sortiert.

Historischer Kontext: in frühen Unix-Systemen lagen User-Home-Verzeichnisse direkt unter /usr/<username>/ — daher der Name. Mit zunehmender Trennung der Systembereiche wanderten die Heimat-Verzeichnisse nach /home, und /usr wurde zum Speicher für die Distribution-Software.

Die Struktur unter /usr

/usr ist intern streng strukturiert — fast jeder Unterordner hat eine klar definierte Aufgabe:

Die Trennung zwischen /usr/bin und /usr/lib ist wichtig: /usr/bin enthält Programme, die direkt aus der Shell aufgerufen werden, /usr/lib enthält Bibliotheken, die von Programmen geladen werden, sowie interne Helper, die nicht im PATH stehen sollen.

sudo du -sh /usr/* 2>/dev/null | sort -hr
# 6.2G  /usr/lib
# 3.1G  /usr/share
# 1.2G  /usr/bin
# 240M  /usr/include
# 180M  /usr/src
# 86M   /usr/sbin
# 28M   /usr/local
# ...

/usr/local — der eigene Userspace

/usr/local hat einen Sonderstatus: es ist explizit für lokal installierte oder selbst-kompilierte Software reserviert. Der Paketmanager fasst es nicht an, deshalb können eigene Installationen nie mit Paket-Updates kollidieren — und Distributions-Updates überschreiben nichts, was du selbst kompiliert hast.

Die interne Struktur spiegelt /usr als Mini-System:

Der Klassiker-Workflow: ./configure --prefix=/usr/local && make && sudo make install. Damit landen alle Bestandteile sortiert in den passenden /usr/local/*-Unterordnern.

# Eigenes Skript bereitstellen
sudo install -m 755 mein-tool.sh /usr/local/bin/mein-tool

# PATH-Reihenfolge prüfen
echo "$PATH"
# /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# type zeigt, welche Version effektiv genutzt wird
type -a python3
# python3 is /usr/local/bin/python3   ← lokale Version
# python3 is /usr/bin/python3         ← Distributions-Version

Der wichtige Punkt: /usr/local/bin steht in der Standard-PATH-Reihenfolge vor /usr/bin. Eine selbst kompilierte Version eines Tools übersteuert automatisch die Distributions-Version, ohne dass du etwas konfigurieren musst.

Read-Only-Ambitionen und atomare Updates

Eine zentrale Eigenschaft, die der FHS für /usr festschreibt: das Verzeichnis darf read-only mountbar sein. Programme dürfen also zur Laufzeit nichts schreiben, was unter /usr liegt — schreibbarer State gehört nach /var, /home oder /tmp.

Diese Eigenschaft ist die Grundlage für eine ganze Klasse moderner Distributions-Architekturen:

Vorteile dieser Modelle:

• Atomare Updates. Entweder das gesamte Update wird wirksam, oder gar keins — keine halb-aktualisierten Zustände nach Strom-Aus.
• Rollback per Boot. Ein voriger /usr-Snapshot ist beim Bootloader auswählbar, falls ein Update Probleme macht.
• Reproduzierbare Systeme. Mehrere Maschinen mit demselben /usr-Image sind bit-identisch.

In der klassischen Welt (Debian, Arch, openSUSE Tumbleweed in der Standard-Installation) ist /usr read-write, aber das Prinzip „nichts schreibt zur Laufzeit hier rein" gilt trotzdem — Anwendungen, die Logfiles in /usr ablegen oder dort Caches anlegen, gelten als FHS-Verstoß.

Usr-Merge: warum / und /usr heute zusammenfallen

Auf modernen Distributionen sind /bin, /sbin, /lib etc. Symlinks auf die entsprechenden Unterverzeichnisse von /usr — diese Vereinheitlichung heißt Usr-Merge. Initiiert von Fedora 17 (2012), heute Standard auf praktisch allen wichtigen Distributionen (Debian 12+, Ubuntu 19.04+, RHEL 9+, Arch, openSUSE).

Inhaltlich liegt nach dem Usr-Merge alles unter /usr:

ls -la / | grep -E '^l'
# lrwxrwxrwx ... bin   -> usr/bin
# lrwxrwxrwx ... lib   -> usr/lib
# lrwxrwxrwx ... lib64 -> usr/lib64
# lrwxrwxrwx ... sbin  -> usr/sbin

# /bin/ls und /usr/bin/ls sind dieselbe Datei
stat /bin/ls /usr/bin/ls | grep Inode
# Inode: 12345
# Inode: 12345

Konsequenzen für den Alltag:

• Skripte mit #!/bin/bash und #!/usr/bin/bash funktionieren beide.
• Bei der Suche nach Programmen ist es egal, ob du find /bin oder find /usr/bin schreibst — das Ergebnis ist identisch.
• Beim Backup oder Snapshot musst du nur /usr und einige spezifische Pfade (/etc, /var, /home, /root) sichern — /bin, /sbin, /lib sind über die Symlinks bereits abgedeckt.
• Beim Schreiben von Dateien: lege niemals Inhalte direkt nur in /bin oder /lib ab und erwarte sie nicht zwingend in /usr/bin — die Symlinks lösen das transparent auf, aber für saubere Skripte bezieh dich immer auf /usr/bin/....

Mehr zum Usr-Merge findest du im Artikel zu /bin.

Praxis: /usr inspizieren

# Gesamt-Größe
sudo du -sh /usr

# Größte Pakete in /usr/lib (oft Browser, Office, Compiler)
sudo du -ah /usr/lib | sort -hr | head -10

# Anzahl Programme in /usr/bin
ls /usr/bin | wc -l
# ca. 1500–4000 auf einem voll installierten Desktop

# Welches Paket bringt welche Datei? (Ubuntu/Debian)
dpkg -S /usr/bin/python3
# python3-minimal: /usr/bin/python3

# Manpages für ein Programm finden
ls /usr/share/man/man1/ls*
# /usr/share/man/man1/ls.1.gz

# Welche shared libraries lädt ein Programm?
ldd /usr/bin/git | head
# libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6
# ...

# Inverse Suche: wer nutzt diese Bibliothek?
sudo apt-rdepends --reverse libc6 2>/dev/null | head

# Klassischer GNU-Workflow
cd /tmp
wget https://example.com/cooltool-1.0.tar.gz
tar xf cooltool-1.0.tar.gz
cd cooltool-1.0

./configure --prefix=/usr/local
make -j$(nproc)
sudo make install

# Hinterher in /usr/local sichtbar
ls /usr/local/bin/cooltool
# /usr/local/bin/cooltool

# Beim späteren Entfernen: meist sudo make uninstall im selben
# Source-Tree (deshalb Source-Trees aufheben oder Tools wie
# checkinstall / paco / stow nutzen).

Weiterführende Ressourcen

Externe Quellen

• Filesystem Hierarchy Standard 3.0 — /usr
• Fedora Silverblue Architecture
• GNU Stow Documentation
• Debian Multi-Arch Wiki
• Linux man-pages: hier(7) — Verzeichnisstruktur

Verwandte Artikel

• Verzeichnisstruktur — Übersicht
• /bin — Essenzielle Benutzer-Binaries
• /var — Variable Daten und Logs
• /etc — Systemkonfiguration
• PATH-Variable und wie die Shell Programme findet
• Pakete kompilieren aus Quellen