Kap. 03 · Inodes & Links · Lernwerkstatt

Inhalt dieses Kapitels

3.1Was ist eine Datei wirklich? Das Inode-Konzept
3.2Hard-Links — der zweite Name für dieselbe Datei
3.3Soft-Links (Symlinks) — der Wegweiser
3.4Wann Hard, wann Soft? Vergleich
3.6Typische Anfänger-Fehler
🎯Kontrollfragen zum Kapitel

3.1

Was ist eine Datei wirklich? Das Inode-Konzept

Pflicht

Die Bibliotheks-Analogie: In einer Bibliothek gibt es zwei Sachen:

Das Buch selbst (mit dem Inhalt) — steht irgendwo im Regal
Der Katalogzettel mit dem Titel „Der Herr der Ringe", der dir sagt, wo das Buch steht

In Linux ist es genauso:

Der Dateiinhalt liegt irgendwo auf der Festplatte und hat eine eindeutige Nummer — den Inode
Der Dateiname ist nur ein Zettel, der zur Inode-Nummer zeigt

Eine Datei kann mehrere Zettel haben, die alle aufs selbe Buch zeigen. Das sind Hard-Links.

Dateiname Inode-Nr. Datenblöcke (Etikett) (Eintrag) (echte Daten) bericht.txt → 1234567 → "Quartalsbericht Q1 Umsatz: 4,2 Mio € Kosten: 2,1 Mio €..." ↑ ↑ ↑ was du siehst die ID, das, was wirklich und änderst worüber Linux Speicherplatz die Datei kennt belegt

Inodes anzeigen

bash

# Inode-Nummer einer Datei anzeigen
ls -i bericht.txt
# → 1234567 bericht.txt

# Long-Listing MIT Inodes
ls -li
# → 1234567 -rw-r--r-- 1 admin admin 245 Mai 26 14:22 bericht.txt

# Inode-Info im Detail
stat bericht.txt

📌

Was speichert ein Inode?

Ein Inode enthält alles über eine Datei außer dem Namen:

Dateigröße in Bytes
Eigentümer (User-ID, Gruppen-ID)
Berechtigungen (kommt in Kapitel 04!)
Zeitstempel (erstellt, geändert, zuletzt zugegriffen)
Datentyp (normale Datei, Verzeichnis, Gerätedatei, Link …)
Pointer zu den echten Datenblöcken auf der Festplatte

Der Dateiname steht nicht im Inode — der lebt im Verzeichnis als Verweis auf die Inode-Nummer.

⚙️

Was passiert bei rm?

rm datei.txt löscht nicht die Daten von der Festplatte. Es entfernt nur den Eintrag im Verzeichnis — also den Zettel, der zur Inode-Nummer zeigt. Wenn das der letzte Verweis war, gibt Linux die Inode und die Datenblöcke frei. Bis dahin liegen die Daten weiter dort, nur unverlinkt. Deswegen können Forensik-Tools gelöschte Dateien manchmal wiederherstellen.

🛡️

Wozu brauchst du das Inode-Konzept im Admin-Alltag?

Speicher-Debugging: Wenn df sagt „Festplatte voll" aber du sagt „nur 30 % belegt" → es sind die Inodes voll (Millionen Mini-Dateien, oft in /var/spool/ oder Mail-Queues). df -i zeigt es.
Hardlinks verstehen: Backup-Tools wie rsync --link-dest machen platzsparende inkrementelle Backups über Hardlinks.
Identische Dateien finden: Zwei Dateien haben dieselbe Inode-Nummer? Dann sind sie derselbe Inhalt, kein Duplikat.

▶ Tiefer einsteigen: Inode-Geschichte und -Limits

Inodes wurden 1969 in Unix eingeführt (Ken Thompson)
Bei der Formatierung eines Dateisystems wird eine feste Anzahl Inodes angelegt
Auf ext4 wird per Default 1 Inode pro 16 KB Speicher erzeugt
Ein Mail-Server mit Millionen kleiner Mails kann früher Inodes als Platz verbrauchen!
Modernere Dateisysteme (btrfs, xfs) erzeugen Inodes dynamisch

3.2

Hard-Links — der zweite Name für dieselbe Datei

Pflicht

Ein Hard-Link ist ein weiterer Dateiname, der auf dieselbe Inode zeigt. Beide Namen sind gleichwertig — keiner ist „das Original". Die Datei existiert, solange mindestens ein Hard-Link auf die Inode zeigt.

Hard-Links in Aktion

bash

# Hard-Link erstellen
ln original.txt zweitname.txt

# Beide haben dieselbe Inode-Nummer!
ls -li original.txt zweitname.txt
# → 1234567 -rw-r--r-- 2 admin admin ... original.txt
# → 1234567 -rw-r--r-- 2 admin admin ... zweitname.txt
#   ^^^^^^^                ^
#   gleich!                Link-Count: 2 Verweise auf diese Inode

# Datei ändern über einen Namen — sichtbar über beide
echo "neuer Inhalt" >> original.txt
cat zweitname.txt   # → enthält den neuen Inhalt!

# Original löschen — Datei ist NICHT weg
rm original.txt
cat zweitname.txt   # → funktioniert weiter, Inhalt da

📌

Der Link-Count in ls -l

Die Zahl direkt nach den Berechtigungen (-rw-r--r--) in ls -l ist der Link-Count — wie viele Dateinamen auf diese Inode zeigen. Bei normalen Dateien ist das 1. Wer ln macht, sieht plötzlich 2. Bei Verzeichnissen ist die Zahl höher, weil . und .. mitzählen.

Einschränkungen von Hard-Links

❌ Kein Hard-Link auf Verzeichnisse (würde Endlos-Schleifen erzeugen)
❌ Kein Hard-Link über Dateisystem-Grenzen (Inode-Nummern sind nur innerhalb eines Dateisystems eindeutig)
❌ Nicht über Netzwerk-Mounts (NFS, Samba)

🛡️

Wozu brauchst du Hard-Links?

Inkrementelle Backups: rsync --link-dest legt täglich einen Snapshot an, der unveränderte Dateien als Hard-Links zum Vortag speichert. 30 Backups → fast kein Platzverbrauch.
Dateiversionen ohne Speicher-Verschwendung: Mehrere Pfade zum selben Inhalt im Dateisystem.
Schutz vor versehentlichem Löschen: Solange ein Hard-Link existiert, sind die Daten da. Wer paranoid ist, hardlinkt wichtige Dateien.

▶ Mehr Use Cases — Hard-Links in der Praxis

Build-Systeme: Mehrere Build-Pfade zum selben Source-File ohne Kopie
Mail-Spool-Optimierung: Mailing-Listen, bei denen 100 Empfänger dieselbe Mail bekommen, werden als Hardlinks gespeichert (Sendmail/Postfix)
Time Machine (macOS): Apples Backup-System nutzt Hardlinks für Snapshots — ist eine Linux-Technik
Container-Images: Docker-Layer teilen Dateien über Hard-Links zwischen Containern

3.3

Soft-Links (Symlinks) — der Wegweiser

Pflicht

Ein Soft-Link (auch Symlink, symbolischer Link) ist eine eigenständige kleine Datei, die einen Pfad zu einer anderen Datei enthält. Wie eine Verknüpfung in Windows oder eine Wegweiser-Tafel im Wald. Wenn das Ziel verschwindet, zeigt der Wegweiser ins Leere → dangling symlink.

Soft-Links in Aktion

bash

# Soft-Link erstellen — Option -s = symbolic
ln -s /var/log/messages aktuelles-log

# Symlink anzeigen
ls -l aktuelles-log
# → lrwxrwxrwx 1 admin admin 18 Mai 26 14:30 aktuelles-log -> /var/log/messages
#   ^                                                       ^^
#   "l" = Symlink                                           Pfeil zeigt aufs Ziel

# Inode-Nummer ist anders als beim Ziel!
ls -li /var/log/messages aktuelles-log
# → 9876543 lrwxrwxrwx ... aktuelles-log -> /var/log/messages
# → 1112223 -rw-r----- ... /var/log/messages
#   ^^^^^^^                ^^^^^^^
#   verschiedene Inodes!

# Über den Symlink lesen — funktioniert
cat aktuelles-log   # zeigt Inhalt von /var/log/messages

# Wenn das Ziel gelöscht wird — Symlink ins Leere
rm /var/log/messages
cat aktuelles-log   # → cat: aktuelles-log: No such file or directory

📌

Wie Symlinks aussehen

Symlinks haben in ls -l immer:

l als erstes Zeichen der Berechtigung (statt - für Datei, d für Dir)
-> in der Ausgabe, gefolgt vom Ziel-Pfad
lrwxrwxrwx als Berechtigung — Symlinks haben immer alle Rechte, weil die echten Rechte am Ziel zählen

Absolute vs. relative Pfade in Symlinks

bash

# Absoluter Pfad — gilt überall
ln -s /home/admin/scripts/backup.sh /usr/local/bin/backup

# Relativer Pfad — geht beim Verschieben kaputt!
cd /home/admin
ln -s scripts/backup.sh meine-verknuepfung
# → zeigt auf "scripts/backup.sh" relativ zum Symlink-Standort
# → wenn ich den Symlink woanders hin verschiebe, zeigt er ins Nichts

⚠️

Symlinks und das Verschieben

Wer Symlinks verschiebt, muss aufpassen: Absolute Pfade im Symlink (/var/log/...) funktionieren weiter. Relative Pfade (../logs/foo) sind ans alte Verzeichnis gebunden und kaputt nach dem Verschieben. Im Zweifel: absoluten Pfad verwenden.

🛡️

Wozu brauchst du Soft-Links im Admin-Alltag?

Versionsverwaltung: /opt/app/current → /opt/app/v2.3.1 — beim Update wird nur der Symlink umgehängt, kein Restart nötig
Kurzpfade zu Tools: /usr/local/bin/python → /opt/python3.11/bin/python3.11
Logs in Standard-Pfade: Logfile liegt auf großer Daten-Partition (/data/app/logs), aber Tools erwarten es in /var/log/app/ → Symlink machen

▶ Mehr Use Cases — Symlinks in der Praxis

Dotfiles managen: ~/.bashrc → ~/dotfiles/bashrc — Config in Git, Symlink ins Home
Mehrere PHP-/Node-/Python-Versionen: Standard-Symlink zeigt auf aktive Version, schnell umschaltbar
Library-Pfade: /usr/lib/libssl.so → libssl.so.3.0.2 — Programme suchen den allgemeinen Namen, finden die aktuelle Version
Mount-Tricks: Symlinks im Home zu eingehängten USB-Sticks, externen Festplatten, Netzwerk-Shares
Konfigurationsumschalter: /etc/nginx/sites-enabled/site.conf → ../sites-available/site.conf — Klassiker bei nginx

▶ Tiefer einsteigen: Wo ist der Pfad gespeichert?

Ein Symlink ist eine eigene Datei — sein Inhalt ist der Zielpfad als Text
readlink zeigt nur den Pfad, ohne dem Link zu folgen: readlink aktuelles-log
realpath zeigt den endgültigen absoluten Pfad, auch bei verschachtelten Symlinks
Symlinks können auf Symlinks zeigen → bis zu 40 Ebenen erlaubt, dann gibt's einen Fehler

3.4

Wann Hard, wann Soft? Vergleich

Pflicht

Aspekt	Hard-Link	Soft-Link
Was ist es?	Zweiter Name für dieselbe Inode	Eigene Datei mit Pfad zum Ziel
Inode-Nummer	gleich wie Original	eigene
Befehl	`ln`	`ln -s`
Ziel löschen	egal — Datei lebt weiter	dangling symlink
Über Dateisystem-Grenzen?	❌ Nein	✅ Ja
Auf Verzeichnisse?	❌ Nein	✅ Ja
Auf nicht-existierendes Ziel?	❌ Nein	✅ Ja (dangling)
Speicherverbrauch	praktisch null	ein paar Bytes für den Pfad
In `ls -l` erkennbar?	Nein (sieht aus wie normale Datei)	Ja (`l` + `->`)

💡

Faustregel

Wenn du nicht weißt, was du nimmst → nimm einen Soft-Link. Symlinks sind flexibler (Verzeichnisse, Dateisystem-Grenzen, sichtbar als Symlink) und reichen für 95 % aller Admin-Aufgaben. Hard-Links sind ein Spezialwerkzeug — brauchst du, wenn du sie brauchst, sonst nicht.

🧪 Lab 2.3 Linkstrukturen für die Software-Migration 30 min

📧 Von: Sandra Reuter · Webentwicklung
An: Tim Schulz (du)
Betreff: Hilfe bei Versions-Umstellung — Symlinks bauen

Hi Tim,

wir migrieren unsere interne Web-App nächste Woche von Version 2.3 auf 2.4. Damit unsere ganzen Konfigurationen nicht angepasst werden müssen, möchten wir das übers Symlink-Pattern lösen, das du im Kurs gerade lernst — also /opt/webapp/current zeigt immer auf die aktive Version, und beim Update wird nur der Symlink umgehängt.

Kannst du das bei dir lokal in einem Test-Setup mal durchspielen? Bau dir die Struktur nach (Version 2.3, Version 2.4), übe das Umhängen, und probier auch mal Hard-Links aus, damit du den Unterschied direkt siehst. Markus meinte, das wäre eine super Übung für Lab 2.3.

Falls Zeit ist: probier auch, was passiert, wenn man Symlinks „dangling" laufen lässt — das ist ein klassischer Fehler, den wir vermeiden wollen.

Danke!
— Sandra

Teil A — Inodes erkunden (5 min)

📌

In diesem Teil triffst du auf einen neuen Befehl: stat. Er zeigt dir alle Metadaten einer Datei — also genau das, was im Inode gespeichert ist.

Erstelle ~/link-lab/ und wechsle hinein.
Erstelle eine Datei original.txt mit dem Inhalt „Das ist die Originaldatei" (per echo mit Redirection).
Zeige die Inode-Nummer von original.txt mit ls -li an.
Schau dir die Datei mit stat original.txt an — welche Felder erkennst du wieder (Größe, Zeitstempel, Owner, Berechtigungen)?

bash

mkdir -p ~/link-lab
cd ~/link-lab

echo "Das ist die Originaldatei" > original.txt

ls -li original.txt
# → 1234567 -rw-r--r-- 1 admin admin 26 Mai 26 14:22 original.txt

stat original.txt

Teil B — Hard-Link spielen (8 min)

Erstelle einen Hard-Link auf original.txt namens hardlink.txt.
Vergleiche die Inode-Nummern beider Dateien mit ls -li. Was fällt auf?
Schau dir den Link-Count an — auf welche Zahl ist er gestiegen?
Hänge eine Zeile an den Inhalt über hardlink.txt an (echo "Änderung" >> hardlink.txt). Schau original.txt mit cat an — ist die Änderung sichtbar?
Lösche original.txt. Versuch cat hardlink.txt — funktioniert das? Warum?

bash

ln original.txt hardlink.txt

ls -li
# Beide haben dieselbe Inode-Nummer.
# Link-Count steht jetzt auf 2.

echo "Änderung über hardlink" >> hardlink.txt
cat original.txt   # enthält die Änderung!

rm original.txt
cat hardlink.txt   # funktioniert — Daten leben weiter.
# Grund: solange mindestens ein Hard-Link auf die Inode zeigt,
# bleibt sie samt Datenblöcken erhalten.

Teil C — Soft-Link und Versions-Switch (10 min)

Erstelle eine neue Datei version-2.3.txt mit dem Inhalt „App-Version 2.3".
Erstelle einen Soft-Link namens current auf version-2.3.txt.
Zeige beides mit ls -li — wie unterscheiden sich Inode-Nummern und das erste Zeichen der Berechtigungen?
Lies den Inhalt über cat current.
Simuliere ein Versions-Update: Erstelle version-2.4.txt mit Inhalt „App-Version 2.4". Lösche den alten Symlink mit rm current, erstelle einen neuen current, der jetzt auf version-2.4.txt zeigt. cat current — was siehst du?
Lösche version-2.4.txt. Versuch cat current — was passiert?

bash

echo "App-Version 2.3" > version-2.3.txt

ln -s version-2.3.txt current

ls -li
# version-2.3.txt — eigene Inode, Typ "-" (Datei)
# current         — eigene Inode, Typ "l" (Symlink), zeigt auf version-2.3.txt

cat current   # → "App-Version 2.3"

# Versions-Update simulieren
echo "App-Version 2.4" > version-2.4.txt
rm current
ln -s version-2.4.txt current
cat current   # → "App-Version 2.4"

# Dangling Symlink
rm version-2.4.txt
cat current
# → cat: current: No such file or directory
ls -l current
# → current -> version-2.4.txt (rot/blinkend in modernen Terminals)

Teil D — Härtetest: Über Verzeichnisse (7 min)

Erstelle ~/link-lab/subdir/ und wechsle hinein. Versuche, einen Hard-Link auf hardlink.txt aus dem Elternverzeichnis zu erstellen (ln ../hardlink.txt sub-hardlink.txt). Was passiert?
Versuche dasselbe als Soft-Link (ln -s ../hardlink.txt sub-softlink.txt). Was funktioniert? Schau das Ergebnis mit ls -l an.
Versuche einen Hard-Link auf ein Verzeichnis zu erstellen (zurück ins Home, dann ln ~/link-lab dirlink). Welche Fehlermeldung kommt? Klappt es als Soft-Link (ln -s ~/link-lab dirlink-soft)?

bash

mkdir subdir
cd subdir

# 16) Hard-Link über Ordnergrenzen — funktioniert, weil gleiches Dateisystem
ln ../hardlink.txt sub-hardlink.txt
ls -li sub-hardlink.txt ../hardlink.txt
# Inode identisch!

# 17) Soft-Link auf dieselbe Datei
ln -s ../hardlink.txt sub-softlink.txt
ls -l sub-softlink.txt
# → sub-softlink.txt -> ../hardlink.txt

# 18) Hard-Link auf Verzeichnis
cd ~
ln ~/link-lab dirlink
# → ln: ~/link-lab: hard link not allowed for directory

# Soft-Link auf Verzeichnis funktioniert
ln -s ~/link-lab dirlink-soft
ls -l dirlink-soft

🌟 Bonus für schnelle Teilnehmer

📌

Im Bonus lernst du drei kleine Tools / Optionen kennen, die dir im Symlink-Alltag das Leben einfacher machen. Probier sie aus — und wenn du nicht weiterkommst, ist man ln dein Freund.

Umhängen ohne Lücke: Wenn man einen Symlink umhängen will (alte Version → neue Version), bricht der klassische Weg rm current; ln -s neue_version current für einen kurzen Moment die Verlinkung. Lies mit man ln nach (oder probiere aus), welche drei Optionen in Kombination das in einem Befehl machen. Tipp: Du suchst nach -s, -f und -n.
Anzeigen, wohin ein Symlink zeigt: Es gibt einen kleinen Befehl namens readlink, der den Pfad eines Symlinks anzeigt — ohne dem Link zu folgen. Probiere readlink current und vergleiche mit ls -l current. Was ist der Unterschied in der Ausgabe?
Der wahre Pfad: Probiere auch realpath current. Was zeigt er an? Hinweis: er folgt allen Symlinks und gibt den absoluten Pfad zur echten Datei zurück.

bash

# 19) Umhängen in einer Zeile
echo "App-Version 2.5" > version-2.5.txt
ln -sfn version-2.5.txt current
# -s = symbolic
# -f = force (existierende Datei überschreiben)
# -n = no-dereference (Symlink selbst überschreiben, nicht in
#      das Ziel hineinschreiben)

# 20) readlink — Pfad im Symlink
readlink current
# → version-2.5.txt
# (nur der gespeicherte Pfad, keine Auflösung)

ls -l current
# → current -> version-2.5.txt
# (Auflistung mit Symlink-Info, Pfeil und Symlink-Typ)

# 21) realpath — vollständig aufgelöster Pfad
realpath current
# → /home/admin/link-lab/version-2.5.txt
# (absoluter Pfad zur echten Datei, alle Symlinks aufgelöst)

🎉

Lab 2.3 geschafft?

Du hast jetzt das Versions-Pattern aus dem echten Software-Deployment selbst gebaut. ln -sfn ist der Befehl, mit dem in Production-Servern täglich neue Versionen aktiviert werden — ohne Restart, ohne Anpassung der aufrufenden Dienste. Sandra wird sich freuen!

3.6

Typische Anfänger-Fehler

Vorsicht

❌

Fehler 1 — ln statt ln -s

Wer einen „Shortcut" wollte und Hard-Link bekam. Hard-Link auf Verzeichnis scheitert, Hard-Link über Mounts scheitert. Fast immer ist ln -s gemeint.

❌

Fehler 2 — Symlink ins Nichts (dangling symlink)

Datei verschoben/gelöscht, Symlink zeigt weiter dorthin. Resultat: cat/ls schlagen fehl. Erkennen: ls -l zeigt den Symlink in Rot (in modernen Terminals).

❌

Fehler 3 — Symlink-Datei kopiert statt Inhalt

cp symlink ziel.txt kopiert in modernen cp-Versionen den Inhalt des Ziels (gut!). Mit cp -P kopiert man den Symlink selbst. Verwechslung bei Backups: tar und cp behandeln Symlinks unterschiedlich je nach Option.

❌

Fehler 4 — Relative Symlinks verschoben

ln -s ./scripts/foo.sh wegweiser bricht, sobald man wegweiser woanders hinverschiebt. Absoluter Pfad ist sicherer für Symlinks, die auch beim Bewegen funktionieren sollen.

❌

Fehler 5 — rm auf Symlink zum Verzeichnis

rm symlink-zum-ordner löscht nur den Symlink, das Verzeichnis bleibt. Aber rm -rf symlink-zum-ordner/ (mit Slash!) folgt dem Symlink und löscht den Inhalt des Originals. Klassische Katastrophe.

🎯

Kontrollfragen zum Kapitel

Selbst-Check

Was ist ein Inode? Was steht drin, was nicht?
Wo ist der Dateiname gespeichert, wenn nicht im Inode?
Was passiert technisch bei rm datei.txt?
Welcher Befehl erstellt einen Hard-Link, welcher einen Soft-Link?
Wenn zwei Dateien dieselbe Inode-Nummer haben — was bedeutet das?
Was passiert mit einem Hard-Link, wenn man das Original löscht?
Was passiert mit einem Soft-Link, wenn man das Ziel löscht?
Welche drei großen Einschränkungen haben Hard-Links?
Wie erkennst du einen Symlink in der ls -l-Ausgabe? Nenne zwei Merkmale.
Was bedeutet die Option -n in ln -sfn?

Eine Datenstruktur mit allen Metadaten einer Datei: Größe, Owner, Berechtigungen, Zeitstempel, Typ, Pointer auf Datenblöcke. NICHT im Inode: der Dateiname.
Im Verzeichnis — das Verzeichnis ist im Grunde eine Tabelle: Name → Inode-Nummer.
Der Eintrag im Verzeichnis wird entfernt. Wenn der Link-Count danach 0 ist, wird die Inode freigegeben und die Datenblöcke werden zum Überschreiben freigegeben.
Hard-Link: ln quelle ziel. Soft-Link: ln -s quelle ziel.
Sie sind derselbe Inhalt — zwei Hard-Links auf dieselbe Datei. Keine Kopie, sondern zwei Namen.
Nichts — die Datei bleibt erhalten, solange mindestens ein Hard-Link auf die Inode zeigt. Das gelöschte Original war nur ein Name von vielen.
Der Symlink wird zum dangling symlink — er existiert noch, zeigt aber ins Leere. Zugriffe schlagen fehl.
(a) Keine Hard-Links auf Verzeichnisse, (b) nicht über Dateisystem-Grenzen, (c) nicht über Netzwerk-Mounts.
(a) Erstes Zeichen der Berechtigungen ist l, (b) im Listing erscheint -> ziel.
-n = „no-dereference" — verhindert, dass ln in einen existierenden Ziel-Symlink hineinschreibt. In Kombination mit -f (force) der sichere Weg, einen Symlink umzuhängen.