Die VM läuft auf Unraid, die Daten liegen auf Unraid, und trotzdem schiebst du sie über SMB durch ein virtuelles Netzwerkkabel, als stünde der Server drei Zimmer weiter. Mit Benutzername, Passwort und Umweg über den TCP-Stack. Für eine Datei, die zwei Zentimeter entfernt auf derselben Platte liegt.

Unraid hat dafür eine kürzere Tür, die laut Support-Thread im Forum seit 6.12.5 stabil läuft, auch mit Windows: VirtioFS. Der Share landet direkt in der VM, ohne Netzwerk, ohne Anmeldung, mit einem Eintrag in den VM-Einstellungen und einer Zeile in der VM. Das geht für Linux und für Windows. Und es hat einen Rechte-Haken, den ich dir nicht ersparen kann, weil er dich sonst in zwei Wochen erwischt.

Kurz gesagt: Am Ende hängt ein Unraid-Share als Ordner in deiner Linux-VM oder als Laufwerk Z: in deiner Windows-VM, überlebt jeden Neustart, und Dateien aus der VM gehören auf dem Array dem richtigen Benutzer. Dauer: 15 Minuten für Linux, 25 für Windows. Schwierigkeitsgrad: Standard, du kennst die VM-Seite von Unraid und hast schon mal ein Terminal offen gehabt. Stand: Unraid 7.3.2, geprüft am 05-09-2026.
Schaubild: Unraid-Share in der VM in drei Schritten: Share in den VM-Einstellungen eintragen, in der VM mounten, Rechte geradeziehen
Der ganze Weg auf einen Blick: eintragen, mounten, Rechte geradeziehen.

Was du brauchst

  • Unraid ab 6.12.5, ab dieser Version nennt der Support-Thread im Forum VirtioFS stabil, auch unter Windows. Geschrieben und geprüft ist die Anleitung gegen 7.3.2
  • Eine fertige VM: Linux mit Kernel ab 5.4, also Debian 11, Ubuntu 20.04 oder neuer; oder Windows 10 und 11
  • Einen Share, den die VM sehen soll, und einen Blick auf sein Backup. Die VM bekommt vollen Schreibzugriff, und was du dort versehentlich löschst, ist auf dem Array weg
  • Für Windows zwei Downloads: die VirtIO-Treiber, die Unraid selbst bereithält, und WinFsp
So liest du diese Anleitung: Alles, was du selbst tun sollst, steht in einem farbigen Kasten. [ per klick ] heißt: Das erledigst du mit der Maus in einer Web-Oberfläche, hier das Unraid-Dashboard oder der Windows-Desktop der VM. [ über die shell ] heißt: Den Befehl kopieren, ins Terminal einfügen, Enter. Stehen beide Kästen direkt untereinander, führen sie zum selben Ergebnis. Du gehst EINEN davon, nicht beide.

Ob deine Linux-VM den Weg überhaupt mitgeht, verrät ein Befehl in der VM:

uname -r
grep -c virtiofs /proc/filesystems

Die erste Zeile zeigt die Kernel-Version, alles ab 5.4 passt. Die zweite zählt, ob der Kernel das Dateisystem schon kennt. Eine 0 ist vor dem ersten Mount normal, weil der Kernel das Modul erst lädt, wenn er es braucht. Steht in der ersten Zeile vorne eine 4, ist deine VM alt, und für dich gilt unten der 9p-Umweg.

Alle Befehle rechnen mit denselben Beispielwerten. Eintragen musst du sie nirgendwo. Wo sie unten auftauchen, setzt du das ein, was bei dir steht.

  • Share auf Unraid: daten, also der Pfad /mnt/user/daten
  • Mount-Tag, das Namensschild für die VM: daten
  • Mountpunkt in der Linux-VM: /mnt/daten
  • Laufwerk in der Windows-VM: Z:
  • Benutzer in der Linux-VM: sakis
VirtioFS? Eine Durchreiche zwischen Unraid und der VM, die im Arbeitsspeicher liegt statt im Netzwerk. Unraid startet für jeden Share einen kleinen Helfer (virtiofsd), der den Ordner direkt an die VM weiterreicht. Die VM sieht ein ganz normales Dateisystem, nur ohne Kabel, ohne Anmeldung und ohne den Umweg über Samba.
/mnt/user/daten→ virtiofsd →deine VM→ mount →/mnt/daten oder Z:

Schritt 1: Den Share in den VM-Einstellungen eintragen

Das passiert komplett in Unraid. Die VM muss dafür aus sein, weil die Einstellungen erst beim nächsten Start greifen.

Im Unraid-Dashboard auf den Reiter VMs, die VM anhalten, dann auf ihr Symbol und Edit (deutsch: Bearbeiten). Im Formular nach unten zu den Feldern mit Unraid Share Mode (Unraid Freigabemodus). Dann: Unraid Share Mode auf Virtiofs Mode (Virtiofs-Modus), bei Unraid Share (Unraid Freigabe) den Share daten wählen, das Feld Unraid Mount Tag (Bezeichnung des eingehängten Datenträgers/Ordners) füllt sich mit daten von selbst. Unten Update (Aktualisierung), dann die VM starten. Stand Unraid 7.3; die deutschen Namen gelten für das offizielle Sprachpaket.

Warum der Modus zuerst kommt: Unraid baut daraus die VM-Konfiguration, und die sieht bei 9p und Virtiofs völlig anders aus. Ich würde immer Virtiofs nehmen. 9p ist der ältere Weg, läuft auch mit uralten Kernen, ist dafür langsamer und in Windows gar nicht erst im Rennen.

Willst du mehrere Shares, klickst du im Formular auf das Plus-Symbol links neben dem Block, und jeder Share bekommt sein eigenes Mount-Tag. Für Windows bleib erst mal bei einem, warum, steht gleich.

Geklappt hat es, wenn die VM ohne Meckern hochkommt und in der VM-Übersicht hinter ihrem Namen kein Fehler steht. Den Share selbst siehst du in der VM noch nicht, der kommt in Schritt 2.

Mount-Tag? Das Namensschild, unter dem die VM den Share findet. Unraid hängt den Ordner nicht unter seinem Pfad in die VM, sondern unter diesem Namen. In der VM sagst du dann: Häng mir das Ding namens daten nach /mnt/daten. Pfad auf Unraid und Ordner in der VM haben sonst nichts miteinander zu tun.

Schritt 2a: In der Linux-VM mounten

Einmal von Hand zum Testen, danach dauerhaft über die fstab.

sudo mkdir -p /mnt/daten
sudo mount -t virtiofs daten /mnt/daten
ls -la /mnt/daten

Zeile eins legt den leeren Ordner an, in den der Share eingehängt wird. Zeile zwei ist der eigentliche Mount: Dateisystemtyp virtiofs, dann das Mount-Tag, dann der Ordner. Zeile drei zeigt dir zur Kontrolle den Inhalt, und zwar denselben, den du im Unraid-Dashboard unter Shares siehst. Wenn dir dabei auffällt, dass die Dateien einem Benutzer mit der Nummer 99 gehören: Das stimmt so, und es ist das Thema von Schritt 3.

Damit der Share nach einem Neustart wiederkommt, kommt er in die fstab:

Die Datei im Editor öffnen:

sudo nano /etc/fstab

Ganz unten diese Zeile anhängen:

daten  /mnt/daten  virtiofs  rw,relatime  0  0

Speichern mit Strg+O und Enter, schließen mit Strg+X. Dann alles aus der fstab einhängen und prüfen:

sudo mount -a
findmnt /mnt/daten

findmnt antwortet mit einer Zeile, in der daten als Quelle und virtiofs als Typ stehen. Kommt nichts zurück, steckt ein Tippfehler in der fstab-Zeile, meistens im Tag. Steht die Zeile da, ist der Mount dauerhaft.

Schritt 2b: In der Windows-VM mounten

Windows kann VirtioFS nicht von Haus aus. Es braucht drei Teile: einen Treiber für das virtuelle Gerät, WinFsp als Brücke ins Windows-Dateisystem und einen kleinen Dienst, der beides verbindet. Das ist mehr Handarbeit als bei Linux, dafür machst du sie genau einmal.

Teil 1, VirtIO-Treiber. Beim Bearbeiten der VM in Unraid steht bei VirtIO Drivers ISO (VirtIO Treiber-ISO) das Treiber-Abbild, das Unraid selbst herunterlädt; es liegt in der VM als CD-Laufwerk. In der Windows-VM den Explorer öffnen, auf dieses Laufwerk gehen und virtio-win-guest-tools.exe ausführen, mit den Standardeinstellungen durchklicken. Das installiert alle VirtIO-Treiber, darunter den für VirtioFS, und legt virtiofs.exe unter C:\Program Files\Virtio-Win\VioFS\ ab. Prüf im Explorer, dass die Datei dort liegt.

Teil 2, WinFsp. Von winfsp.dev das aktuelle Installationspaket holen und mit den Standardeinstellungen installieren. Die Option Core reicht.

Jetzt der Dienst, der die beiden Teile zusammenbringt. Dafür eine Eingabeaufforderung als Administrator öffnen: Startmenü, cmd tippen, Rechtsklick, Als Administrator ausführen.

sc.exe create VirtioFsSvc binpath="C:\Program Files\Virtio-Win\VioFS\virtiofs.exe" start=auto depend="WinFsp.Launcher/VirtioFsDrv" DisplayName="Virtio FS Service"
sc.exe start VirtioFsSvc

Der erste Befehl registriert den Dienst so, dass er beim Hochfahren von selbst startet und erst loslegt, wenn WinFsp und der Treiber da sind. Der zweite startet ihn sofort. In der Antwort auf Zeile zwei steht STATE : 2 START_PENDING oder 4 RUNNING, beides ist gut. Dann im Explorer nachsehen: Unter Dieser PC liegt ein neues Laufwerk Z: mit dem Inhalt deines Shares. Kein Passwort, kein Netzlaufwerk, kein rotes Kreuz nach dem nächsten Neustart.

Der Dienst nimmt sich immer den ersten freien Buchstaben von Z abwärts. Und er bedient genau einen Share. Wer in Windows zwei oder drei braucht, legt den Dienst über den WinFsp-Launcher mehrfach an. Wie, steht in der virtio-win-Dokumentation unter den Quellen, und das ist nichts für den ersten Nachmittag.

Schritt 3: Die Rechte geradeziehen

Hier kommt der Haken. Unraid kann nichts dafür, das ist Unix. Auf dem Array gehören Dateien dem Benutzer nobody mit der Nummer 99 und der Gruppe users mit der Nummer 100, weil Samba genau das erwartet, damit jeder Netzwerk-Benutzer an alles kommt. Deine Linux-VM kennt aber nur ihren eigenen Benutzer, meist mit der Nummer 1000, und mit dieser Nummer landen neue Dateien auf dem Array. Von der VM aus sieht alles gut aus, vom Laptop über SMB ist es plötzlich schreibgeschützt. Im Forum ist das seit Jahren die häufigste Frage zu VM-Shares, und die übliche Antwort lautet: nachts ein chown per Cron. Geht auch ohne Nachtschicht.

Der schnelle Weg ist Unraids eingebauter Rechte-Reset. Der läuft über den ganzen Share und setzt alles zurück auf nobody:users. Bei großen Shares dauert das, und als Dauerlösung taugt es nicht. Es ist die Aufräumaktion nach einem Umzug:

Im Unraid-Dashboard auf Tools (Werkzeuge), dann New Permissions (Neue Berechtigungen). In der Liste nur den Share daten anhaken, unten Start. Stand Unraid 7.3.

Der saubere Weg für Linux-VMs: ein Benutzer in der VM, der dieselben Nummern trägt wie nobody:users auf Unraid. Alles, was der anlegt, sieht auf dem Array von Anfang an richtig aus. Die Gruppe 100 heißt auf Debian und Ubuntu sowieso schon users, und die Nummer 99 ist dort frei:

sudo useradd -u 99 -g 100 -m -s /bin/bash unraid
sudo passwd unraid
id unraid

Zeile eins legt den Benutzer mit Nummer 99 in der Gruppe 100 an, samt Home-Verzeichnis und Shell. Zeile zwei gibt ihm ein Passwort. Zeile drei ist die Kontrolle und antwortet mit uid=99(unraid) gid=100(users). Was du ab jetzt als dieser Benutzer nach /mnt/daten schreibst, gehört auf Unraid automatisch nobody:users. Ein Dienst in der VM, der auf den Share schreibt, sollte deshalb unter genau diesem Benutzer laufen.

Für Windows gibt es diesen Trick nicht, dort landen die Dateien mit der Nummer des Dienstes auf dem Array. Da bleibt New Permissions das Werkzeug, oder du gibst der Windows-VM einen eigenen Share, an den sonst niemand muss. Ehrlich gesagt ist das auch für Linux die entspannteste Lösung.

uid und gid? Linux merkt sich bei jeder Datei nicht den Namen des Besitzers, sondern nur zwei Nummern: Benutzer (uid) und Gruppe (gid). Namen wie nobody oder sakis sind Übersetzungen, die jedes System für sich macht. Zwei Systeme, die denselben Ordner sehen, streiten sich deshalb nie über Namen, aber ständig über Nummern.

Die ersten Einstellungen

Der Share hängt. Drei Dinge würde ich jetzt noch anfassen, bevor die VM in den Alltag geht.

Einen eigenen Share pro VM statt des großen Daten-Shares. Der Rechte-Haken aus Schritt 3 verschwindet fast ganz, wenn die VM einen Ordner bekommt, den nur sie beschreibt. Den Rest liest sie meinetwegen über einen zweiten, nur lesend gemounteten Share. Standardmäßig hängt der Share nämlich mit vollem Schreibzugriff, und ein rm -rf im falschen Ordner der VM ist ein rm -rf auf dem Array.

Nur lesend einhängen, wo Schreiben nicht nötig ist. Für Medien, Backups zum Zurücklesen oder Fotos für Immich in der VM reicht in der fstab ein ro statt rw. Dann kann die VM nichts kaputtmachen, egal wer sich dort einloggt:

In der fstab die Optionen der Zeile ändern und neu einhängen:

daten  /mnt/daten  virtiofs  ro,relatime  0  0
sudo umount /mnt/daten && sudo mount -a
touch /mnt/daten/test 2>&1 | head -1

Der touch muss jetzt mit Read-only file system scheitern. Das ist das eine Mal, wo eine Fehlermeldung die gute Nachricht ist.

Das Backup des Shares prüfen, bevor die VM losschreibt. Unraids Parität schützt vor einer kaputten Platte, nicht vor einem Skript in der VM, das den falschen Ordner leert. Steckt der Share noch in keinem Backup-Plan, kommt er jetzt rein. Ja, schon wieder. Ich hör auch nicht auf damit.

Häufige Stolpersteine

Linux: mount: unknown filesystem type 'virtiofs'. Der Kernel der VM ist zu alt. Entweder die VM auf eine aktuelle Version heben, oder in Schritt 1 den 9p-Modus wählen und in der VM mit sudo mount -t 9p -o trans=virtio,version=9p2000.L daten /mnt/daten einhängen. Langsamer, aber es geht.

Windows: kein Laufwerk Z: zu sehen. In neun von zehn Fällen fehlt WinFsp oder der Dienst läuft nicht. In services.msc nach Virtio FS Service suchen. Steht er auf Beendet, den Fehlertext aus der Ereignisanzeige lesen, meist ist der Pfad zur virtiofs.exe im Befehl aus Schritt 2b falsch. Mit genau dieser Frage wurde übrigens der VirtioFS-Thread im Unraid-Forum eröffnet. Du bist in guter Gesellschaft.

Die VM friert nach dem Eintragen des Shares ein. Im Forum berichten einzelne Nutzer von Hängern, sobald VirtioFS mit einem geänderten Speicher-Modus (Memory Backing) in der VM-Konfiguration steht. Erst Unraid auf den aktuellen Stand bringen, dann die VM einmal neu anlegen statt die alte umzubauen. Hilft das nicht, bleibt 9p als Rückzugsort.

Vom Laptop aus plötzlich schreibgeschützt. Das ist Schritt 3, die Dateien gehören der VM-Benutzernummer. Einmal New Permissions (Neue Berechtigungen) drüberlaufen lassen, dann den 99er-Benutzer anlegen, damit es nicht wieder passiert.

Fazit

VirtioFS ist der Weg, den Unraid für VM-Shares eigentlich immer gemeint hat: ein Klick im Formular, eine Zeile in der fstab, fertig. SMB in einer VM auf demselben Server ist damit für mich eine Notlösung. Gelten lasse ich sie nur noch für Windows-VMs mit mehreren Shares, weil dort die Dienst-Einrichtung schnell fummelig wird.

Verstehen muss man nur den Rechte-Teil, und den versteht man einmal und dann für immer. Wer ihn mit einem eigenen Share pro VM umgeht, hat ihn nie wieder.

Welche VM hängt bei dir am Array, und läuft die über VirtioFS, 9p oder doch noch über SMB? Und hat dich der Rechte-Haken schon erwischt? Schreib es in die Kommentare.

Wenn dir solche Anleitungen taugen: Der Newsletter unten bringt die nächste ins Postfach, sobald sie steht, ohne dass du hier vorbeischauen musst.

Quellen