Mit ln legst du in Linux einen zweiten Verweis auf eine Datei an. Es gibt zwei Arten: Hardlinks zeigen direkt auf den Inode einer Datei und sind von ihr nicht zu unterscheiden. Symbolische Links (Softlinks) speichern einen Pfad zur Originaldatei und verhalten sich wie Verknüpfungen unter anderen Betriebssystemen. Beide sind im Alltag extrem nützlich — aber konzeptionell sehr verschieden.
Was ln macht
Der ln-Befehl erzeugt einen weiteren Namen für eine bestehende Datei. Standardmäßig ist das ein Hardlink — ein zweiter Verzeichnis-Eintrag, der auf denselben Inode zeigt. Mit der Option -s legst du stattdessen einen symbolischen Link an, der nur einen Pfad als Inhalt hat.
ln [OPTION] ZIEL [LINKNAME]
ln [OPTION] ZIEL... VERZEICHNIS
ln [OPTION] -t VERZEICHNIS ZIEL...Wichtig zur Begrifflichkeit: in der ln-Manpage heißt die Originaldatei TARGET (Ziel), und der zu erstellende Name LINK_NAME. Das Argument ZIEL ist also die existierende Datei, auf die verwiesen wird — nicht der neue Eintrag.
Hardlinks vs. Symlinks
Die beiden Linkarten unterscheiden sich grundlegend in der Mechanik:
| Eigenschaft | Hardlink | Symlink (Softlink) |
|---|---|---|
| Was wird referenziert | derselbe Inode | ein Pfad als Text |
| Cross-Filesystem | nein, nur innerhalb eines FS | ja, beliebige Filesysteme |
| Bricht bei Löschung | nein, Datei bleibt bis Counter = 0 | ja, „dangling” Link |
| Auf Verzeichnisse | nein (außer . und .. durch Kernel) | ja, problemlos |
| Größe | identisch zur Originaldatei | nur Pfadlänge in Bytes |
| Berechtigungen | identisch (gleicher Inode) | eigene, meist lrwxrwxrwx, geprüft am Ziel |
| Eigentümer | identisch | eigene, geprüft am Ziel |
| Sichtbarkeit | nicht von Original unterscheidbar | ls -l zeigt link -> ziel |
| Anlegen mit | ln ZIEL LINK | ln -s ZIEL LINK |
Konzeptionell:
Verzeichnis-Einträge Inode 12345
───────────────────── ──────────────────
original.txt ──┐ Größe, Rechte,
├──────────► Zeitstempel,
link.txt ──┘ Datenblöcke,
Link-Counter: 2Inode 67890 (Symlink) Inode 12345 (Original)
────────────────────── ──────────────────
Typ: l Typ: -
Inhalt: "original.txt" ───► echte Daten
Größe: 12 BytesHardlinks im Detail
Ein Hardlink ist einfach ein zweiter Verzeichnis-Eintrag, der auf dieselbe Inode-Nummer zeigt. Im Inode wird ein Link-Counter mitgeführt — er gibt an, wie viele Namen auf diesen Inode verweisen.
echo "Inhalt" > original.txt
ln original.txt link.txt
ls -li original.txt link.txt2621442 -rw-r--r-- 2 michael users 7 Mai 4 14:22 link.txt
2621442 -rw-r--r-- 2 michael users 7 Mai 4 14:22 original.txtDie erste Spalte ist die Inode-Nummer — bei beiden Einträgen identisch. Die Zahl nach den Berechtigungen ist der Link-Counter (2, weil zwei Namen existieren). Erst wenn der Counter auf 0 fällt — also der letzte Name gelöscht wurde — gibt das Dateisystem die Datenblöcke wirklich frei.
Du kannst original.txt löschen, ohne dass die Daten verschwinden: link.txt zeigt nach wie vor auf denselben Inode, der Counter sinkt nur auf 1.
Grenzen von Hardlinks:
- Kein Cross-Filesystem. Inodes sind pro Dateisystem eindeutig — ein Hardlink von
/home(z. B. ext4) auf/mnt/usb(z. B. exFAT) ist konzeptionell unmöglich.lnschlägt mitInvalid cross-device linkfehl. - Keine Verzeichnisse. Hardlinks auf Verzeichnisse sind in modernen Linux-Filesystemen verboten, weil sie Schleifen im Verzeichnisbaum erzeugen würden. Die einzigen Ausnahmen sind die automatisch vom Kernel gepflegten Einträge
.und...
Symlinks im Detail
Ein symbolischer Link ist eine eigene kleine Datei mit eigenem Inode. Ihr Inhalt ist nur ein Pfad als Zeichenkette — beim Zugriff löst der Kernel diesen Pfad auf und folgt ihm zur Zieldatei.
ln -s /etc/hosts hosts.lnk
ls -l hosts.lnklrwxrwxrwx 1 michael users 10 Mai 4 14:30 hosts.lnk -> /etc/hostsDas l ganz vorne zeigt den Dateityp Symlink, der Pfeil -> das Ziel. Die Größe 10 ist die Länge des Pfades /etc/hosts in Bytes — keine echten Daten.
Relative Pfade — die häufigste Stolperfalle
Das ZIEL in ln -s ZIEL LINK kann absolut oder relativ angegeben werden. Bei einem relativen Pfad gilt aber eine Sonderregel:
Beispiel:
cd ~
ln -s docs/config.yaml backup/cfg
# Symlink "backup/cfg" enthält den Pfad "docs/config.yaml"
# Aufgelöst wird das aber relativ zu "backup/" — also "backup/docs/config.yaml"
readlink backup/cfg
ls -l backup/cfgdocs/config.yaml
lrwxrwxrwx 1 michael users 16 Mai 4 14:35 backup/cfg -> docs/config.yamlWenn backup/docs/config.yaml nicht existiert, ist der Link kaputt, obwohl ~/docs/config.yaml durchaus existiert. Lösung: entweder absoluten Pfad verwenden oder den korrekten relativen Pfad bezogen auf den Linkort konstruieren — ln -r macht das automatisch (siehe nächster Abschnitt).
Wichtige Optionen
-s, --symbolic Erzeugt einen symbolischen Link statt eines Hardlinks. Die mit Abstand häufigste Option.
-f, --force Überschreibt einen existierenden Linknamen ohne Rückfrage. Ohne -f schlägt ln fehl, wenn LINKNAME bereits existiert.
-i, --interactive Fragt nach, bevor ein bestehender Linkname überschrieben wird (überstimmt -f).
-n, --no-dereference Behandelt einen Symlink, der auf ein Verzeichnis zeigt, als normale Datei. Ohne -n wird ln -sf neuesziel symlinkAufVerzeichnis den Link innerhalb des Verzeichnisses anlegen, was selten gewollt ist.
-r, --relative Erzeugt bei Symlinks einen relativen Pfad zum Ziel — automatisch korrekt bezogen auf den Linkort. Sehr praktisch für portable Setups.
-v, --verbose Gibt für jede angelegte Verknüpfung eine Zeile aus.
-T, --no-target-directory Behandelt LINKNAME als gewöhnliche Datei, auch wenn dort ein Verzeichnis liegt. Verhindert die „in-Verzeichnis-anlegen”-Semantik.
-t, --target-directory=DIR Legt alle Links in DIR an. Praktisch für Skripte mit xargs oder find.
-b, --backup[=CONTROL] Erstellt eine Sicherung, falls ein Link überschrieben wird (z. B. link~).
-P, --physical Erstellt einen Hardlink direkt zum Symlink-Eintrag, nicht zu seinem Ziel.
-L, --logical Dereferenziert Symlinks im ZIEL — Hardlink zeigt auf das aufgelöste Ziel.
Häufige Praxis-Patterns
Versionierter current-Link
Ein klassisches Deployment-Pattern: jede Release-Version landet in einem eigenen Verzeichnis, ein Symlink current zeigt auf die aktive Version. Ein Rollback ist dann nur ein ln -sfn.
ln -sfn /var/www/releases/v3.4.2 /var/www/current
# später Rollback
ln -sfn /var/www/releases/v3.4.1 /var/www/current-s für Symlink, -f zum Überschreiben des bestehenden current, -n damit der existierende Symlink nicht als Verzeichnis behandelt wird.
Dotfiles aus einem Git-Repo
Statt Konfigurationsdateien zu kopieren, lässt man sie an ihrem Repo-Ort liegen und verlinkt sie ins Home-Verzeichnis.
ln -s ~/dotfiles/.bashrc ~/.bashrc
ln -s ~/dotfiles/.vimrc ~/.vimrc
ln -s ~/dotfiles/.config/nvim ~/.config/nvimVorteile: ein git pull aktualisiert die Konfiguration automatisch, Änderungen lassen sich im Repo committen.
Cross-Repo-Sharing
Wenn mehrere Projekte dieselbe Library-Datei verwenden sollen, kann ein Symlink Dopplung vermeiden — vorausgesetzt, alle liegen auf demselben Filesystem (für Hardlinks) oder zumindest erreichbar (für Symlinks).
update-alternatives
Auf Debian/Ubuntu ist update-alternatives ein systemweiter Symlink-Manager: /usr/bin/editor ist ein Symlink auf einen weiteren Symlink in /etc/alternatives/editor, der wiederum auf den tatsächlich installierten Editor zeigt. So lassen sich Default-Programme zentral umschalten.
Webserver-Document-Roots
Nginx- und Apache-Konfigurationen verwenden Symlinks, um aktive von verfügbaren Sites zu trennen — /etc/nginx/sites-enabled/example ist meist ein Symlink auf /etc/nginx/sites-available/example.
Symlinks finden und prüfen
| Befehl | Zweck |
|---|---|
ls -l | Zeigt Symlinks mit -> und Ziel |
ls -li | Zusätzlich Inode — Hardlinks erkennen |
find PFAD -type l | Listet alle Symlinks unter PFAD |
find -L PFAD -type l | Listet nur kaputte Symlinks (folgt Links, übrig bleibt nur Defektes) |
readlink LINK | Gibt den rohen Pfad-Inhalt des Symlinks aus |
readlink -f LINK | Löst rekursiv bis zum echten Ziel auf (auch bei Symlink-Ketten) |
realpath LINK | Wie readlink -f, kanonischer Pfad |
stat LINK | Detail-Ansicht: Typ, Inode, Link-Counter |
find -L ~ -type l 2>/dev/nullfind -L folgt allen Symlinks, scheitert aber an kaputten — und genau diese werden noch als -type l gemeldet. Praktischer Trick zum Auffinden verwaister Verknüpfungen.
Häufige Stolperfallen
Relative Symlinks sind relativ zum Link, nicht zum Working Directory
ln -s docs/config.yaml backup/cfg legt einen Link an, dessen Inhalt wörtlich docs/config.yaml ist. Beim Zugriff sucht der Kernel relativ zu backup/ — also nach backup/docs/config.yaml. Wenn du das nicht willst, nutze einen absoluten Pfad oder ln -r, das den korrekten relativen Pfad automatisch konstruiert.
Hardlinks scheitern still über Filesystem-Grenzen
Ein Hardlink kann den Inode-Bereich seines Filesystems nicht verlassen. ln /home/user/file /mnt/usb/file liefert Invalid cross-device link. In Skripten die Fehlermeldung ernst nehmen — oder gleich auf ln -s ausweichen, der Symlink hat diese Einschränkung nicht.
Hardlinks auf Verzeichnisse sind dem Kernel vorbehalten
Nur die automatisch gepflegten Einträge . und .. sind Hardlinks auf Verzeichnisse. Userspace-Tools dürfen sie nicht erzeugen, weil sie Schleifen im Baum erlauben würden — ein find oder tar würde endlos laufen. Wenn du ein Verzeichnis verlinken willst, brauchst du zwingend einen Symlink.
mv über Filesystem-Grenzen trennt Hardlinks
Wird eine Datei mit mv auf ein anderes Filesystem verschoben, ist das in Wahrheit Kopie + Löschen. Das Ergebnis hat einen neuen Inode — die ursprünglichen Hardlink-Geschwister auf dem alten Filesystem zeigen jetzt auf eine eigenständige Datei. Innerhalb desselben Filesystems ändert mv nur den Verzeichnis-Eintrag, der Inode bleibt erhalten und alle Hardlinks bleiben verknüpft.
rsync und Symlinks — drei Modi merken
Ohne Optionen kopiert rsync Symlinks nicht. Mit -l werden sie als Symlinks übertragen, mit -L aufgelöst und als Datei kopiert (das Ziel wandert mit). --copy-unsafe-links ist ein Mittelweg: Symlinks innerhalb des Quellbaums bleiben Symlinks, solche, die nach außen zeigen, werden aufgelöst.
Symlink-Loops fängt der Kernel mit ELOOP ab
ln -s a b; ln -s b a baut eine zyklische Verkettung. Der Kernel verfolgt Symlinks beim Auflösen nur bis zu einer festen Tiefe (typisch 40), danach wird der Aufruf mit ELOOP — Too many levels of symbolic links abgebrochen. Programme sehen einen klaren Fehler, das System hängt nicht — aber der Link bleibt unbenutzbar.
SUID auf Symlinks ist wirkungslos
Setzt jemand chmod u+s auf einen Symlink, wird das Bit ignoriert: bei der Berechtigungsprüfung zählt der Inode des Ziels, nicht des Links. Symlinks haben deshalb fast immer die Anzeige lrwxrwxrwx — die Rechte sind ohne Bedeutung, geprüft wird am Ziel.
cp kopiert Symlinks standardmäßig als Ziel-Inhalt
cp link.lnk neu.lnk legt keinen Symlink an, sondern kopiert die Datei, auf die der Symlink zeigt. Willst du den Link selbst kopieren, brauchst du cp -d oder cp -P (no-dereference) oder cp -a (archive). Bei rekursiven Verzeichnis-Kopien ist das besonders heikel — siehe den cp-Artikel.
Weiterführende Ressourcen
Externe Quellen
- ln(1) – Manpage (man7.org) — Vollständige Optionen
- GNU Coreutils: ln invocation — Ausführliche Dokumentation
- readlink(1) – Manpage — Symlinks rückwärts auflösen
- realpath(1) – Manpage — Kanonische Pfade berechnen
- Arch Wiki: Symbolic link — Praxisnahe Tipps und Patterns
Verwandte Artikel
- cp – Dateien kopieren — Verhalten bei Symlinks (
-d,-P,-a) - mv – Dateien verschieben — Hardlink-Effekte über Filesystem-Grenzen
- find – Dateien suchen — Symlinks aufspüren mit
-type lund-L - Linux Berechtigungen — Warum Symlinks
lrwxrwxrwxzeigen - Linux Dateisystem — Inodes, FHS und Filesystem-Grenzen