☚ zurück - Einstiegskurs

In diesem Projekt wird aus einem Raspberry Pi ein zentraler NFS-Backupserver für ein lokales Netzwerk aufgebaut. Ziel ist eine saubere und technisch nachvollziehbare Trennung zwischen einem ausschließlich lesbaren Bereich und einem schreibbaren Datenbereich. Dabei wird bewusst keine Benutzer-Synchronisation zwischen Client und Server eingesetzt. Stattdessen werden alle Schreibzugriffe serverseitig auf einen definierten Service-User abgebildet. Dadurch bleibt die Client-Konfiguration minimal, konsistent und unabhängig von lokalen UID-Strukturen.

Der Server stellt zwei Verzeichnisse bereit:

• /srv/nfs/public → nur lesend (ro)
• /srv/nfs/data → lesend + schreibend (rw, Service-User 2000)

Für das Datenverzeichnis wird ein technischer Service-User mit der UID/GID 2000 eingerichtet. Alle Schreibzugriffe werden mittels all_squash auf diesen Benutzer umgeleitet. Dadurch gehören sämtliche erzeugten Dateien immer demselben Systemkonto – unabhängig davon, welcher Client sie erstellt hat.

Dieses Modell verhindert UID-Konflikte zwischen unterschiedlichen Linux-Systemen im Netzwerk und sorgt für ein eindeutiges Besitzmodell auf dem Server.

Alle schreibenden Zugriffe auf /srv/nfs/data werden serverseitig auf UID/GID 2000 abgebildet (all_squash).

Im Kurs steht der Server bereits zur Verfügung, sodass es primär darum geht, ihn korrekt einzubinden. Wer einen eigenen NFS-Server aufsetzen möchte, findet hier die vollständige Einrichtung.

Einrichtung Server

sudo apt update
sudo apt install -y nfs-kernel-server
 
# Service-User für schreibendes Share
sudo groupadd -g 2000 nfsdata
sudo useradd -u 2000 -g 2000 -M -r nfsdata
 
# Verzeichnisse anlegen
sudo mkdir -p /srv/nfs/public
sudo mkdir -p /srv/nfs/data
 
# Rechte setzen
sudo chown -R root:root /srv/nfs/public
sudo chmod -R 755 /srv/nfs/public
 
sudo chown -R 2000:2000 /srv/nfs/data
sudo chmod -R 2775 /srv/nfs/data
 
 
# ================================
# /etc/exports
# ================================
 
/srv/nfs/public  IP/24(ro,sync,no_subtree_check,root_squash)
/srv/nfs/data    IP/24(rw,sync,no_subtree_check,all_squash,root_squash,anonuid=2000,anongid=2000)
 
 
# anwenden
sudo exportfs -ra
sudo systemctl restart nfs-kernel-server
sudo systemctl enable nfs-kernel-server
 
# prüfen
sudo exportfs -v

Um die Freigaben zu verwenden, wird auf dem Client zunächst das notwendige Paket installiert.

sudo apt install -y nfs-common
showmount -e IP

Der Befehl zeigt an, welche Verzeichnisse der Server exportiert.

Für einen ersten Test werden lokale Mountpunkte angelegt und die Freigaben manuell eingebunden.

sudo mkdir -p /mnt/public
sudo mkdir -p /mnt/data
 
sudo mount -t nfs -o ro IP:/srv/nfs/public /mnt/public
sudo mount -t nfs -o rw,soft,timeo=50,retrans=3 IP:/srv/nfs/data /mnt/data

Das Verzeichnis /mnt/public ist nur lesbar. Im Verzeichnis /mnt/data können Dateien erzeugt werden, die serverseitig immer UID/GID 2000 gehören.

Damit der Client auch dann startet, wenn der Server nicht erreichbar ist, erfolgt die Einbindung per systemd-Automount in der /etc/fstab.

IP:/srv/nfs/public  /mnt/public  nfs  ro,_netdev,noatime,x-systemd.automount,nofail  0  0
IP:/srv/nfs/data    /mnt/data    nfs  rw,_netdev,noatime,x-systemd.automount,x-systemd.device-timeout=10s,x-systemd.idle-timeout=600,soft,timeo=50,retrans=3,nofail  0  0
 
sudo systemctl daemon-reload
sudo mount -a

Der Mount erfolgt nun erst beim ersten Zugriff. Ist der Server nicht erreichbar, blockiert der Bootvorgang nicht.

• /srv/nfs/public → nur lesbar für alle Clients
• /srv/nfs/data → schreibbar, serverseitig UID/GID 2000
• Client bootet auch wenn Server offline ist
• Mount erfolgt erst bei Zugriff (automount)
• Keine UID-Anpassung auf Clients erforderlich

Damit steht ein klar strukturiertes, wartungsarmes Backup-System auf Basis eines Raspberry Pi zur Verfügung.