Im Auftakt dieser Serie habe ich TrueNAS bereits kurz als meinen zentralen Netzwerkspeicher erwähnt. Diesmal gehe ich tiefer: Warum überhaupt ein eigenes NAS statt verteilter Daten je Dienst, wie ich den Speicher technisch aufgebaut habe und welche Anwendungen heute tatsächlich darauf zugreifen.
Warum ein zentraler Netzwerkspeicher
Am Anfang lag jeder Dienst mit seinen Daten für sich: eigene Festplatte, eigener Ordner, keine Verbindung zu anderen Anwendungen. Das funktioniert, solange man wenig selbst hostet. Mit wachsender Zahl an Diensten wurde das schnell unübersichtlich, und ich habe angefangen, Daten mehrfach vorzuhalten, statt sie an einem Ort zu bündeln.
Ein zentraler Netzwerkspeicher löst genau dieses Problem. Statt dass jeder Dienst seinen eigenen Datentopf mitbringt, greifen mehrere Anwendungen auf denselben Ort zu. Das ist einer der Synergie-Effekte, die für mich den eigentlichen Reiz eines Homelabs ausmachen: Der Nutzen der Infrastruktur wächst nicht nur mit der Zahl der Dienste, sondern auch mit der Zahl ihrer Verbindungen untereinander.
TrueNAS als eigene VM im Homelab
Technisch läuft TrueNAS SCALE bei mir als eigenständige virtuelle Maschine auf dem Hauptserver, verwaltet über Proxmox VE. Der eigentliche Speicherplatz kommt dabei nicht aus einer virtuellen Festplatte, sondern aus zwei externen HDDs, die per USB-Passthrough direkt an die TrueNAS-VM durchgereicht werden. Das hat einen einfachen Grund: So bleibt der Speicher unabhängig vom restlichen VM-Storage des Hosts und lässt sich bei Bedarf auch an einem anderen Gerät weiterverwenden.
Bei der Aufteilung habe ich mich bewusst gegen ein klassisches RAID entschieden. Statt beide Festplatten zu einem Verbund mit Redundanz oder Geschwindigkeitsgewinn zu koppeln, laufen sie als zwei vollständig unabhängige Pools. Fällt eine Festplatte aus, bleibt die andere unberührt nutzbar. Das ist kein Ausfallschutz im klassischen Sinn, aber ein bewusster Kompromiss: Für ein Homelab dieser Größenordnung wiegt die Einfachheit des Setups mehr als die zusätzliche Komplexität eines echten RAID-Verbunds.
Beim Einrichten des USB-Passthroughs gab es einen Stolperstein, der sich vermutlich auf ähnliche Setups übertragen lässt: Proxmox vergibt beim Durchreichen von USB-Datenträgern standardmäßig keine eindeutige Seriennummer an das virtuelle Laufwerk. TrueNAS sieht dadurch mehrere Festplatten mit identischer, leerer Kennung und verweigert die Pool-Erstellung. Die Lösung war, die reale Seriennummer der Festplatte per lshw auszulesen und sie manuell in die Proxmox-Konfiguration der VM einzutragen.
Der Weg vom NAS zum Client: die SMB-Freigabe einrichten
Damit andere Geräte im Netzwerk auf den Speicher zugreifen können, stellt TrueNAS eine Freigabe über das SMB-Protokoll bereit. Unter Windows lässt sich diese Freigabe einfach als Netzlaufwerk einbinden. Auf Linux-Systemen, etwa in einzelnen VMs oder Containern im Homelab, läuft die Einbindung über einen klassischen CIFS-Mount in der fstab, ergänzt um eine separate Zugangsdaten-Datei.
Gerade bei der Linux-seitigen Einrichtung gibt es ein paar Stolpersteine, die mich zunächst Zeit gekostet haben:
- Ein einzelner Tippfehler in der IP-Adresse führt zu einer unspezifischen Verbindungsfehlermeldung, die auf den ersten Blick nach einem grundsätzlichen Netzwerkproblem aussieht.
- Fehlt der lokale Mount-Punkt als Verzeichnis, bricht der Mount-Befehl ohne hilfreiche Fehlermeldung ab.
- Die Datei mit den Zugangsdaten muss an einem Ort liegen, auf den der Mount-Prozess mit Root-Rechten tatsächlich zugreifen kann — im Home-Verzeichnis des eigenen Nutzers reicht das nicht, wenn der Mount als Root ausgeführt wird.
Alle drei Fehler sind einzeln schnell behoben, sobald man weiß, wonach man sucht. Ich habe sie mir inzwischen als kleine Checkliste notiert, die ich bei jedem neuen Mount zuerst durchgehe, bevor ich tiefer debugge.
Wer den Speicher heute nutzt
Der eigentliche Mehrwert zeigt sich erst daran, wer inzwischen tatsächlich auf die Freigabe zugreift. Auf meinem Windows-Rechner binde ich sie direkt als Netzlaufwerk ein, unter anderem für dieses LLM-Wiki, das komplett auf dem NAS liegt und von dort aus bearbeitet wird, statt lokal auf einem einzelnen Gerät.
Interessanter war der Zugriff aus einem eigenständigen Container heraus, den ich für die mobile Nutzung von Claude Code eingerichtet habe. Dieser Container läuft unprivilegiert und kann SMB-Freigaben technisch nicht selbst einbinden. Die Lösung: Der Netzlaufwerk-Mount passiert auf dem Proxmox-Host, der Container bekommt die passenden Unterordner anschließend nur per Bind-Mount durchgereicht. Bewusst habe ich dabei nicht die komplette Freigabe eingebunden, sondern gezielt nur die beiden benötigten Unterordner. Der Container sieht dadurch ausschließlich das, was er wirklich braucht, statt vollen Zugriff auf das gesamte NAS zu haben. Eine kleine Entscheidung, die aber zeigt, wie sich Bequemlichkeit und ein sauberes Berechtigungskonzept in der Praxis gegeneinander abwägen lassen.
Diese Liste an Nutzern wird mit der Zeit länger, nicht kürzer. Jeder neue Dienst, der Projektdaten oder Medien braucht, landet inzwischen als erste Option auf meiner Prüfliste für den zentralen Speicher, bevor ich über eine eigene, isolierte Lösung nachdenke. Das hat auch eine Kehrseite: Mit steigender Zahl an Zugriffen wächst die Verantwortung, den Speicherplatz im Blick zu behalten und die Zugriffsrechte nicht aus Bequemlichkeit großzügiger zu vergeben, als es der jeweilige Dienst eigentlich benötigt.
Fazit und Ausblick
Aus einer anfangs simplen Idee, Daten nicht mehr mehrfach vorzuhalten, ist ein zentraler Baustein meines Homelabs geworden: zwei unabhängige Speicher-Pools, sauber eingebunden über SMB und, wo nötig, gezielt statt pauschal freigegeben. Genau dieser zentrale Speicher ist die Grundlage für einige der Themen, die in dieser Serie noch folgen, etwa wenn es um regelmäßige Backups meiner Home-Assistant-Instanz auf genau diesem NAS geht.
Wie in den anderen Beiträgen dieser Serie: Bei Fragen oder Interesse an Details zur Umsetzung freue ich mich über eine Nachricht.