Kurz gesagt: Am Ende sieht deine VM einen Unraid-Share wie eine eigene Platte: unter Linux als Ordner /mnt/daten, unter Windows als Laufwerk Z:. Kein SMB-Benutzer, kein Netzwerk-Umweg, und nach einem Neustart ist der Share von allein wieder da. Dauer rund 20 Minuten, Stufe Standard. Stand: Unraid 7.3.2, geprüft am 07-09-2026.
Unraid-Share per VirtioFS in drei Schritten: Share in die Vorlage, in der VM einhängen, neustartfest machen
Der ganze Weg auf einen Blick: Schritt 2 ist der, den die Unraid-Doku nicht erwähnt.

Eine VM auf Unraid, die per SMB auf einen Share zugreift, tut etwas Seltsames: Sie schickt jede Datei durch das virtuelle Netzwerk an den Rechner, auf dem sie selbst läuft. Das ist, als würdest du deinem Mitbewohner einen Brief schreiben und ihn zur Post bringen, statt ihn über den Flur zu tragen. Es funktioniert. Es kostet nur Zeit, einen SMB-Benutzer mit Passwort und bei jeder Datei ein Stück Prozessor.

VirtioFS ist der Flur. Unraid bringt es seit Version 6.11.1 mit, für Windows-VMs gilt es seit 6.12.5 als stabil, und die Einrichtung ist kürzer als bei SMB. Nur eines sagt die Unraid-Doku nicht: dass die VM den Share danach nicht von allein sieht. Genau daran hängt es im Forum am häufigsten, und genau da setzt diese Anleitung an.

VirtioFS? Ein Durchreichfenster zwischen Unraid und der VM. Die VM sieht den Ordner, als läge er auf ihrer eigenen Platte, weil beide sich ein Stück Arbeitsspeicher teilen und die Daten dort hin- und herschieben. SMB und NFS sind dagegen Netzwerkprotokolle: Sie wurden für Rechner gebaut, die in verschiedenen Räumen stehen, und tun so, als wäre das hier auch so.
Linux- oder Windows-VM→ ruft Mount Tag „daten“ →virtiofsd auf Unraid→ reicht durch →/mnt/user/daten

Was du brauchst, bevor du die VM anfasst

  • Unraid 6.12.5 oder neuer, besser 7.x. Für Linux-VMs reicht 6.11.1. Für Windows ist 6.12.5 die Untergrenze: Davor froren Windows-VMs nach Stunden ein, das hat mackid1993 im Unraid-Forum über Monate nachverfolgt und mit QEMU 7.2 als behoben gemeldet.
  • VMs eingeschaltet unter Settings → VM Manager.
  • Eine fertige VM: Linux mit Kernel 5.4 oder neuer (jedes Debian oder Ubuntu der letzten Jahre) oder Windows 10/11. Wie du sie anlegst, zeigt die Unraid-Doku; hier geht es nur um den Share. Die Linux-VM bedienst du über die VNC-Konsole in Unraid oder per SSH, und wenn SSH bei dir noch mit Passwort und als root läuft, wäre das der Beitrag davor.
  • Für Windows: die VirtIO-Treiber-ISO in Version 0.1.248 oder neuer, unter Settings → VM Manager eingetragen. Der Dateiname verrät die Version. Ältere Treiber hatten ein Speicherleck, das die VM nach und nach lahmlegte; auch das steht bei mackid1993.
  • Ein Backup des Shares. Die VM schreibt direkt hinein, ohne Papierkorb. Unraids Parität schützt vor einer kaputten Platte, nicht vor einem falschen Löschbefehl. Ich weiß, dass du das schon kennst.
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 die Unraid-Oberfläche oder Windows in 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.

Version und VM-Schalter prüfst du in der Unraid-Oberfläche:

Oben Tools, dann Update OS: Dort steht die laufende Version. Danach Settings → VM Manager: Enable VMs muss auf Yes stehen, und bei einer Windows-VM muss unter VirtIO Windows Drivers ISO die ISO gewählt sein. Ist alles gesetzt, taucht oben in der Leiste der Reiter VMs auf.

Den Kernel prüfst du in der Linux-VM. Alles ab 5.4 kennt virtiofs:

uname -r
6.1.0-37-amd64

Diese Werte benutze ich im ganzen Beitrag; ersetze sie durch deine:

  • Share auf Unraid: daten, Pfad /mnt/user/daten
  • Mount Tag (das Namensschild, unter dem die VM den Share findet): daten
  • Ordner in der Linux-VM, in dem der Share erscheint: /mnt/daten
  • Laufwerk in der Windows-VM: Z:
  • Dein Benutzer in der Linux-VM: sakis

Schritt 1: Den Share in die VM-Vorlage eintragen

Die VM muss dafür aus sein. Dann bekommt sie in ihrer Vorlage einen zusätzlichen Eintrag, und Unraid übersetzt ihn beim Speichern in die XML-Beschreibung der Maschine.

Reiter VMs, auf das Symbol der VM klicken, Stop, danach noch einmal auf das Symbol und Edit (Stand Unraid 7.3). Im Formular nach unten zu Unraid Share Mode und dort Virtiofs Mode wählen. Bei Unraid Share den Share daten auswählen; Unraid Source Path füllt sich mit /mnt/user/daten und Unraid Mount Tag mit daten. Unten Update.

Der Mount Tag ist das Schild am Durchreichfenster: Unraid hängt es an den Ordner, die VM ruft es gleich beim Einhängen auf. Lass ihn kurz und ohne Leerzeichen, das erspart dir später Anführungszeichen. Ob Unraid alles richtig übersetzt hat, siehst du in der XML-Ansicht, und die lohnt einen Blick, weil ein Block darin früher gern fehlte:

Wieder Edit öffnen und oben rechts von Form View auf XML View umschalten. Mit Strg+F nach filesystem und nach memoryBacking suchen.

<memoryBacking>
  <source type='memfd'/>
  <access mode='shared'/>
</memoryBacking>
…
<filesystem type='mount' accessmode='passthrough'>
  <driver type='virtiofs' queue='1024'/>
  <binary path='/usr/libexec/virtiofsd'/>
  <source dir='/mnt/user/daten'/>
  <target dir='daten'/>
</filesystem>

Zeilenumbrüche und Reihenfolge dürfen bei dir abweichen; auf die zwei Blöcke kommt es an. Der Block memoryBacking ist der Grund, warum das Ganze schneller ist als SMB: VM und Unraid teilen sich ein Stück Arbeitsspeicher, und genau dort wandern die Daten hin und her. Fehlt er, ergänzt du ihn direkt hinter der Zeile currentMemory; SimonF, der VirtioFS im Unraid-Forum betreut, nennt die drei Zeilen als Pflicht. Dann die VM starten:

Auf das Symbol der VM klicken, Start. Im Reiter VMs steht danach started neben dem Namen.

Schritt 2: In der Linux-VM einhängen

Jetzt der Teil, den die Doku überspringt. Linux hängt ein Dateisystem nie von allein ein; der Share ist da wie ein eingesteckter USB-Stick, den noch niemand geöffnet hat. Du brauchst einen leeren Ordner als Einstiegspunkt und einen Mount-Befehl, der das Namensschild aufruft:

sudo mkdir -p /mnt/daten
sudo mount -t virtiofs daten /mnt/daten
findmnt /mnt/daten
TARGET     SOURCE FSTYPE   OPTIONS
/mnt/daten daten  virtiofs rw,relatime

Steht dort virtiofs, ist das Fenster offen. Ein ls -la /mnt/daten zeigt dir die Dateien vom Share, und zwar mit einer Eigenheit, die du gleich noch brauchst: Als Besitzer steht dort die Zahl 99 statt eines Namens und als Gruppe users. Das ist Unraids Standardbesitzer nobody (Nummer 99) mit der Gruppe users (Nummer 100), und deine Debian-VM kennt nur die Gruppe, nicht den Benutzer. Alles richtig so. Kurz freuen: Die Datei, die du eben auf Unraid abgelegt hast, liegt jetzt in der VM, ohne dass ein Byte durch ein Netzwerk musste.

Schritt 3: Den Mount neustartfest machen

Der Mount aus Schritt 2 lebt bis zum nächsten Neustart. Dauerhaft wird er über die Datei, in der Linux alle Dateisysteme nachschlägt, die beim Hochfahren dran sind:

sudo nano /etc/fstab

Ans Ende der Datei kommt diese eine Zeile; speichern mit Strg+O und Enter, schließen mit Strg+X:

daten  /mnt/daten  virtiofs  defaults,nofail  0  0

Das Wort nofail ist die wichtigste Entscheidung in dieser Zeile, und ich würde sie nie weglassen. Ohne das Wort behandelt systemd den Mount als Pflicht: Fehlt der Share beim Start, weil du ihn aus der Vorlage genommen oder die VM auf einen anderen Rechner kopiert hast, bleibt die Maschine im Notfallmodus stehen und wartet auf dich. Mit nofail fährt sie hoch, der Ordner ist eben leer, und du siehst es beim ersten Blick. Ob die Zeile stimmt, prüfst du ohne Neustart:

sudo umount /mnt/daten
sudo mount -a
findmnt /mnt/daten

Kommt dieselbe Ausgabe wie in Schritt 2, hat fstab die Zeile verstanden. Kommt ein Fehler, ist es fast immer ein Tippfehler im Tag oder ein Ordner, der nicht existiert; fstab meldet beides mit Zeilennummer.

Windows-VM: ein Übersetzer und ein Dienst

Windows kennt kein virtiofs und lernt es auch nicht von allein. Schritt 1 ist derselbe; in der VM brauchst du danach zwei Programme, und die Reihenfolge ist nicht egal.

WinFsp? Der Dolmetscher. Windows spricht nur NTFS und ein paar Verwandte; WinFsp bringt ihm bei, ein fremdes Dateisystem wie ein gewöhnliches Laufwerk zu zeigen. Der VirtioFS-Treiber redet mit Unraid, WinFsp übersetzt das für den Explorer.

In der Windows-VM zuerst WinFsp von winfsp.dev/rel laden und mit den Standardhaken installieren (die Komponente Core reicht). Dann im Explorer das CD-Laufwerk virtio-win öffnen und virtio-win-guest-tools.exe starten; in der Komponentenliste muss Viofs angehakt bleiben. Neustart. Danach Windows-Taste, Dienste eintippen, in der Liste VirtIO-FS Service suchen: Rechtsklick, Eigenschaften, Starttyp Automatisch, dann Starten.

Geklappt hat es, wenn im Explorer unter Dieser PC ein Laufwerk Z: mit dem Namen deines Shares steht. Das ist die ganze Windows-Seite. Wer die Treiber bei der Installation schon von Unraid 7 einspielen ließ, findet den Dienst oft bereits vor und braucht nur noch WinFsp und den Starttyp. Der Weg zu Fuß, Treiber per Geräte-Manager und Dienst per sc create, steht in der virtio-win-Doku in den Quellen; nötig ist er nur, wenn der Installer den Dienst nicht anlegt.

Was du danach einstellst

Der Share hängt. Vier Dinge würde ich jetzt noch erledigen, alle wegen eines Standards, der nicht zu dir passt.

Nur den einen Share durchreichen, nicht /mnt/user. Die Vorlage bietet dir den ganzen Baum an, und das ist verführerisch, weil du dann nie wieder etwas eintragen musst. Enzaii meldet im Forum Ordner, die auf diesem Weg nur lesbar ankamen, und die VM sieht dann alles, was sie versehentlich löschen kann. Ein zweiter Share ist ein zweiter Eintrag in der Vorlage und unter Linux eine zweite fstab-Zeile; unter Windows ist es komplizierter, dazu gleich.

Schreibrechte für deinen Benutzer. Die Dateien gehören 99:100, dein Benutzer in der VM ist meist 1000. Schreiben darf er nur, wo die Gruppe users darf. Also nimm ihn in die Gruppe auf und prüfe, dass sie in deiner VM wirklich die Nummer 100 trägt:

getent group 100
sudo usermod -aG users sakis
users:x:100:

Nach dem Ab- und Anmelden zeigt id die Gruppe users. Bleibt trotzdem „Permission denied“, hat Unraid dem Ordner irgendwann engere Rechte gegeben; TexasUnraid rät im Forum zu Tools → Docker Safe New Perms auf Unraid, das setzt den Share auf die Standardrechte zurück. Ordner, die Windows über den Share anlegt, kommen laut djmulder gelegentlich mit Rechten an, in denen selbst der Besitzer nicht schreiben darf; derselbe Handgriff hilft.

Den Windows-Dienst nie von Hand neu starten. johnsanc und 20_100 haben im Forum beschrieben, was dann passiert: Die Dateien im Laufwerk gehören plötzlich einem Windows-Konto, das es nicht gibt, und der Explorer verweigert den Zugriff. Starttyp Automatisch, und dann in Ruhe lassen; wenn etwas klemmt, die VM neu starten.

Einmal messen, bevor du SMB abschaltest. Beweis vor Applaus: LeoRX hat im Forum eine Windows-VM gemessen, in der SMB beim Schreiben schneller war als VirtioFS. Das war 2023 mit älteren Treibern, aber dein Ergebnis kennt niemand außer dir. Eine Testdatei von einem Gigabyte in den Share, einmal über Z: und einmal über den alten SMB-Pfad, und die Uhr entscheidet. Unter Linux geht das in einer Zeile, danach die Datei wieder löschen:

dd if=/dev/zero of=/mnt/daten/test.bin bs=1M count=1024 conv=fsync status=progress
rm /mnt/daten/test.bin

Wo es im Forum immer wieder hakt

„Ich habe alles eingetragen und sehe nichts.“ Der häufigste Thread, zuletzt von JKunraid mit einer Pop!_OS-VM. Antwort von SimonF: Der Share muss in der VM eingehängt werden, Schritt 2 und 3 oben. Die Vorlage öffnet das Fenster, sie geht nicht hindurch.

„The service did not start in a timely fashion.“ Die Meldung des Windows-Dienstes, wenn WinFsp fehlt. TexasUnraid hat es im Forum gelöst, und er schreibt dazu, dass der Zusammenhang nicht offensichtlich ist. Reihenfolge: erst WinFsp, dann der Dienst.

Zweiter Share, aber nur ein Z:. Der Windows-Dienst hängt genau einen Share ein; einen zweiten Buchstaben vergibt er nicht, das hat KptnKMan lange gesucht. Der Weg dafür steht im virtio-win-Wiki in den Quellen: den Dienst abschalten und jeden Share einzeln über den WinFsp-Launcher mit eigenem Buchstaben starten. Das ist ein Abend für sich; für einen Share brauchst du ihn nicht.

„Errno 95, Operation not supported.“ Iron_Forge bekam den Fehler, als yt-dlp in den Share schreiben wollte. Manche Programme sperren Dateien auf eine Art, die durch das Fenster nicht passt. Für genau diesen Ordner bleibt dann SMB, und das ist kein Rückschritt, sondern das richtige Werkzeug für den einen Fall.

Eingefrorene Windows-VM nach Stunden. Unraid älter als 6.12.5 oder Treiber älter als 0.1.248, siehe Voraussetzungen. Erst aktualisieren, dann weitersuchen.

Linux ja, Windows mit Vorbehalt

Für eine Linux-VM würde ich SMB heute nicht mehr anfassen. Zwei Befehle, eine fstab-Zeile, kein Benutzer, kein Passwort, und der Share verhält sich wie ein Ordner auf der eigenen Platte. Das ist der Unterschied zwischen Post und Flur, und du kannst ihn mit dem dd-Befehl oben selbst nachmessen.

Bei Windows lautet mein Urteil: einrichten, messen, und SMB erst abschalten, wenn dein eigener Test es hergibt. Der Weg ist länger, die Forumsgeschichte holpriger, und die Sache mit dem einen Laufwerksbuchstaben ist eine Grenze, die du kennen solltest. Dass es seit 6.12.5 stabil läuft, glaube ich mackid1993, der es ein Jahr lang nachverfolgt hat. Was es bei dir bringt, weißt nur du.

Hängt deine VM den Share schon per VirtioFS ein, oder bist du bei SMB geblieben, weil es einfach lief? Und falls Windows: Hat der Dienst bei dir auf Anhieb gestartet, oder hast du auch erst nach WinFsp gesucht? Schreib's in die Kommentare, ich lese jede Antwort.

Solche Handgriffe sammle ich sonntags im Newsletter, mit den Beiträgen der Woche in einer Mail; eintragen kannst du dich unten auf der Seite, austragen jederzeit mit einem Klick.

Quellen