Werkstatt & Experimente Homelab & Server

Proxmox als Fileserver – USB-Festplatten mit LXC und Samba

Zwei USB-Festplatten, ein Proxmox und eine Horde Ratten

Ausgangspunkt war ein vorhandenes NAS, das für seinen verbliebenen Einsatzzweck unnötig Strom verbrauchte. Da ohnehin ein Proxmox-Server läuft, wollten wir prüfen, ob sich zwei vorhandene USB-Festplatten direkt am Proxmox-Host betreiben und über einen schlanken Debian-LXC mit Samba im Netzwerk bereitstellen lassen – als ganz normaler Netzwerkspeicher für Daten und Downloads.

Art: Praxisversuch im Homelab
Zutaten: Proxmox VE · 2 USB-Festplatten (NTFS) · Debian 13 LXC · Samba
Ergebnis: Funktioniert – Lesen und Schreiben auf beiden Platten
Noch offen: Kontrolle beim nächsten regulären Neustart des Proxmox-Hosts

Comic-Panel im Rattenlabor: Hausmeisterratte und Laborratte stehen vor zwei USB-Festplatten, einem Monitor mit Proxmox und einem Strommessgerät und besprechen das stromhungrige NAS. — Panel 1 Das Problem: ein NAS, das mehr Strom zieht als nötig.

01 Ausgangslage und Konzept

Die Idee ist schnell erzählt: Die Festplatten hängen per USB am Proxmox-Host, werden dort fest eingehängt und dann an einen kleinen Container durchgereicht. Erst im Container läuft Samba und stellt die Daten im Netzwerk bereit.

USB-Festplatten
Proxmox-Host
Mountpoints
Debian-LXC
Samba
Windows / LAN

Warum diese Lösung?

Proxmox läuft ohnehin – kein zusätzliches Gerät im Dauerbetrieb.
Die USB-Festplatten sind bereits vorhanden – nichts Neues zu kaufen.
Kein Samba auf dem Proxmox-Host – der Hypervisor bleibt schlank.
Eigener LXC – Fileserver-Dienste sind sauber vom Hypervisor getrennt.
Sehr wenig Ressourcen – der Container braucht kaum etwas.
Das alte NAS darf gehen – nach einem erfolgreichen Paralleltest kann es abgeschaltet werden.

Comic-Panel: Hausmeisterratte und Laborratte mit zwei USB-Festplatten vor einem Monitor mit der Proxmox-Oberfläche, daneben eine Checkliste. — Panel 2 Die Platten ziehen an den Proxmox-Host um.

02 USB-Festplatten am Proxmox-Host einbinden

Zuerst die Datenträger identifizieren – zum Beispiel mit:

Proxmox-Host

lsblk -f

In unserem realen Aufbau wurden zwei USB-Festplatten erkannt. Beide verwenden NTFS und wurden mit dem Linux-Treiber ntfs3 eingebunden.

Mountpoints anlegen:

Proxmox-Host

mkdir -p /mnt/wd8tb
mkdir -p /mnt/wd14tb

Feste Zuordnung per UUID

Die produktive Konfiguration verwendet UUIDs in /etc/fstab. So hängt die Zuordnung nicht davon ab, ob Linux eine Platte beim nächsten Start als /dev/sda, /dev/sdb usw. erkennt.

Vor jeder Änderung eine Sicherung anlegen:

Proxmox-Host

cp /etc/fstab /etc/fstab.backup-YYYYMMDD

Danach die UUID-basierten Einträge ergänzen. Die Werte in spitzen Klammern sind Platzhalter:

/etc/fstab

UUID=<UUID-DER-ERSTEN-PLATTE>  /mnt/wd8tb   ntfs3  <OPTIONEN>  0  0
UUID=<UUID-DER-ZWEITEN-PLATTE> /mnt/wd14tb  ntfs3  <OPTIONEN>  0  0

Konfiguration anschließend prüfen:

Proxmox-Host

systemctl daemon-reload
mount -a
findmnt /mnt/wd8tb
findmnt /mnt/wd14tb

Comic-Panel: Auf mehreren Monitoren sind die Proxmox-Oberfläche und ein Terminal zu sehen, die Laborratte erklärt, wie die Festplatten an den Debian-Container weitergereicht werden. — Panel 3 Ein kleiner Container bekommt die beiden Platten.

03 Debian-LXC als Fileserver

Für den Fileserver wurde ein schlanker Debian-13-LXC eingerichtet. Mehr braucht es für Samba nicht.

System: Debian 13
Typ: unprivilegierter LXC
CPU: 2 vCPU
RAM: 2 GB
Swap: 512 MB
Root: 16 GB
Autostart: aktiviert

Platten als Bind Mounts durchreichen

Die auf dem Proxmox-Host eingehängten USB-Festplatten werden als Bind Mounts in den Container eingebunden. In der Container-Konfiguration auf dem Host (/etc/pve/lxc/<CTID>.conf) sieht das in unserem Aufbau so aus:

/etc/pve/lxc/<CTID>.conf

mp0: /mnt/wd8tb,mp=/mnt/wd8tb
mp1: /mnt/wd14tb,mp=/mnt/wd14tb

Danach im Container kontrollieren, ob beide Platten ankommen:

Debian-LXC

df -h /mnt/wd8tb /mnt/wd14tb

04 Samba installieren und Freigaben erstellen

Im Debian-LXC Samba installieren und einen Benutzer für den SMB-Zugriff anlegen:

Debian-LXC

apt update
apt install samba
smbpasswd -a <benutzer>

Die beiden Datenträger werden anschließend als eigene Freigaben in der Samba-Konfiguration angelegt. Die Grundstruktur:

/etc/samba/smb.conf

[WD8TB]
   path = /mnt/wd8tb
   browseable = yes
   read only = no
   guest ok = no
   valid users = <benutzer>

[WD14TB]
   path = /mnt/wd14tb
   browseable = yes
   read only = no
   guest ok = no
   valid users = <benutzer>

Erweiterter Hinweis: force user, force group, create mask, directory mask

In unserem tatsächlichen Aufbau haben wir zusätzlich diese vier Optionen verwendet. Kurz erklärt:

force user / force group – alle Zugriffe über die Freigabe laufen im Container unter einem festen Benutzer bzw. einer festen Gruppe.
create mask / directory mask – legen fest, welche Rechte neu angelegte Dateien bzw. Verzeichnisse höchstens bekommen.

Das ist keine allgemeine Empfehlung: Welche Werte sinnvoll sind, hängt davon ab, wie Rechte auf dem Host, im Container und auf dem Dateisystem zusammenspielen. Berechtigungen müssen zum eigenen System passen.

Konfiguration prüfen und Dienst kontrollieren:

Debian-LXC

testparm
systemctl status smbd

Comic-Panel: Die Ratten testen den Zugriff, auf einem Monitor ist der Windows-Explorer mit den Netzwerkfreigaben geöffnet, daneben eine Checkliste für den Test. — Panel 4 Der Moment der Wahrheit: Windows klopft an.

05 Windows-Zugriff testen

Vom Windows-PC aus geht es im Explorer über die Adresse des Fileservers:

Windows-Explorer

\\<IP-DES-FILESERVERS>

Dabei nicht nur schauen, ob die Freigaben auftauchen. Mindestens das hier gehört zum Test:

Verzeichnisse öffnen
Dateien lesen
neue Datei schreiben
Datei wieder löschen
größere Datei kopieren
beide USB-Festplatten testen
Zugriff nach Neustart des LXC erneut kontrollieren

In unserem Test funktionierten Lesen und Schreiben auf beiden Datenträgern.

Comic-Panel: Eine Rat in Black im schwarzen Anzug hat aufgeräumt, auf den Monitoren erscheint eine Windows-Fehlermeldung, die übrigen Ratten sehen verdutzt zu. — Panel 5 Wenn die RiB aufräumen, ist hinterher etwas weg.

06 Aus dem Rattenlabor: [homes] nicht vorschnell „aufräumen“

Aus dem Rattenlabor

Eigentlich lief alles. Also wollten wir die Samba-Konfiguration noch schnell aufräumen. Der standardmäßige Bereich [homes] stand da herum, und für unsere beiden eigentlichen Freigaben brauchten wir ihn nicht. Also: weg damit.

Hausmeisterratte Das sieht überflüssig aus.
RiB Muss ich was aufräumen?
[homes] verschwindet.
Windows ZUGRIFF VERWEIGERT
RiB Auftrag erledigt.

Danach verweigerte Windows plötzlich den Zugriff. Der direkte Samba-Test funktionierte aber weiterhin – Samba selbst und die eigentlichen Freigaben waren also grundsätzlich erreichbar. Nachdem [homes] wiederhergestellt war, klappte der Windows-Zugriff sofort wieder.

Unsere funktionierende [homes]-Konfiguration:

/etc/samba/smb.conf

[homes]
   browseable = No
   comment = Home Directories
   create mask = 0700
   directory mask = 0700
   valid users = %S

Comic-Panel: Die Ratten vor Monitoren mit Windows-Explorer und Erfolgsmeldung, auf der Checkliste sind die Punkte abgehakt. — Panel 6 Versuch erfolgreich – beide Platten im Netz.

07 Abschlusstest

Am Ende funktionierte:

beide USB-Festplatten am Proxmox-Host
persistente Mountpoints
Weitergabe an den Debian-LXC
Samba im Container
Zugriff von Windows
Lesen und Schreiben auf beiden Datenträgern
LXC-Autostart
Neustart des LXC ohne Probleme

Proxmox-Host

findmnt /mnt/wd8tb
findmnt /mnt/wd14tb
pct status <CTID>
pct exec <CTID> -- systemctl is-active smbd
pct exec <CTID> -- df -h /mnt/wd8tb /mnt/wd14tb

Anschließend noch einmal den Lese- und Schreibzugriff von Windows testen.

Übersichtsgrafik im Comic-Stil: Laborratte bei der Fehlersuche – QNAP-Fehlermeldung, Verzeichnisse als nobody nogroup im Container, Ursache UID-Mapping des unprivilegierten LXC, Korrektur in der /etc/fstab, erneutes Einhängen, Verzeichnisse als root root, erfolgreicher Schreibtest und ein Hinweis zum fstab-Fehler. — Panel 7 Fehlersuche in acht Schritten: vom „Zugriff verweigert“ zur richtigen UID/GID.

08 Wenn der Labortest funktioniert – aber die Realität „Zugriff verweigert“ sagt

Aus dem Rattenlabor

Alle Tests grün, Checkliste abgehakt, Kaffee verdient. Dann kam der eigentliche Umzug: vorhandene Daten vom QNAP auf die neue Samba-Freigabe verschieben. Und Windows so:

Laborratte Schreibtest bestanden. Was soll da schon passieren?
Windows Zugriff auf den Zielordner wurde verweigert.
Laborratte Aber … der Schreibtest hat doch funktioniert.

Das war ein echter Fehler aus unserem Aufbau – trotz zuvor erfolgreicher Schreibtests unter Windows.

Fehlersuche: Wem gehört das eigentlich?

Zuerst haben wir im Container nachgesehen, wem der Datenträger und der betroffene Ordner gehören:

Proxmox-Host

pct exec <CTID> -- ls -ld /mnt/<datentraeger>
pct exec <CTID> -- ls -ld "/mnt/<datentraeger>/<problematischer-ordner>"

Die Verzeichnisse erschienen als nobody nogroup. Danach die tatsächlichen Mountoptionen auf dem Proxmox-Host:

Proxmox-Host

findmnt -no SOURCE,FSTYPE,OPTIONS /mnt/<datentraeger>

Der NTFS3-Datenträger war effektiv mit uid=0,gid=0 eingebunden – er gehörte also Host-root.

Ursache: der unprivilegierte LXC

Der Fileserver läuft als unprivilegierter LXC. Deshalb entspricht root im Container nicht automatisch der Host-UID 0 – die Benutzer- und Gruppen-IDs des Containers werden auf einen eigenen Bereich des Hosts abgebildet. Dateien, die Host-UID 0 gehören, liegen außerhalb dieses Bereichs; im Container tauchen sie deshalb als nobody nogroup auf, und Container-root darf dort nicht einfach schreiben.

Das verwendete Mapping lässt sich auf dem Host prüfen:

Proxmox-Host

grep '^root:' /etc/subuid /etc/subgid

In unserem konkreten System ergab sich:

Ausgabe in unserem System

/etc/subuid:root:100000:65536
/etc/subgid:root:100000:65536

Damit entspricht Container-root in unserem Aufbau der Host-UID/GID 100000.

Korrektur der NTFS3-Mounts

Vor der Änderung wurde /etc/fstab wieder gesichert (siehe Kapitel 02). Ursprünglich waren die Datenträger sinngemäß so eingebunden:

/etc/fstab – vorher

UUID=<UUID> /mnt/<datentraeger> ntfs3 defaults,nofail 0 0

Für unseren unprivilegierten Container wurde die Besitzzuordnung passend zum ermittelten Mapping ergänzt:

/etc/fstab – nachher

UUID=<UUID> /mnt/<datentraeger> ntfs3 defaults,nofail,uid=100000,gid=100000 0 0

Der LXC wurde vor dem Neu-Einhängen gestoppt:

Proxmox-Host

pct stop <CTID>

Kleiner Stolperstein nebenbei

Mitten in den Arbeiten meldete sich die fstab selbst:

Meldung

/etc/fstab: parse error at line 1

Schuld war die Kopfzeile ganz oben – ihr fehlte das führende Kommentarzeichen:

Falsch

<file system> <mount point> <type> <options> <dump> <pass>

Richtig

# <file system> <mount point> <type> <options> <dump> <pass>

Ein einzelnes #. Die Ratten haben es inzwischen eingerahmt.

Vor dem tatsächlichen Mount wurde die Syntax mit einem Testlauf geprüft – -f tut nur so, als würde es einhängen:

Proxmox-Host

mount -a -f

Danach neu einlesen, einhängen und kontrollieren:

Proxmox-Host

systemctl daemon-reload
mount /mnt/<datentraeger>
findmnt -no SOURCE,FSTYPE,OPTIONS /mnt/<datentraeger>

Jetzt war die gewünschte UID/GID-Zuordnung aktiv.

Kontrolle im LXC

Container starten und noch einmal nachsehen:

Proxmox-Host

pct start <CTID>
pct exec <CTID> -- ls -ld /mnt/<datentraeger>

Die Verzeichnisse erschienen nicht mehr als nobody nogroup, sondern korrekt als root root. Anschließend direkt im zuvor problematischen Ordner ein Schreibtest:

Proxmox-Host

pct exec <CTID> -- touch "/mnt/<datentraeger>/<problematischer-ordner>/schreibtest.txt"

Der Test war erfolgreich; die Testdatei wurde danach wieder entfernt.

Ergebnis aus dem realen Betrieb: Nach dieser Korrektur funktioniert auch das tatsächliche Schreiben bzw. Verschieben der Daten vom QNAP auf die neue Samba-Freigabe.

Der Labortest war bestanden. Dann kam die Realität – und noch eine Ratte kroch aus dem Berechtigungsmodell.

Fazit

Ein universeller NAS-Ersatz ist das nicht. Für unseren konkreten Einsatzzweck ließen sich die vorhandenen USB-Festplatten aber mit sehr wenig zusätzlichem Ressourcenbedarf über den ohnehin laufenden Proxmox-Server als Netzwerkspeicher bereitstellen.

Versuch erfolgreich. Zwei Festplatten im Netz, ein Gerät weniger im Dauerbetrieb – und die RiB haben gelernt, dass nicht alles, was überflüssig aussieht, auch gelöscht werden sollte.