> ## Content Index
> Fetch the complete content index at: https://sakis.tech/llms.txt
> Use this file to discover other available public pages before exploring further.

# Unraid-Share in der VM mounten: VirtioFS statt SMB
- URL: https://sakis.tech/unraid-share-vm-mounten/
- Published: 2026-09-05T03:28:02.000Z
- Updated: 2026-09-05T03:28:02.000Z
- Description: Die VM liegt auf demselben Server wie die Daten, und trotzdem geht alles über SMB? Mit VirtioFS hängt der Unraid-Share direkt in der Linux- oder Windows-VM, ohne Netzwerk und Passwort. Samt dem Rechte-Haken, den fast jeder erwischt.
- Author: Sakis
- Tags: homelab, Unraid

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](https://sakis.tech/content/images/2026/09/grafik-3.png)

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:

```bash
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.

```bash
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:

```bash
sudo nano /etc/fstab
```

Ganz unten diese Zeile anhängen:

```text
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:

```bash
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](https://winfsp.dev/?ref=sakis.tech) 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.

```bash
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:

```bash
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:

```text
daten  /mnt/daten  virtiofs  ro,relatime  0  0
```

```bash
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.

sakis@homelab:\~$ echo "bleib neugierig — und mach backups" 

## Quellen

- [Unraid WebGUI (GitHub): VM-Formular mit den Feldern Unraid Share Mode, Unraid Share, Unraid Mount Tag](https://github.com/unraid/webgui/blob/master/emhttp/plugins/dynamix.vm.manager/templates/Custom.form.php?ref=sakis.tech)
- [Unraid-Forum: VirtioFS Support Page (Voraussetzungen, Windows, bekannte Probleme)](https://forums.unraid.net/topic/129352-virtiofs-support-page/?ref=sakis.tech)
- [Unraid-Dokumentation: Release Notes 7.3.2](https://docs.unraid.net/unraid-os/release-notes/7.3.2/?ref=sakis.tech)
- [virtio-fs: HOWTO für Linux-Gäste (mount -t virtiofs, Kernel ab 5.4)](https://virtio-fs.gitlab.io/howto-qemu.html?ref=sakis.tech)
- [virtio-fs: HOWTO für Windows-Gäste (WinFsp, Treiber, VirtioFsSvc)](https://virtio-fs.gitlab.io/howto-windows.html?ref=sakis.tech)
- [virtio-win Knowledge Base: Virtiofs, mehrere Shares über den WinFsp-Launcher](https://virtio-win.github.io/Knowledge-Base/Virtiofs:-Shared-file-system.html?ref=sakis.tech)
- [QEMU-Wiki: 9p-Setup (Mount-Optionen trans=virtio, version=9p2000.L)](https://wiki.qemu.org/Documentation/9psetup?ref=sakis.tech)
- [Unraid-Forum: Permissions on files created in VM](https://forums.unraid.net/topic/76739-permissions-on-files-created-in-vm/?ref=sakis.tech)