/home — Heimverzeichnisse

Was ist /home?

Der FHS-Standard (3.0, Kapitel 3.10) definiert /home als den zentralen Sammelpfad für Benutzer-Heimverzeichnisse. Pro regulärem User gibt es ein Unterverzeichnis, das diesem alleinig gehört und in dem er beliebig schreiben darf — alles, was zu seiner Person gehört, lebt dort.

Was du in einem Home-Verzeichnis typisch findest:

Die Größe eines Home-Verzeichnisses variiert stark — auf Servern oft nur wenige MB (vor allem Konfiguration), auf Desktop-Systemen mit Browser-Caches, Steam-Library oder Projektordnern leicht hunderte GB.

# Top-Level-Übersicht inkl. versteckter Dateien
ls -la ~

# Größte Unterordner (Cache und Daten ausgeblendet ist sinnvoll)
du -sh ~/* 2>/dev/null | sort -hr | head -10

# Auch Dotfiles berücksichtigen
du -sh ~/.* 2>/dev/null | sort -hr | head -10

Berechtigungen und Zugriff

Standardmäßig hat ein Home-Verzeichnis die Berechtigung 0750 oder 0755, mit Owner und Group auf den Nutzer und seine Primärgruppe gesetzt. useradd -m legt das Verzeichnis automatisch mit den richtigen Rechten an, indem es den Inhalt aus /etc/skel/ kopiert.

Die Default-Berechtigung wird durch zwei Faktoren bestimmt:

1. HOME_MODE in /etc/login.defs (z. B. HOME_MODE 0700 oder 0750).
2. Die umask zum Zeitpunkt der User-Anlage.

# Eigene Berechtigung anschauen
ls -ld ~
# drwxr-x--- 24 michael michael 4096 ... /home/michael

# Auf privat (nur ich) umstellen
chmod 700 ~

# Default für neue Nutzer: HOME_MODE in /etc/login.defs setzen
sudo grep HOME_MODE /etc/login.defs
# HOME_MODE 0750

Sensibel und gesondert geschützt: das .ssh-Verzeichnis. SSH verweigert die Anmeldung, wenn die Berechtigungen zu offen sind:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_*           # private Schlüssel
chmod 644 ~/.ssh/id_*.pub        # public Schlüssel
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/known_hosts
chmod 644 ~/.ssh/config

XDG Base Directory Specification

Historisch lag App-Konfiguration als Wildwuchs aus Dotfiles direkt im Home-Verzeichnis (~/.bashrc, ~/.vimrc, ~/.firefox-config, ~/.skype-data). Das wurde unhandlich — deshalb hat die Free Desktop Foundation die XDG Base Directory Specification definiert, an die sich heute die meisten Linux-Anwendungen halten.

XDG legt vier Standard-Pfade fest:

Anwendungen, die XDG sauber unterstützen, lesen ihre Konfiguration aus ~/.config/<appname>/. Beispiele:

• ~/.config/git/config — git-Konfiguration (alternativ zu ~/.gitconfig)
• ~/.config/nvim/init.vim — neovim
• ~/.config/htop/htoprc — htop
• ~/.config/systemd/user/ — User-Services in systemd

Vorteile: gemeinsamer Backup-Pfad (~/.config/), klare Trennung zwischen Cache (entfernbar) und State (wichtig), und konsistente Über-Steuerung via Environment-Variablen.

# Aktuelle XDG-Werte anzeigen
echo "$XDG_CONFIG_HOME"
# leer = Default ~/.config

# Eigene App-Daten beim Sichern fokussieren
tar czf homeconfig.tar.gz \
    -C ~ .config .local/share \
    --exclude='.cache' \
    --exclude='.local/share/Trash'

Dotfiles und Versionskontrolle

Die persönliche Konfiguration lebt in Dotfiles (.bashrc, .vimrc, .gitconfig, .ssh/config, …). Sie machen ein Linux-System produktiv — und wandern ständig zwischen Maschinen mit. Deshalb hat sich das Pattern etabliert, sie in einem Git-Repo zu verwalten.

Drei verbreitete Ansätze:

Das Bare-Repo-Pattern ist besonders elegant, weil es ohne Symlinks auskommt:

# Initial-Setup
git init --bare $HOME/.dotfiles
alias dotfiles='/usr/bin/git --git-dir=$HOME/.dotfiles --work-tree=$HOME'
dotfiles config --local status.showUntrackedFiles no

# Datei tracken und committen
dotfiles add .bashrc .gitconfig .config/nvim/init.vim
dotfiles commit -m "initial dotfiles"
dotfiles remote add origin git@github.com:user/dotfiles.git
dotfiles push -u origin main

# Auf neuer Maschine einspielen
git clone --bare git@github.com:user/dotfiles.git $HOME/.dotfiles
alias dotfiles='/usr/bin/git --git-dir=$HOME/.dotfiles --work-tree=$HOME'
dotfiles checkout

Eigene Partition für /home

Eine separate /home-Partition (oder LVM-Volume) ist eine der häufigsten Layout-Entscheidungen bei Linux-Installationen — und meist die richtige.

Vorteile:

• System-Reinstallation ohne Datenverlust. Beim nächsten Distribution-Wechsel oder Major-Upgrade kannst du / neu aufsetzen, /home bleibt unangetastet.
• Quotas pro User möglich. Mit quota oder Filesystem-Features (Btrfs, XFS) lassen sich pro User Speicher-Limits setzen.
• Unterschiedliche Filesystem-Optionen. / mit konservativen Defaults, /home mit noexec (Sicherheit), nodev, nosuid.
• Encryption granular. Nur das User-Verzeichnis verschlüsseln, ohne das ganze System dem LUKS-Key auszusetzen (LUKS auf dem /home-Volume).

Trade-off: bei zu kleiner /home-Partition läuft sie früher voll als das gesamte System. LVM löst das, weil sich die Volume-Größe online erweitern lässt.

# Hat /home eine eigene Mountpoint?
df -h /home
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/nvme0n1p3  500G   80G  395G  17% /home

# In der fstab nachschauen, was beim Boot gemountet wird
grep '/home' /etc/fstab

# Mount-Optionen prüfen (z. B. nodev,nosuid,noexec wären restriktiv)
mount | grep '/home'

Backup und Verschlüsselung

/home ist der wichtigste Backup-Pfad auf einem Endbenutzer-System. Die Strategie sollte zwei Aspekte abdecken:

Backup-Ziele:

• Eigene Daten: Dokumente, Bilder, Videos, Code-Projekte, Mails, Konfiguration.
• Verzichtbar (excluden): Caches (.cache/, .mozilla/.../Cache/), npm-Module (node_modules/), Build-Output, Trash, virtuelle Maschinen-Images, Steam-Bibliothek (re-installierbar), Snapshots vom Backup-Tool selbst.

rsync -aHAX --delete \
    --exclude='.cache' \
    --exclude='.local/share/Trash' \
    --exclude='node_modules' \
    --exclude='.mozilla/firefox/*/Cache*' \
    --exclude='.config/google-chrome/*/Cache*' \
    --exclude='*.iso' \
    ~/ /mnt/backup/home-michael/

Bessere Tools für dauerhaftes, dedupliziertes Backup: restic, borgbackup, kopia. Alle drei können /home performant und mit Verschlüsselung gegen externe Targets (S3, Backblaze, lokale Disks) sichern.

Verschlüsselung:

Auf modernen Distributionen ist die übliche Wahl vollständige Disk-Verschlüsselung mit LUKS — der gesamte Storage (also auch /home) wird beim Boot entschlüsselt. Alternativ:

• Per-User-Encryption mit fscrypt (Ext4, F2FS): jeder User hat seinen eigenen Schlüssel, andere können seine Dateien nicht mal als Bytes lesen.
• eCryptfs (deprecated) — historisch von Ubuntu für „Home-Encryption per User" genutzt, heute nicht mehr empfohlen.
• systemd-homed — modernerer Ansatz: das Home-Verzeichnis ist ein verschlüsseltes LUKS-Image, das beim Login eingehängt wird. Erfordert systemd ≥ 245 und Distributionen-Support.

Abgrenzung: /root, Service-Accounts und mehrere /home

/home ist nicht der Pfad für root oder System-Service-User:

Der Grund für /root außerhalb von /home: bei einer defekten oder nicht mountbaren /home-Partition muss root sich trotzdem einloggen können, um zu reparieren. Wäre /root unter /home, wäre genau das nicht möglich.

In großen Umgebungen mit vielen Nutzern wird /home oft per NFS oder anderen Netzwerk-Filesystemen gemountet — der Home-Inhalt eines Nutzers folgt ihm dann auf jede Maschine im Netzwerk. Das ist der klassische Unix-Workgroup-Setup, in modernen Cloud-Umgebungen seltener geworden.

Weiterführende Ressourcen

Externe Quellen

• Filesystem Hierarchy Standard 3.0 — /home
• XDG Base Directory Specification
• systemd-homed Documentation
• restic — Backup Tool
• Linux man-pages: hier(7) — Verzeichnisstruktur

Verwandte Artikel

• Verzeichnisstruktur — Übersicht
• /root — Heimat des Superusers
• /etc — Systemkonfiguration
• /var — Variable Daten
• Berechtigungen unter Linux — chmod, chown, SUID
• Dotfiles mit Git verwalten