NAS selber bauen 2026: Die vollständige Anleitung für dein Heimnetz-NAS

🔄 Zuletzt aktualisiert: 11. Juli 2026

Ein selbst gebauter NAS auf Intel N100-Basis mit vier CMR-Festplatten, 2,5GbE-Switch und USV — das Fundament für ein zuverlässiges Heimnetz-NAS 2026.

Wer einen zentralen Datenspeicher mit vollem Zugriff auf Hardware, Betriebssystem und Daten braucht, kommt 2026 an einem selbst gebauten NAS auf Intel N100-Basis kaum vorbei. ZFS-Redundanz, Docker-Container und 2,5GbE-Netzwerk lassen sich damit für unter 400 € realisieren — ohne Cloud-Zwang, ohne Lizenzfallen. Wichtige Einschränkung vorab: Wer 1–4 Festplatten ohne VMs oder Docker betreibt und keine Zeit für Troubleshooting investieren will, ist mit einer gebrauchten Synology DS423+ kaufen oft konkurrenzfähig im Gesamtpreis.

Und noch etwas, bevor wir anfangen: RAID ist kein Backup. Wir planen Redundanz und Datensicherung von Anfang an parallel — dazu mehr im Abschnitt zur 3-2-1-Strategie.

---

Warum ein selbst gebautes NAS 2026 Sinn ergibt — und wann nicht

Ein NAS selber bauen kostet 2026 bei 4+ Festplatten-Slots deutlich weniger als eine vergleichbare Fertiglösung — und liefert mehr Flexibilität. Aus einem Intel-N100-Mini-PC, vier NAS-Festplatten und kostenloser Software entsteht ein zentraler Datenspeicher mit redundantem ZFS-Pool, SMB-Freigaben, Nextcloud, Jellyfin und sauberer 3-2-1-Backup-Strategie.

Typischer Anfängerfehler: Selbstbau ist immer günstiger als Synology oder QNAP. Bei kleinen Setups (1–4 Festplatten, reine NAS-Funktion) stimmt das nicht. Ein Synology DS224+ kostet ~300 €. Ein vergleichbarer Selbstbau mit Gehäuse, Board, CPU, RAM, HBA und USV-Kompatibilität landet schnell bei 350–500 €. Dazu kommen Stromkosten: Synology ARM-Prozessoren verbrauchen 15–20 W, ein schlecht optimierter x86-Selbstbau 40–80 W — bei 24/7-Betrieb über 5 Jahre macht das 200–400 € Unterschied. Selbstbau lohnt sich klar ab 4+ Bays, bei Bedarf nach VMs/Docker oder GPU-Transcoding.

Schwierigkeitsgrad: mittel. Grundlegende Linux-Kenntnisse und Kommandozeilen-Erfahrung werden vorausgesetzt.

Zeitplanung: Plane realistisch 2–3 Tage für einen vollständig konfigurierten Build. SMR-Platten-Erkennung und Rückgabe kosten 1–3 Tage Versandzeit. BIOS-Updates bei N100-Boards dauern 30–60 Minuten. Der erste ZFS-Scrub bei 4× 4 TB läuft 3–5 Stunden.

Praxis-Hinweis N100-Boards: Auf Minisforum-N100-Boards mit BIOS-Versionen vor 2024-Q2 zeigen sich unter Ubuntu 22.04 und Debian 12 sporadische SATA-Link-Resets (dmesg | grep "ata[0-9]: SATA link down"), die ZFS als Disk-Fehler interpretiert. Ein BIOS-Update löst das vollständig; ohne Update hilft echo 1 > /sys/module/libata/parameters/noacpi.

---

DIY vs. Fertig-NAS: Direktvergleich 2026

Wer noch unentschlossen ist, findet hier den direkten Vergleich zwischen einem N100-Selbstbau und aktuellen Fertig-NAS-Modellen — ohne Festplatten gerechnet.

Fazit: Fertig-NAS punkten bei Stromverbrauch und Plug-and-play-Erlebnis. Der Selbstbau gewinnt bei Bays, ZFS-Flexibilität und Docker ohne Einschränkungen. AMD-CPUs (z. B. Ryzen 5600G) sind eine Alternative für ECC-Support — aber ohne Intel Quick Sync fehlt Hardware-Transcoding für H.265/HEVC in Jellyfin/Plex, was ein häufiger Fehler bei der CPU-Wahl ist.

---

Welches NAS-Betriebssystem passt: TrueNAS Scale, TrueNAS Core, Unraid oder OpenMediaVault

Die Wahl des Betriebssystems entscheidet über alles Weitere — ein späterer Wechsel kann im schlimmsten Fall Daten kosten.

Entscheidungsbaum:

• Reine NAS-Funktion ohne Docker → TrueNAS Core
• Docker + Jellyfin/Plex-Transcoding mit GPU → TrueNAS Scale
• Unterschiedliche Festplattengrößen mischen → Unraid
• Einfacher Einstieg mit GUI, Linux-nah → OpenMediaVault 7
• Nextcloud auf TrueNAS Scale → Docker Compose (nicht die k3s-App)

Kritischer Hinweis TrueNAS Scale vs. Core: Ein Pool, der unter Scale mit neueren OpenZFS-Feature-Flags erstellt wurde, kann unter Core nicht importiert werden. Prüfe vor einer Migration: zpool get all | grep feature. TrueNAS Scale 24.x hat mit der Einführung von „Apps“ (k3s) die Docker-Verwaltung grundlegend geändert — wer einfaches Docker Compose bevorzugt, ist mit OMV 7.x + Compose-Plugin besser bedient.

Diese Anleitung verwendet OpenMediaVault 7 auf einem Intel N100-Board als Basis — niedrigste Einstiegshürde, Docker Compose nativ. Die ZFS-Befehle gelten identisch für TrueNAS Scale.

Die Architektur des NAS-Eigenbaus: Intel N100 kaufen als Basis, ZFS RAIDZ1/RAIDZ2 für Redundanz, Docker-Container für Dienste und eine 3-2-1-Backup-Strategie für Datensicherheit.

---

Hardware-Auswahl für den NAS-Eigenbau 2026: Intel N100, HBA und Festplatten

Eine SMR-Platte, zu wenig RAM oder ein fehlender HBA bremst das Projekt wochenlang aus. Hier die vollständige Materialliste.

Hardware-Checkliste

• [ ] CPU/Plattform: Intel N100 Mini-PC oder N100-Mainboard (z. B. ASRock N100DC-ITX) — 6 W TDP, ausreichend für ZFS + 2–3 Docker-Container. Alternativ AMD Ryzen 5600G für ECC-Support (aber kein Quick Sync)
• [ ] RAM: mindestens 16 GB DDR4/DDR5. ECC nur bei Boards die es unterstützen — beim N100 meist Non-ECC
• [ ] Boot-Laufwerk: separate SSD/NVMe ab 32 GB — niemals auf den Daten-Pool installieren
• [ ] Datenfestplatten: 2–6× CMR-Platten (WD Red Plus, WD Red Pro, Seagate IronWolf). Keine SMR-Platten (WD Red ohne Suffix, Seagate Barracuda)
• [ ] HBA-Controller (bei >4 Platten): LSI 9207-8i im IT-Mode für direkten Disk-Durchgriff
• [ ] Netzwerk: 2,5GbE-NIC (Intel I226-V empfohlen) + passender Switch
• [ ] Netzteil: be quiet! Pure Power Angebot oder PicoPSU für N100
• [ ] USV dringend empfohlen: ZFS verträgt plötzliche Stromausfälle schlecht

Typischer Anfängerfehler: Ein Raspberry Pi 5 kaufen reicht als vollwertiges NAS mit 4+ Festplatten. Der Raspberry Pi 5 kaufen hat fundamentale Limitierungen: Alle USB-3.0-Ports teilen sich intern einen begrenzten Bus — bei 4 Platten sinkt der Durchsatz pro Platte drastisch. Für 1–2 Platten als Medienserver ist der Pi 5 akzeptabel — für produktive NAS-Workloads ist ein Intel N100 Mini-PC (≈150 €, PCIe, 6–10 W idle) die überlegene Wahl.

RAM-Faustregel für ZFS: Die oft zitierte Regel „1 GB RAM pro TB Speicher“ bezieht sich auf den L2ARC-Cache, nicht auf den Basisbetrieb. Ein RAIDZ2-Pool mit 4× 4 TB läuft problemlos mit 8 GB RAM ohne Dedup. Dedup ist der eigentliche RAM-Fresser (~5 GB RAM pro TB deduplizierter Daten). Für Heimanwender ohne Dedup reichen 8–16 GB; 16 GB empfiehlt sich sobald Docker-Container dazukommen.

NAS-Festplatten-Empfehlung 2026: WD Red Plus (CMR) und Seagate IronWolf sind die Standardempfehlung. SMR-Erkennung: Modellnummern mit EFPX (WD Red Plus) sind CMR, EZRZ (WD Red ohne Suffix) sind SMR. Prüfe die WD-eigene CMR-Liste unter support.westerndigital.com vor dem Kauf.

Software-Checkliste

• [ ] Betriebssystem: TrueNAS Scale 24.x oder OpenMediaVault 7.x
• [ ] smartmontools, iperf3
• [ ] docker + docker compose v2 (ohne Bindestrich — V1 ist End-of-Life)
• [ ] mergerfs + snapraid (nur für die ZFS-Alternative bei gemischten Platten)
• [ ] rsync / rclone für Backup — vor dem ersten produktiven Datentransfer einrichten

Netzwerk-Anforderungen

• [ ] Feste IP per DHCP-Reservation am Router (z. B. 192.168.1.10), zusätzlich statisch im NAS-OS
• [ ] Offene Ports: 445 (SMB), 80/443 (Nextcloud), 8096 (Jellyfin), 9000 (Portainer)
• [ ] MTU 9000 (Jumbo Frames) nur wenn alle Geräte im Pfad es unterstützen — auf Fritz!Box-Heimnetzen nicht möglich

---

Stromverbrauch & Energieeffizienz: N100 vs. Alternativen

Energieeffizienz ist beim 24/7-NAS kein Luxus — sie entscheidet über die Betriebskosten der nächsten 5 Jahre. Hier der direkte Vergleich verschiedener Plattformen:

Konkrete Stromkostenrechnung (24/7, 0,35 €/kWh):

• N100-NAS, Ø 22 W: 22 × 24 × 365 = 192,7 kWh × 0,35 € = ~67 €/Jahr → 5 Jahre ~337 €
• i3-Selbstbau, Ø 50 W: 50 × 24 × 365 = 438 kWh × 0,35 € = ~153 €/Jahr → 5 Jahre ~766 €
• Xeon-Oldie, Ø 70 W: 70 × 24 × 365 = 613 kWh × 0,35 € = ~215 €/Jahr → 5 Jahre ~1.073 €

Stromsparen am N100 — die wichtigsten Maßnahmen:

• C-States im BIOS aktivieren (C6/C7 für CPU-Tiefschlaf)
• ASPM (Active State Power Management) für PCIe aktivieren
• HDD-Spindown nach 20–30 Minuten Inaktivität konfigurieren
• powertop --auto-tune beim Systemstart ausführen

# C-State-Tiefe prüfen
powertop --quiet --time=10 | grep -A6 "Package"

# ASPM-Status prüfen
cat /sys/module/pcie_aspm/parameters/policy
# Gewünschte Ausgabe: default performance [powersave] powersupersave

Wichtig: Auf dem ASRock N100DC-ITX führt C6/C7 unter TrueNAS Scale zu SATA-Port-Timeouts nach ~15 Minuten Inaktivität. Fix: processor.max_cstate=1 als Kernel-Parameter. Unter Ubuntu 22.04 tritt das Problem nicht auf.

---

Die 5 häufigsten Fehler beim NAS-Eigenbau

Diese Fehler kosten am meisten Zeit — und sind alle vermeidbar:

1. SMR-Festplatten im RAID/ZFS verwenden. SMR-Platten (WD Red ohne Suffix, Seagate Barracuda) brechen beim Rebuild auf unter 10 MB/s ein und können den Pool in DEGRADED halten. Immer CMR-Modelle kaufen und Modellnummer vorher prüfen.
2. AMD-CPU ohne Quick Sync für Transcoding wählen. AMD-CPUs haben kein Intel Quick Sync — Hardware-Transcoding für H.265/HEVC in Jellyfin/Plex funktioniert damit nicht. Wer Transcoding braucht, nimmt Intel (N100, i3-12100 oder neuer).
3. ZFS-Pool mit /dev/sdX statt Disk-IDs anlegen. Nach einem Reboot kann sda zu sdc werden — der Pool findet seine Platten nicht mehr. Immer /dev/disk/by-id/ata-... verwenden.
4. RAID als Backup betrachten. RAID schützt nur vor Plattenausfall. Versehentliches Löschen, Ransomware und Feuer treffen alle Platten gleichzeitig. Ohne 3-2-1-Backup sind die Daten nicht sicher.
5. ashift=12 vergessen. Ohne explizites ashift=12 wählt ZFS bei 512e-Platten automatisch ashift=9 — massive Schreib-Amplifikation, nachträglich nicht korrigierbar ohne Pool-Neuanlage.

---

NAS selber bauen Schritt für Schritt: BIOS, ZFS-Pool und SMB-Freigaben einrichten

Jeder Schritt baut auf dem vorherigen auf. Basis: OpenMediaVault 7 auf einem Intel N100-Board mit 16 GB RAM und vier WD Red Plus CMR-Platten. Überspringe keinen Schritt.

Schritt 1: BIOS/UEFI für NAS-Betrieb konfigurieren

Drei Einstellungen müssen stimmen, bevor das OS ins Spiel kommt:

• SATA-Modus auf AHCI (nicht RAID) — sonst kann das OS keine SMART-Werte auslesen
• VT-d / Intel Virtualization Technology for Directed I/O = Enabled — Pflicht für HBA-Passthrough und Proxmox
• Secure Boot deaktivieren — blockiert auf vielen N100-Boards das Laden des ZFS-Kernel-Moduls
• Wake-on-LAN = Enabled im Power-Management

Typischer Anfängerfehler: Viele günstige N100-Mini-PCs liefern BIOS-Versionen, in denen AHCI zwar angezeigt wird, intern aber ein proprietärer RAID-Modus aktiv ist. Symptom: dmesg zeigt AHCI korrekt, aber smartctl liefert „Device open failed“. Lösung: BIOS-Update, danach AHCI explizit neu setzen.

Beweis — AHCI korrekt aktiv:

dmesg | grep -i ahci | head -10

Erwartete Ausgabe:

[    1.882341] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
[    1.883104] scsi host0: ahci
[    1.883288] scsi host1: ahci
[    1.883441] scsi host2: ahci
[    1.883592] scsi host3: ahci

Beweis — VT-d aktiv:

dmesg | grep -i iommu | head -5

Erwartete Ausgabe:

[    0.021438] DMAR: IOMMU enabled
[    0.021441] DMAR: Intel(R) Virtualization Technology for Directed I/O

---

Schritt 2: OpenMediaVault 7 installieren

OMV 7 setzt auf Debian 12 (Bookworm). Installiere zuerst ein minimales Debian auf der Boot-SSD, dann OMV obendrauf.

Debian-Installer-Kurzanleitung:

1. Boot vom USB-Stick (DD-Modus in Rufus — nicht ISO-Modus)
2. Partitionierung: Ausschließlich die Boot-SSD als Ziel — niemals die Datenplatten
3. Software-Auswahl: Nur „SSH server“ und „Standard-Systemwerkzeuge“ — kein Desktop

# OMV installieren
wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash

# Nach Reboot: omv-extras installieren
wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

Web-UI unter http://<NAS-IP> (Standard-Login: admin / openmediavault). Passwort sofort ändern.

USB-Boot-Warnung: Billige USB-Sticks sterben unter dem Schreib-Load von Systemlogs innerhalb von 3–12 Monaten. Konfiguriere log2ram oder nutze das Flash-Memory-Plugin aus OMV-Extras.

Nach Kernel-Updates: apt upgrade (nicht full-upgrade) verwenden. Nach Kernel-Updates mit dkms status prüfen ob das ZFS-Modul kompiliert wurde. Bei Fehler: apt install linux-headers-$(uname -r) && dkms autoinstall.

Beweis — OMV korrekt installiert:

systemctl status openmediavault-engined

Erwartete Ausgabe:

● openmediavault-engined.service - OpenMediaVault Engine Daemon
     Active: active (running) since Sat 2026-01-18 09:14:32 CET; 3min 47s ago

Das Web-Dashboard nach der Erstinstallation zeigt Pool-Status, Systemressourcen und aktive Dienste auf einen Blick.

---

Schritt 3: ZFS-Pool für NAS-Eigenbau anlegen — RAIDZ2 vs. Mirror

Installiere das ZFS-Plugin über OMV-Extras. Der DKMS-Kompiliervorgang dauert auf dem N100 5–15 Minuten ohne Fortschrittsanzeige — prüfe den Fortschritt mit dmesg -w.

RAIDZ2 mit 4 Platten vs. Mirror: Für Heimanwender mit 4 Platten ist 2× Mirror (2+2) oft die bessere Wahl: schnellere Rebuild-Zeiten, bessere Random-Read-Performance. RAIDZ2 mit 4 Platten und 2× Mirror ergeben beide ~50 % Nutzkapazität — Mirror ist performanter für typische NAS-Workloads. Ab OpenZFS 2.2 (verfügbar in OMV 7.x) gibt es RAIDZ-Expansion — der Prozess dauert bei 4× 4 TB mehrere Tage.

Disk-IDs ermitteln — niemals /dev/sdX verwenden:

ls -la /dev/disk/by-id/ | grep -v part | grep ata

zpool create -o ashift=12 -O compression=lz4 -O atime=off storage raidz2 \
  /dev/disk/by-id/ata-WDC_WD40EFPX-68C6CN0_WD-WX52D71KXHSF \
  /dev/disk/by-id/ata-WDC_WD40EFPX-68C6CN0_WD-WX52D71KXHSG \
  /dev/disk/by-id/ata-WDC_WD40EFPX-68C6CN0_WD-WX52D71KXHSH \
  /dev/disk/by-id/ata-WDC_WD40EFPX-68C6CN0_WD-WX52D71KXHSI

Wichtig: ashift=12 erzwingt 4K-Sektoren. Ohne explizites ashift=12 wählt ZFS bei 512e-Platten automatisch ashift=9 — massive Schreib-Amplifikation, nachträglich nicht korrigierbar ohne Pool-Neuanlage.

# Monatlichen Scrub einrichten — Pflicht für ZFS-Datenintegrität
echo "0 2 1 * * root /sbin/zpool scrub storage" > /etc/cron.d/zfs-scrub

# ZFS ARC-Limit auf 4 GiB setzen (bei 16 GB RAM empfohlen)
echo "options zfs zfs_arc_max=4294967296" | sudo tee /etc/modprobe.d/zfs.conf
sudo update-initramfs -u

Beweis — Pool korrekt angelegt:

zpool status -v storage

Erwartete Ausgabe:

  pool: storage
 state: ONLINE
config:
        NAME                                          STATE     READ WRITE CKSUM
        storage                                       ONLINE       0     0     0
          raidz2-0                                    ONLINE       0     0     0
            ata-WDC_WD40EFPX-68C6CN0_WD-WX52D71KXHSF ONLINE      0     0     0
            ata-WDC_WD40EFPX-68C6CN0_WD-WX52D71KXHSG ONLINE      0     0     0
            ata-WDC_WD40EFPX-68C6CN0_WD-WX52D71KXHSH ONLINE      0     0     0
            ata-WDC_WD40EFPX-68C6CN0_WD-WX52D71KXHSI ONLINE      0     0     0
errors: No known data errors

zfs list storage

Erwartete Ausgabe (RAIDZ2 mit 4× 4 TB = ~7,06 TB nutzbar):

NAME      USED  AVAIL     REFER  MOUNTPOINT
storage   756K  7.06T      192K  /storage

zpool status -v zeigt den ONLINE-Status aller Vdevs, Fehlerstatistiken und die Disk-IDs des angelegten RAIDZ2-Pools.

---

Schritt 4: Samba SMB-Freigabe für NAS-Eigenbau einrichten

Erstelle in der Web-UI eine Freigabe auf dem Pool, oder editiere direkt /etc/samba/smb.conf:

[global]
   workgroup = WORKGROUP
   server string = NAS-N100
   server role = standalone server
   map to guest = bad user
   security = user
   server multi channel support = yes
   max protocol = SMB3
   log file = /var/log/samba/log.smbd
   max log size = 1000

[storage]
   path = /storage/shared
   browseable = yes
   writable = yes
   guest ok = no
   valid users = nasuser
   create mask = 0664
   directory mask = 0775

Danach: systemctl restart smbd

Typischer Anfängerfehler — Samba-Benutzer vs. Linux-Benutzer: Samba verwaltet eine eigene Passwort-Datenbank. Ein Linux-Benutzer kann sich nicht per SMB anmelden, bis er mit smbpasswd -a nasuser zur Samba-Datenbank hinzugefügt wurde. Das ist der häufigste Grund für NT_STATUS_WRONG_PASSWORD-Fehler.

Realtek RTL8125B Bug: server multi channel support = yes in Kombination mit Realtek RTL8125B führt nach 10–14 Tagen zu SMB-Session-Verlusten. Fix: ethtool -C eth0 rx-usecs 50. Mit Intel I226-V tritt das Problem nicht auf.

Beweis — Samba korrekt konfiguriert:

testparm -s /etc/samba/smb.conf
# Erwartete Ausgabe: "Loaded services file OK."

ss -tlnp | grep smbd
# Erwartete Ausgabe: LISTEN auf Port 445

---

Schritt 5: Docker und Portainer auf dem NAS-Eigenbau installieren

Aktiviere im OMV-Compose-Plugin Docker. Lege /etc/docker/daemon.json an:

{
  "data-root": "/storage/docker",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "storage-driver": "overlay2"
}

Docker data-root auf ZFS-Dataset: Das Dataset muss mit xattr=sa und dnodesize=auto konfiguriert sein — sonst schlägt overlay2 mit „overlayfs: upper fs does not support RENAME_WHITEOUT“ fehl:

zfs create -o xattr=sa -o dnodesize=auto storage/docker

Neustart: systemctl restart docker

Beweis — Docker nutzt den ZFS-Pool:

docker info | grep -E 'Docker Root Dir|Storage Driver'

Erwartete Ausgabe:

 Docker Root Dir: /storage/docker
 Storage Driver: overlay2

---

Schritt 6: Jellyfin oder Plex als Medienserver auf dem NAS einrichten

Plex vs. Jellyfin für NAS-Eigenbau:

Jellyfin via Docker Compose:

version: "3.8"
services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
    volumes:
      - /storage/jellyfin/config:/config
      - /storage/media:/media:ro
    ports:
      - "8096:8096"
    devices:
      - /dev/dri:/dev/dri  # Intel Quick Sync für Hardware-Transcoding
    restart: unless-stopped

docker compose up -d

Jellyfin ist danach unter http://<NAS-IP>:8096 erreichbar.

Intel N100 Quick Sync unter Debian 12: Die GuC/HuC-Firmware wird nicht automatisch geladen. Lösung: intel-media-va-driver-non-free aus dem non-free-Repo installieren und echo 'options i915 enable_guc=3' > /etc/modprobe.d/i915.conf && update-initramfs -u ausführen. Prüfe mit vainfo ob H.265/HEVC erkannt wird.

Verifikation — Hardware-Transcoding:

docker exec jellyfin vainfo 2>/dev/null | grep -i "VAProfile"
# Erwartete Ausgabe: VAProfileH264Main, VAProfileHEVCMain, VAProfileAV1Profile0

curl -o /dev/null -s -w "%{http_code}\n" http://localhost:8096/web/
# Erwartete Ausgabe: 200

Jellyfin unter TrueNAS Scale (App-Weg): Auf TrueNAS Scale installierst du Jellyfin über den App-Katalog (Apps → Discover Apps → Jellyfin). Wichtig: Unter GPU Resources „Intel GPU“ auf 1 setzen. Verifikation: sudo k3s kubectl get pods -n ix-jellyfin — Status muss 1/1 READY zeigen.

*arr-Stack (Sonarr/Radarr) als Ergänzung: Wer Medien automatisiert verwalten will, ergänzt den Stack um Sonarr (Serien) und Radarr (Filme). Beide laufen als Docker-Container und integrieren sich direkt mit Jellyfin:

  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
    volumes:
      - /storage/sonarr/config:/config
      - /storage/media/tv:/tv
    ports:
      - "8989:8989"
    restart: unless-stopped

---

Schritt 7: Nextcloud auf TrueNAS Scale oder OMV installieren

Nextcloud via Docker Compose auf OMV:

version: "3.8"
services:
  nextcloud-db:
    image: mariadb:11
    container_name: nextcloud-db
    environment:
      - MYSQL_ROOT_PASSWORD=sicherespasswort
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=ncpasswort
    volumes:
      - /storage/nextcloud/db:/var/lib/mysql
    restart: unless-stopped

  nextcloud:
    image: nextcloud:29
    container_name: nextcloud
    environment:
      - MYSQL_HOST=nextcloud-db
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=ncpasswort
    volumes:
      - /storage/nextcloud/data:/var/www/html
    ports:
      - "8080:80"
    depends_on:
      - nextcloud-db
    restart: unless-stopped

# Ownership korrekt setzen
chown -R 33:33 /storage/nextcloud/data/
docker compose up -d

Typischer Anfängerfehler — PUID/PGID-Mismatch: Nextcloud (UID 33) hat keine Schreibrechte wenn PUID/PGID nicht mit der Dateisystem-UID übereinstimmt. Symptom: 403/Permission denied bei Uploads.

Trusted Domains und HTTPS einrichten:

docker exec -u www-data nextcloud php occ config:system:set trusted_domains 1 --value=192.168.178.50
docker exec -u www-data nextcloud php occ config:system:set overwriteprotocol --value=https

Für HTTPS empfiehlt sich Nginx Proxy Manager (NPM) als Reverse-Proxy — er holt Let’s-Encrypt-Zertifikate automatisch und terminiert TLS sauber vor Nextcloud.

---

2,5GbE-Netzwerk für den NAS-Eigenbau einrichten und messen

Ein N100-Board bringt meist einen Realtek RTL8125B oder Intel I226-V mit. Prüfe die ausgehandelte Geschwindigkeit:

ethtool eth0 | grep -i speed
# Erwartete Ausgabe: Speed: 2500Mb/s

Zeigt Speed: 1000Mb/s: Switch oder Kabel ist nicht 2,5G-fähig. Cat5e reicht für 2,5GbE bis 100 m — uraltes Cat5 (ohne „e“) kann auf längeren Strecken Probleme machen.

Switch-Empfehlung (lüfterlos):

• 5-Port 2,5GbE: QNAP QSW-1105-5T oder TP-Link TL-SG105-M2 kaufen — passiv gekühlt, ~60–80 €
• 8-Port mit 10G-Uplink: Zyxel XGS1210-12 kaufen (managed, 8×2,5G + 2×10G SFP+)

Durchsatz-Test mit iperf3:

# Auf dem NAS:
iperf3 -s

# Auf dem Client:
iperf3 -c 192.168.178.50 -t 15

Erwartete Ausgabe:

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-15.00  sec  4.10 GBytes  2.35 Gbits/sec   sender

2,3–2,4 Gbit/s entspricht ~290 MB/s — fast das Dreifache von Gigabit.

Realtek RTL8125B Interrupt-Coalescing-Fix: Bei steigendem rx_missed-Counter unter Last: sudo ethtool -C enp2s0 rx-usecs 100 rx-frames 64. Persistent machen via /etc/network/interfaces (post-up ethtool -C ...).

---

HBA-Controller in IT-Mode flashen: LSI/Broadcom Schritt für Schritt

Ein HBA wie der LSI 9211-8i muss für ZFS in den IT-Mode geflasht werden — ZFS will rohe Platten sehen, keinen RAID-Layer.

# Aktuelle Firmware-Info auslesen
sudo sas2flash -listall

# Alte Firmware löschen (SAS-Adresse vorher notieren!)
sudo sas2flash -o -e 6

# IT-Mode-Firmware einspielen (P20-Firmware empfohlen)
sudo sas2flash -o -f 2118it.bin -b mptsas2.rom

# SAS-Adresse zurückschreiben
sudo sas2flash -o -sasadd 500605bxxxxxxxxx

Wichtig: Nutze die P20-Firmware (Version 20.00.07.00) — P19 hat bekannte Probleme unter ZFS, P21 wurde nie für den 9211 freigegeben. Gebrauchte LSI-Karten von eBay sind häufig gefälscht oder falsch geflasht — Revision mit lspci -v vor dem Flash prüfen.

---

TrueNAS Scale als VM unter Proxmox: HBA per IOMMU durchreichen

Aktiviere IOMMU im Kernel (Intel-CPU):

nano /etc/default/grub
# GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"
update-grub && reboot

# IOMMU-Gruppe des HBA finden
for d in /sys/kernel/iommu_groups/*/devices/*; do
  n=${d#*/iommu_groups/*}; n=${n%%/*}
  printf 'Gruppe %s: ' "$n"; lspci -nns "${d##*/}"
done | grep -i 'lsi\|sas'

In der Proxmox-GUI: VM → Hardware → Add → PCI Device → HBA auswählen, Haken bei „All Functions“. Bei vfio: Failed to set iommu for container: Operation not permitted: pcie_acs_override=downstream,multifunction zur grub-Zeile hinzufügen.

N100-spezifisch: Auf N100-Boards mit einem einzigen PCIe-Slot gruppiert IOMMU den HBA zusammen mit anderen Geräten. echo "options vfio_iommu_type1 allow_unsafe_interrupts=1" > /etc/modprobe.d/vfio.conf ist dann nötig — sonst bleibt der HBA in der VM unsichtbar.

---

RAID ist kein Backup: Die 3-2-1-Strategie für deinen NAS-Eigenbau

Dieser Abschnitt gehört zur Planung — nicht ans Ende des Projekts. Richte Snapshots und Off-Site-Backup ein, bevor die ersten produktiven Daten auf den Pool wandern.

Typischer Anfängerfehler: RAID schützt ausschließlich vor Hardware-Ausfall einzelner Festplatten. Es schützt nicht vor: versehentlichem Löschen, Ransomware, Feuer/Diebstahl, Silent Data Corruption auf mehreren Platten gleichzeitig, Controller-Ausfall.

Die 3-2-1-Regel: 3 Kopien, 2 verschiedene Medien, 1 Off-Site.

Die 3-2-1-Backup-Strategie im Heimnetz: lokale Snapshots auf dem NAS, zweite Kopie auf externer Platte und Off-Site-Backup in der Cloud.

ZFS Snapshots für lokale Point-in-Time-Wiederherstellung:

# Automatische tägliche Snapshots via Cron
echo "0 3 * * * root /sbin/zfs snapshot storage/shared@backup-\$(date +%F)" > /etc/cron.d/zfs-snapshots

# Datei aus Snapshot wiederherstellen
cp /storage/shared/.zfs/snapshot/backup-2026-01-18/wichtige-datei.txt /storage/shared/

Off-Site-Backup-Optionen:

# rclone konfigurieren und testen
rclone config  # interaktiver Assistent
rclone sync /storage/shared b2:mein-nas-backup --dry-run -v  # erst trocken laufen lassen
rclone sync /storage/shared b2:mein-nas-backup --transfers 4

# Restore-Test — ein Backup ohne Restore-Test ist kein Backup
rclone copy b2:mein-nas-backup/daten/wichtig.pdf /tmp/restore-test/ -v

ZFS-Snapshots auf demselben Pool sind kein Backup. Wenn der Pool durch einen Controller-Defekt verloren geht, sind alle Snapshots ebenfalls weg. zfs send | zfs receive auf einen zweiten physischen Pool oder Off-Site-Ziel ist der einzige Weg, Snapshots als echtes Backup zu nutzen.

---

USV-Überwachung & SMART-Monitoring einrichten

ZFS verträgt einen harten Stromausfall mitten im Schreibvorgang schlecht — eine USV mit USB-Anbindung und sauberem Shutdown-Trigger ist Pflicht, kein Extra.

USV per NUT konfigurieren

sudo apt install nut
sudo nut-scanner -U  # USV erkennen

/etc/nut/ups.conf:

[usv]
    driver = usbhid-ups
    port = auto
    desc = "CyberPower CP1500 kaufen"

/etc/nut/nut.conf: MODE=standalone

sudo upsdrvctl start && upsc usv
# Erwartete Ausgabe: ups.status: OL (Online)

/etc/nut/upsmon.conf:

MONITOR usv@localhost 1 upsmon mypassword master
SHUTDOWNCMD "/sbin/shutdown -h +0"

# Shutdown-Logik testen (löst echten Shutdown aus!)
upsmon -c fsd

SMART-Monitoring mit smartd

sudo apt install smartmontools msmtp-mta
sudo smartctl -i -H /dev/sda  # SMART-Status prüfen

/etc/smartd.conf (für alle 4 Platten):

/dev/sda -a -o on -S on -s (S/../.././02|L/../../7/03) -m admin@deinedomain.de -M exec /usr/share/smartmontools/smartd-runner
/dev/sdb -a -o on -S on -s (S/../.././02|L/../../7/03) -m admin@deinedomain.de -M exec /usr/share/smartmontools/smartd-runner
/dev/sdc -a -o on -S on -s (S/../.././02|L/../../7/03) -m admin@deinedomain.de -M exec /usr/share/smartmontools/smartd-runner
/dev/sdd -a -o on -S on -s (S/../.././02|L/../../7/03) -m admin@deinedomain.de -M exec /usr/share/smartmontools/smartd-runner

sudo systemctl enable --now smartd

---

Upgrade-Pfad 2026–2028: 10GbE, RAM-Erweiterung, Pool-Expansion

Ein gut geplanter N100-Build ist nicht nur für heute — hier die realistischen Upgrade-Optionen für die nächsten Jahre:

ZFS-Pool-Migration bei Platform-Upgrade: Ein ZFS-Pool ist portabel — zpool export storage auf dem alten System, Platten umstecken, zpool import storage auf dem neuen. Einzige Einschränkung: Niemals direkt nach der Migration zpool upgrade ausführen, wenn ein Rollback noch möglich sein soll. Neue Feature-Flags machen den Pool auf älteren Systemen unlesbar.

---

DIY vs. Synology: 5-Jahres-Kostenrechnung 2026

Die ehrliche Gesamtrechnung über 5 Jahre — ohne Festplatten:

Fazit: Der DIY-Weg ist über 5 Jahre rund 70 € günstiger und flexibler (Docker, ZFS, RAM-Upgrade). Dafür zahlst du mit Bastelzeit und selbst gefahrenen Updates. Synology punktet mit DSM, Mobile-Apps und Support aus einer Hand. Faustregel: Ist dir eine Stunde Bastelzeit weniger als 70 € wert, kauf Synology. Macht dir das Setup Spaß und willst du volle Kontrolle, bau selbst.

Häufige Fehler beim NAS-Eigenbau: Symptome, Ursachen und Lösungen

ZFS-Alternative: mergerfs + SnapRAID für gemischte Platten

ZFS will gleich große Platten und festen RAID-Level. Hast du einen Mix aus 2-, 4- und 8-TB-Platten, ist mergerfs + SnapRAID flexibler:

apt install mergerfs snapraid
mergerfs /mnt/disk1:/mnt/disk2:/mnt/disk3 /mnt/storage -o defaults,allow_other,use_ino,category.create=mfs
snapraid sync && snapraid status

Der Nachteil: SnapRAID schützt nur bis zur letzten Sync-Ausführung. Für selten geänderte Mediensammlungen ideal — für aktive Datenbanken nimm ZFS.

TrueNAS Core vs. Scale: Wann was?

Core ist FreeBSD-basiert, ein geschlosseneres Appliance-System — robust out of the box, aber du sollst die Shell möglichst meiden. Scale ist Debian-basiert, flexibler bei Docker und KVM. iXsystems hat den Entwicklungsfokus klar auf Scale verschoben — Core erhält nur noch Wartungsupdates. Für Neueinsteiger 2026: TrueNAS Scale. Für Bastler mit Docker-Fokus und gemischter Hardware: OMV.

Kritische Warnung: Niemals direkt nach einer Core→Scale-Migration zpool upgrade ausführen. Neue Feature-Flags machen den Pool auf Core unlesbar. Warte 2–3 Wochen problemlosen Betrieb vor dem Upgrade.

ZFS ohne ECC-RAM: Mythos vs. Realität

ZFS ohne ECC ist nicht gefährlicher als jedes andere Dateisystem ohne ECC. Der „Scrub of Death“ — bei dem ein RAM-Bitfehler angeblich den gesamten Pool zerstört — ist ein Mythos, der von ZFS-Entwicklern widerlegt wurde. Ohne ECC kann ein Bitfehler eine Datei korrumpieren, bevor ZFS die Prüfsumme berechnet — aber das passiert bei ext4/btrfs genauso. Wer Backups nach 3-2-1 fährt, kann ZFS ohne ECC bedenkenlos einsetzen.

---

FAQ

Das könnte dich auch interessieren

• NAS-Backup in die Cloud: Datensicherheit für dein Heimnetz
• Einstieg in die Netzwerksegmentierung: Ein Praxis-Tutorial für dein Heimnetz
• Die besten NAS-Setups für Medienstreaming im Heimnetz

LSI 9207-8i Angebot