WSL: /mnt/c nach Windows-Update nicht erreichbar – was tun?

WSL startet, aber Dein Windows-Projektordner ist plötzlich nicht mehr erreichbar? Wenn /mnt/c fehlt oder keine Dateien liefert, musst Du nicht sofort Ubuntu neu installieren. Prüfe zuerst, ob die Laufwerkseinbindung fehlt, ein anderer Mountpfad konfiguriert ist oder nur einzelne Ordner den Zugriff verweigern.

Recherchestand: 22. September 2026. Diese Anleitung konzentriert sich auf Windows 11 mit WSL 2. Der aktuelle Update-Sonderfall und die allgemeinen Diagnosewege sind getrennt beschrieben.

September 2026: bestätigter Fehler bei Windows-Hostordnern

Microsoft dokumentiert nach dem Sicherheitsupdate vom 8. September 2026 einen Fehler bei Hostordnern in HCS-verwalteten Linux-VMs. HCS steht für Host Compute Service. Die virtuelle Maschine startet, aber über Plan9 bereitgestellte Windows-Ordner fehlen oder sind nicht zugänglich. Microsoft nennt WSL und Claude Cowork als betroffene Anwendungen. Normale Hyper-V-VMs ohne diese Plan9-Funktion sind nicht betroffen. Die Meldung wurde am 11. September eröffnet; seit 14. September gilt das Problem als behoben. Ein pauschaler Fehlercode oder eine gemeinsame Event-ID wird dafür nicht genannt. Quelle: Windows Release Health.

Fehlendes /mnt/c allein beweist diesen Fehler nicht. Der zeitliche Zusammenhang und der Windows-Patchstand sind entscheidend.

1. Windows-Version und WSL prüfen

Öffne PowerShell im betroffenen Windows-Benutzerkonto. Für diese Abfragen sind normalerweise keine Administratorrechte erforderlich:

winver
wsl --version
wsl --status
wsl --list --verbose

winver zeigt Windows-Version und Betriebssystembuild. Die WSL-Abfragen liefern Komponentenstand, Standardkonfiguration und installierte Distributionen. In der Distributionsliste zeigt die Spalte VERSION, ob WSL 1 oder WSL 2 verwendet wird. Das ist nicht dieselbe Versionsangabe wie bei wsl --version. Falls der letztgenannte Schalter nicht erkannt wird, notiere diese Meldung ebenfalls. Quelle: Microsoft: WSL-Befehle.

Öffne zusätzlich Einstellungen → Windows Update → Updateverlauf. Notiere, welches Update unmittelbar vor dem ersten Ausfall installiert wurde.

2. Beim September-Fehler zuerst Windows aktualisieren

Für Windows 11 24H2 und 25H2 liefert KB5129195 vom 14. September 2026 die Korrektur. Das kumulative Sonderupdate führt zu diesen Builds:

• Windows 11 24H2: 26100.9457
• Windows 11 25H2: 26200.9457

Installiere über Windows Update das passende aktuelle kumulative Update und starte Windows neu. Auch spätere Updates enthalten die Korrektur. wsl --update aktualisiert dagegen WSL selbst und ersetzt diesen Windows-Patch nicht. Bei einer manuellen Installation müssen Architektur und gegebenenfalls erforderliche Checkpoint-Pakete passen; folge dafür den Installationshinweisen in Microsofts KB5129195.

Auf verwalteten Geräten: Die Freigabe durch die IT beachten. Wurde der Fehler vorübergehend per Gruppenrichtlinie umgangen, verlangt Microsoft, die betreffende Richtlinie wieder zu aktivieren, das Sonderupdate zu installieren und neu zu starten. Keine unbeteiligten Richtlinien verändern. Quelle: Microsofts Lösungshinweis.

3. Ist /mnt/c wirklich eingehängt?

Führe in der betroffenen Linux-Distribution diese lesenden Prüfungen aus:

ls -ld /mnt/c
findmnt --mountpoint /mnt/c
ls /mnt/c/Windows

findmnt zeigt die vorhandenen Dateisystemeinbindungen. Mit --mountpoint prüfst Du gezielt diesen Mountpunkt. Ein existierender Ordner allein bedeutet nicht, dass dort das Windows-Laufwerk eingebunden ist. Liefert die Prüfung keinen Treffer, untersuche den Mountpfad im nächsten Abschnitt. Fehlt findmnt in Deiner Distribution, kannst Du mit mount zunächst die vorhandenen Einbindungen auflisten. Referenz: findmnt-Dokumentation.

Funktioniert /mnt/c/Windows, aber Dein Projektordner nicht, ist ein vollständiger Ausfall der Laufwerkseinbindung weniger wahrscheinlich. Prüfe dann den genauen Pfad und die Zugriffsrechte.

4. Automount-Konfiguration kontrollieren

Die Datei /etc/wsl.conf steuert die jeweilige Distribution. Prüfe ihren Inhalt, falls sie existiert:

cat /etc/wsl.conf

Eine fehlende Datei ist nicht automatisch ein Fehler: WSL verwendet dann die Standardwerte. Im Abschnitt [automount] verhindert enabled=false die automatische Einbindung fester Windows-Laufwerke. Ein abweichender root-Wert verändert den Pfad: Bei root=/windir/ liegt Laufwerk C unter /windir/c.

Wenn die Abweichung unbeabsichtigt ist, sichere die vorhandene Datei und passe mit Linux-Administratorrechten nur den betreffenden Abschnitt an. Die Standardkonfiguration entspricht:

[automount]
enabled=true
root=/mnt/

Nicht die gesamte Datei ersetzen: Andere Abschnitte können benötigt werden. Auch Einträge in /etc/fstab können Laufwerke einbinden. Quelle: Microsoft: Automount und wsl.conf.

Damit Änderungen greifen, speichere offene Arbeiten und stoppe laufende Linux-Dienste geordnet. Führe anschließend in PowerShell aus:

wsl --shutdown

Achtung: Das beendet alle laufenden WSL-Distributionen und die WSL-2-VM unmittelbar; auch darauf aufbauende Entwicklungswerkzeuge können unterbrochen werden. Starte danach die betroffene Distribution erneut. Quelle: Microsoft: WSL herunterfahren.

5. „Permission denied“ ist ein anderer Diagnosezweig

Ist das Laufwerk eingebunden und nur ein bestimmter Ordner unzugänglich, teste denselben Ordner im Windows-Explorer mit Deinem normalen Benutzerkonto. Windows-Zugriffsrechte gelten auch beim Zugriff aus WSL. Linux-Metadaten und Mountoptionen können zusätzlich beeinflussen, welche Rechte angezeigt werden.

Ein pauschales chmod -R 777 behebt keine fehlenden Windows-Berechtigungen und kann Rechte unnötig aufweiten. Auch Linux-root erhält dadurch nicht automatisch zusätzliche Windows-Rechte. Auf Firmenrechnern sollte die IT die erforderlichen Berechtigungen gezielt prüfen. Quelle: Microsoft: Dateiberechtigungen in WSL.

6. Erfolg prüfen und verbleibende Fehler eingrenzen

Wiederhole nach Neustart oder Konfigurationsänderung die Mountprüfung und öffne eine vorhandene, unkritische Datei im ursprünglich betroffenen Projektordner. Teste anschließend genau die Anwendung, die zuvor gescheitert ist. Ein wieder sichtbares Laufwerk allein bestätigt noch nicht, dass der gesamte Arbeitsablauf funktioniert.

Bleibt der Fehler bestehen, sammle Windows-Build, Updateverlauf, WSL-Version, Distributionsname, den vollständigen Fehlertext und die relevanten Konfigurationszeilen. Halte fest, ob alle Windows-Laufwerke oder nur ein Pfad betroffen sind. Schwärze Benutzernamen und interne Projektpfade vor einer öffentlichen Weitergabe.

Nutze danach Microsofts WSL-Troubleshooting für die gezielte Eskalation. Vermeide Neuinstallation, Zurücksetzen oder das Abmelden einer Distribution als ersten Versuch: wsl --unregister entfernt die zugehörigen Distributionsdaten dauerhaft.

Fazit

Bei plötzlich fehlenden Windows-Ordnern in WSL zuerst Patchstand und tatsächliche Einbindung prüfen. Danach helfen Automount-Konfiguration und Berechtigungsprüfung, die Ursache einzugrenzen. So lässt sich der bestätigte September-Sonderfall von lokalen Einstellungen unterscheiden, ohne vorschnell die Linux-Umgebung zu löschen.