Freigeben über

Problembehandlung beim Windows-Subsystem für Linux

Wir haben einige gängige Problembehandlungsszenarien behandelt, die mit WSL im Zusammenhang stehen. Bitte sollten Sie jedoch auch die Im WSL-Produktrepo auf GitHub abgelegten Probleme durchsuchen.

Einreichung eines Problems, eines Fehlerberichts oder einer Funktionsanforderung

Das WSL-Produkt-Repository ermöglicht es Ihnen, Folgendes zu tun:

  • Durchsuchen Sie vorhandene Probleme, um festzustellen, ob mit dem von Ihnen erlebten Problem bereits welche verbunden sind.

    Beachten Sie, dass Sie in der Suchleiste "state:open" entfernen können, um Probleme einzuschließen, die in Ihrer Suche bereits behoben wurden.

    Bitte ziehen Sie in Betracht, offene Probleme zu kommentieren oder einen Daumen hoch zu geben, bei denen Sie Interesse daran haben, sie als Priorität voranzutreiben.

  • Ein neues Anliegen einreichen. Wenn Sie ein Problem mit WSL gefunden haben und kein vorhandenes Problem auftritt, können Sie die grüne Schaltfläche "New issue" auswählen und dann "WSL - Bug Report" auswählen.

    Sie müssen die folgenden Informationen angeben:

    • Problemtitel
    • Windows-Version: Führen Sie die Ausführung aus cmd.exe /c ver , um den Build von Windows zu erhalten, auf dem Sie sich befinden.
    • WSL-Version: Wenn Sie das Windows-Subsystem für Linux aus dem Microsoft Store ausführen, führen Sie bitte aus wsl.exe -v.
    • Verwenden Sie WSL 1 oder WSL 2: Teilen Sie uns mit, ob sich das Problem auf WSL 2 und/oder WSL 1 befindet. Sie können feststellen, indem Sie folgendes ausführen wsl.exe -l -v.
    • Kernelversion: Bitte teilen Sie uns mit, welche Version des linux-Kernels Sie verwenden oder ob Sie einen benutzerdefinierten Kernel verwenden. Sie können ausführen wsl.exe --status , ob dieser Befehl für Sie verfügbar ist, oder indem Sie in Ihrer Distros ausgeführt cat /proc/version werden.
    • Distro Version: Bitte teilen Sie uns mit, welche Distros Sie verwenden (falls zutreffend). Sie können nach Möglichkeit zusätzliche Informationen über die Version erhalten, z. B. auf Debian / Ubuntu. run lsb_release -r
    • Andere Software: Wenn Sie einen Fehler melden, der die Interaktion von WSL mit anderen Anwendungen umfasst, teilen Sie uns bitte mit. Welche Anwendungen? Welche Versionen?
    • Repro Steps: Bitte führen Sie die Schritte aus, um Ihren Fehler zu reproduzieren.
    • Erwartetes Verhalten: Was erwarten Sie? Fügen Sie relevante Beispiele oder Dokumentationslinks ein.
    • Tatsächliches Verhalten: Was ist stattdessen passiert?
    • Diagnoseprotokolle: Geben Sie bei Bedarf zusätzliche Diagnosen an. In den Anleitungen finden Sie Informationen zum Sammeln von Feedback-Hub-Protokollen, Netzwerkprotokollen und mehr.

    Weitere Informationen finden Sie unter "Beitragen zu WSL".

  • Geben Sie eine Featureanforderung ein, indem Sie die grüne Schaltfläche "New issue" und dann "Feature request" auswählen.

    Sie müssen einige Fragen beantworten, die Ihre Anfrage beschreiben.

Sie können außerdem:

  • Ein Dokumentationsproblem melden mithilfe des Dokumentationsrepo für WSL. Informationen zum Mitwirken an den WSL-Dokumenten finden Sie im Microsoft Docs-Mitwirkendenhandbuch.
  • Melden Sie ein Problem mit Windows Terminal im Windows Terminal-Produktrepo, wenn Ihr Problem mit dem Windows Terminal, der Windows-Konsole oder der Befehlszeilenoberfläche zusammenhängt.

Probleme bei der Installation

  • Fehler bei der Installation 0x80070003

    • Das Windows-Subsystem für Linux wird nur auf Ihrem Systemlaufwerk ausgeführt (in der Regel ist dies Ihr C: Laufwerk). Stellen Sie sicher, dass Verteilungen auf Ihrem Systemlaufwerk gespeichert sind:
    • Unter Windows 10 öffnen Sie "Einstellungen -> ->Speicher ->Weitere Speichereinstellungen": Ändern, wo neue Inhalte gespeichert werden, Bild der Systemeinstellungen zum Installieren von Apps auf C: Laufwerk (Windows 10)
    • Unter Windows 11 öffnen Sie Einstellungen - > - Speicher - > - Wo neue Inhalte gespeichert werden>

  • WslRegisterDistribution schlug mit dem Fehler 0x8007019e fehl

    • Die optionale Komponente des Windows-Subsystems für Linux ist nicht aktiviert:
    • Öffnen Sie die Systemsteuerung –>Programme und Features –>Windows-Feature aktivieren oder deaktivieren –> Überprüfen Sie das Windows-Subsystem für Linux, oder verwenden Sie das unter Schritt 1 erwähnte PowerShell-Cmdlet.

  • Fehler bei der Installation 0x80070003 oder Fehler 0x80370102

    • Stellen Sie sicher, dass die Virtualisierung innerhalb des BIOS Ihres Computers aktiviert ist. Die Anweisungen dazu variieren von Computer zu Computer und werden wahrscheinlich unter CPU-bezogenen Optionen stehen.
    • WSL2 erfordert, dass Ihre CPU das Feature Second Level Address Translation (SLAT) unterstützt, das in Intel Nehalem-Prozessoren (Intel Core 1. Generation) und AMD Opteron eingeführt wurde. Ältere CPUs (z. B. intel Core 2 Duo) können WSL2 nicht ausführen, auch wenn die Virtual Machine Platform erfolgreich installiert ist.

  • Fehler beim Versuch, ein Upgrade durchzuführen, Ungültige Befehlszeilenoption: wsl --set-version Ubuntu 2

    • Stellen Sie sicher, dass das Windows-Subsystem für Linux aktiviert ist und Sie Windows Build Version 18362 oder höher verwenden. Um WSL zu aktivieren, führen Sie diesen Befehl in einer PowerShell-Eingabeaufforderung mit Administratorrechten aus:

      Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

  • Der angeforderte Vorgang konnte aufgrund einer Systembeschränkung für virtuelle Datenträger nicht abgeschlossen werden. Virtuelle Festplattendateien müssen nicht komprimiert und unverschlüsselt sein und dürfen nicht sparsam sein.

    • Deaktivieren Sie "Inhalt komprimieren" (sowie "Inhalt verschlüsseln", wenn dies aktiviert ist), indem Sie den Profilordner für Ihre Linux-Verteilung öffnen. Er sollte sich in einem Ordner in Ihrem Windows-Dateisystem befinden, z. B.: %LocalAppData%\Packages\CanonicalGroupLimited...
    • In diesem Linux-Distro-Profil sollte ein LocalState-Ordner vorhanden sein. Klicken Sie mit der rechten Maustaste auf diesen Ordner, um ein Menü mit Optionen anzuzeigen. Wählen Sie "Eigenschaften>erweitert " aus, und stellen Sie dann sicher, dass die Kontrollkästchen "Inhalte komprimieren, um Speicherplatz zu sparen" und "Inhalte zum Sichern von Daten verschlüsseln" nicht ausgewählt sind (nicht aktiviert). Wenn Sie gefragt werden, ob dies nur auf den aktuellen Ordner oder auf alle Unterordner und Dateien angewendet werden soll, wählen Sie "nur diesen Ordner" aus, da Sie nur das Komprimierungskennzeichnung löschen. Danach sollte der wsl --set-version Befehl funktionieren.

    Screenshot der Eigenschaften-Einstellungen der WSL-Distro

    Hinweis

    In meinem Fall wurde der LocalState-Ordner für meine Ubuntu 18.04-Verteilung unter C:\Users\<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc

    Überprüfen Sie den WSL Docs GitHub-Thread #4103, in dem dieses Problem für aktualisierte Informationen verfolgt wird.

  • Der Begriff "wsl" wird nicht als Name eines Cmdlets, einer Funktion, einer Skriptdatei oder eines operierbaren Programms erkannt.

  • Fehler: Das Windows-Subsystem für Linux verfügt über keine installierten Verteilungen.

    • Wenn diese Fehlermeldung angezeigt wird, nachdem Sie WSL-Verteilungen bereits installiert haben:
    1. Führen Sie die Verteilung mindestens einmal aus, bevor Sie sie über die Befehlszeile aufrufen.
    2. Überprüfen Sie, ob Sie möglicherweise separate Benutzerkonten ausführen. Wenn Sie Ihr primäres Benutzerkonto mit erhöhten Berechtigungen (im Administratormodus) ausführen, sollte dieser Fehler nicht auftreten. Sie sollten jedoch sicherstellen, dass Sie nicht versehentlich das integrierte Administratorkonto ausführen, das im Lieferumfang von Windows vorhanden ist. Dies ist ein separates Benutzerkonto und zeigt standardmäßig keine installierten WSL-Verteilungen an. Weitere Informationen finden Sie unter Aktivieren und Deaktivieren des integrierten Administratorkontos.
    3. Die ausführbare WSL-Datei wird nur im systemeigenen Systemverzeichnis installiert. Wenn Sie einen 32-Bit-Prozess unter 64-Bit-Windows (oder arm64, einer nicht nativen Kombination) ausführen, sieht der gehostete nicht native Prozess tatsächlich einen anderen System32-Ordner. (Der 32-Bit-Prozess, der auf x64 Windows angezeigt wird, wird auf dem Datenträger unter %SystemRoot%\SysWOW64 gespeichert.) Sie können über einen gehosteten Prozess über einen gehosteten Prozess auf das systemeigene System32 zugreifen, indem Sie im virtuellen Ordner suchen: \Windows\sysnative. Es wird tatsächlich nicht auf dem Datenträger vorhanden sein, aber der Pfadresolver des Dateisystems wird es trotzdem finden.

  • Fehler: Dieses Update gilt nur für Computer mit dem Windows-Subsystem für Linux.

    • Um das MSI-Paket für das Linux-Kernelupdate zu installieren, ist WSL erforderlich und sollte zuerst aktiviert werden. Wenn der Fehler auftritt, wird die Meldung angezeigt: Dieses Update gilt nur für Computer mit dem Windows-Subsystem für Linux.
    • Es gibt drei mögliche Gründe, warum diese Meldung angezeigt wird:

    1. Sie befinden sich noch in der alten Version von Windows, die WSL 2 nicht unterstützt. Siehe Schritt 2 – Überprüfen der Anforderungen für die Ausführung von WSL 2.

    2. WSL ist nicht aktiviert. Sie müssen zu Schritt 1 zurückkehren und sicherstellen, dass das optionale WSL-Feature auf Ihrem Computer aktiviert ist.

    3. Nachdem Sie WSL aktiviert haben, ist ein Neustart erforderlich, damit er wirksam wird, starten Sie den Computer neu, und versuchen Sie es erneut.

  • Fehler: WSL 2 erfordert eine Aktualisierung der Kernelkomponente. Weitere Informationen finden Sie in Schritt 4

    • Wenn das Linux-Kernelpaket im %SystemRoot%\system32\lxss\tools Ordner fehlt, tritt dieser Fehler auf. Beheben Sie es, indem Sie das MSI-Paket des Linux-Kernelupdates in Schritt 4 dieser Installationsanweisungen installieren. Möglicherweise müssen Sie die MSI-Datei aus "Programme hinzufügen oder entfernen" deinstallieren und erneut installieren.

Häufig auftretende Probleme

Ich bin unter Windows 10, Version 1903, und ich sehe immer noch keine Optionen für WSL 2

Dies liegt wahrscheinlich daran, dass Ihr Computer den Backport für WSL 2 noch nicht übernommen hat. Am einfachsten können Sie dies beheben, indem Sie zu Den Windows-Einstellungen wechseln und auf "Nach Updates suchen" klicken, um die neuesten Updates auf Ihrem System zu installieren. Sehen Sie sich die vollständigen Anweisungen zum Anwenden des Backports an.

Wenn Sie auf "Nach Updates suchen" klicken und das Update trotzdem nicht erhalten, können Sie KB-KB4566116 manuell installieren.

Fehler: 0x1bc bei wsl --set-default-version 2

Dies kann passieren, wenn die Einstellung "Anzeigesprache" oder "Systemgebietsschema" nicht englisch ist.

PS C:\> wsl.exe --set-default-version 2
Error: 0x1bc
For information on key differences with WSL 2 please visit https://aka.ms/wsl2

Der tatsächliche Fehler 0x1bc lautet: WSL 2 erfordert eine Aktualisierung der Kernelkomponente. Weitere Informationen finden Sie unter https://aka.ms/wsl2kernel

Weitere Informationen finden Sie unter Problem Nr. 5749

Auf WSL-Dateien von Windows kann nicht zugegriffen werden.

Ein 9p-Protokolldateiserver stellt den Dienst auf der Linux-Seite bereit, damit Windows auf das Linux-Dateisystem zugreifen kann. Wenn Sie nicht auf WSL unter \\wsl$ Windows zugreifen können, liegt dies daran, dass 9P nicht ordnungsgemäß gestartet wurde.

Um dies zu überprüfen, können Sie die Startprotokolle mithilfe von: dmesg | grep 9p überprüfen, und dies zeigt alle Fehler an. Eine erfolgreiche Ausgabe sieht wie folgt aus:

[    0.363323] 9p: Installing v9fs 9p2000 file system support
[    0.363336] FS-Cache: Netfs '9p' registered for caching
[    0.398989] 9pnet: Installing 9P2000 support

Weitere Informationen zu diesem Thema finden Sie in der Ausgabe Nr. 5307 .

Die WSL 2-Verteilung kann nicht gestartet werden, und nur "WSL 2" wird in der Ausgabe angezeigt.

Wenn Ihre Anzeigesprache nicht Englisch ist, ist es möglich, dass eine abgeschnittene Version eines Fehlertexts angezeigt wird.

PS C:\> wsl.exe
WSL 2

Um dieses Problem zu beheben, lesen Sie Schritt 4 , und installieren Sie den Kernel manuell, indem Sie den Anweisungen auf dieser Dokumentseite folgen.

command not found beim Ausführen von Windows .exe unter Linux

Benutzer können Windows-ausführbare Dateien wie notepad.exe direkt unter Linux ausführen. Manchmal können Sie wie unten auf "Befehl nicht gefunden" klicken:

$ notepad.exe
-bash: notepad.exe: command not found

Wenn in Ihrem $PATH keine Win32-Pfade vorhanden sind, wird die Interop .exenicht finden. Sie können es überprüfen, indem Sie echo $PATH unter Linux ausführen. Es wird erwartet, dass ein Win32-Pfad (z. B /mnt/c/Windows. ) in der Ausgabe angezeigt wird. Wenn keine Windows-Pfade angezeigt werden, wird Ihr PATH wahrscheinlich von Ihrer Linux-Shell überschrieben.

Hier ist ein Beispiel, das /etc/profile auf Debian zum Problem beigetragen hat:

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi

Der richtige Weg auf Debian besteht darin, die oben genannten Zeilen zu entfernen. Sie können auch $PATH während der Zuweisung wie unten anfügen, aber dies führt zu einigen anderen Problemen mit WSL und VSCode..

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:$PATH"
fi

Weitere Informationen finden Sie unter Problem Nr. 5296 und Problem Nr. 5779.

"Fehler: 0x80370102 Der virtuelle Computer konnte nicht gestartet werden, da ein erforderliches Feature nicht installiert ist."

Aktivieren Sie das Windows-Feature für virtuelle Computerplattform, und stellen Sie sicher, dass die Virtualisierung im BIOS aktiviert ist.

  1. Überprüfen der Hyper-V Systemanforderungen

  2. Wenn Es sich bei Ihrem Computer um einen virtuellen Computer handelt, aktivieren Sie die geschachtelte Virtualisierung manuell. Starten Sie PowerShell mit Administrator, und führen Sie den folgenden Befehl aus, und ersetzen <VMName> Sie den Namen des virtuellen Computers auf Ihrem Hostsystem (Sie finden den Namen in Ihrem Hyper-V-Manager):

    Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

  3. Befolgen Sie die Richtlinien des Herstellers Ihres PCs, um die Virtualisierung zu aktivieren. Im Allgemeinen kann dies die Verwendung des System-BIOS umfassen, um sicherzustellen, dass diese Features auf Ihrer CPU aktiviert sind. Anweisungen für diesen Vorgang können von Computer zu Computer variieren, siehe Aktivieren der Virtualisierung unter Windows.

  4. Starten Sie Den Computer neu, nachdem Sie die optionale Komponentefür virtuelle Computerplattform aktiviert haben.

  5. Stellen Sie sicher, dass der Hypervisorstart in Ihrer Startkonfiguration aktiviert ist. Sie können dies überprüfen, indem Sie PowerShell mit erhöhten Rechten ausführen:

    bcdedit /enum | findstr -i hypervisorlaunchtype

    Wenn angezeigt wird hypervisorlaunchtype Off, ist der Hypervisor deaktiviert. Um das Skript in einer PowerShell mit erhöhten Rechten auszuführen:

    bcdedit /set hypervisorlaunchtype Auto

  6. Wenn Sie Außerdem Hypervisoren von Drittanbietern (z. B. VMware oder VirtualBox) installiert haben, stellen Sie sicher, dass Sie diese auf den neuesten Versionen haben, die HyperV (VMware 15.5.5+ und VirtualBox 6+) unterstützen können oder deaktiviert sind.

  7. Wenn Sie diesen Fehler auf einem virtuellen Azure-Computer erhalten, überprüfen Sie, ob der vertrauenswürdige Start deaktiviert ist. Geschachtelte Virtualisierung wird auf virtuellen Azure-Computern mit vertrauenswürdigem Start nicht unterstützt.

Erfahren Sie mehr darüber, wie Sie geschachtelte Virtualisierung konfigurieren , wenn sie Hyper-V auf einem virtuellen Computer ausführen.

WSL verfügt über keine Netzwerkverbindung auf meinem Arbeitscomputer oder in einer Unternehmensumgebung.

Geschäfts- oder Unternehmensumgebungen verfügen möglicherweise über Windows Defender Firewall-Einstellungen, die so konfiguriert sind , dass nicht autorisierter Netzwerkdatenverkehr blockiert wird. Wenn das Zusammenführen lokaler Regeln auf "Nein" festgelegt ist, funktioniert das WSL-Netzwerk standardmäßig nicht, und Ihr Administrator muss eine Firewallregel hinzufügen, um sie zuzulassen.

Sie können die Einstellung für das Zusammenführen lokaler Regeln bestätigen, indem Sie die folgenden Schritte ausführen:

Screenshot der Windows-Firewalleinstellungen

  1. Öffnen Sie "Windows Defender Firewall mit erweiterter Sicherheit" (dies unterscheidet sich von "Windows Defender Firewall" in der Systemsteuerung)
  2. Klicken Sie mit der rechten Maustaste auf die Registerkarte "Windows Defender Firewall mit erweiterter Sicherheit auf dem lokalen Computer".
  3. Wählen Sie "Eigenschaften" aus.
  4. Wählen Sie die Registerkarte "Öffentliches Profil" im neuen Fenster aus, das geöffnet wird.
  5. Wählen Sie im Abschnitt "Einstellungen" die Option "Anpassen" aus.
  6. Überprüfen Sie das Fenster "Einstellungen für das öffentliche Profil anpassen", um festzustellen, ob "Regelzusammenführung" auf "Nein" festgelegt ist. Dadurch wird der Zugriff auf WSL blockiert.

Anweisungen zum Ändern dieser Firewalleinstellung finden Sie unter "Konfigurieren Hyper-V Firewall".

WSL hat keine Netzwerkverbindung, wenn IPv6 deaktiviert wird

Wenn IPv6 mit dem Registrierungswert HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters (REG_DWORD) DisabledComponentsdeaktiviert ist, kann die WSL-Netzwerkkonnektivität fehlschlagen. Siehe Anleitungen zum Konfigurieren von IPv6 in Windows für erweiterte Benutzer.

Wenn IPv6 im Hostsystem deaktiviert werden muss, empfehlen wir die Verwendung von PowerShell, indem sie die IPv6-Protokollbindungen direkt entfernen. Beispiel: Disable-NetAdapterBinding -Name "<MyAdapter>" -ComponentID ms_tcpip[6].

WSL verfügt über keine Netzwerkkonnektivität, sobald eine Verbindung mit einem VPN hergestellt wurde.

Wenn bash nach der Verbindung mit einem VPN unter Windows die Netzwerkverbindung verliert, probieren Sie diese Problemumgehung innerhalb von bash aus. Mit dieser Problemumgehung können Sie die DNS-Auflösung manuell über /etc/resolv.conf überschreiben.

  1. Notieren Sie sich den DNS-Server des VPN von folgendem:

    ipconfig.exe /all

  2. Erstellen sie eine Kopie der vorhandenen resolv.conf:

    sudo cp /etc/resolv.conf /etc/resolv.conf.bak

  3. Verknüpfung des aktuellen resolv.confAufhebens:

    sudo unlink /etc/resolv.conf

  4. Laufen:

    sudo mv /etc/resolv.conf.bak /etc/resolv.conf

  5. Bearbeiten Sie /etc/wsl.conf und fügen Sie den Inhalt der Datei hinzu. (Weitere Informationen zu diesem Setup finden Sie in der Konfiguration für erweiterte Einstellungen)

    [network]
generateResolvConf=false

  6. Öffnen /etc/resolv.conf und

    1. Löschen Sie die erste Zeile aus der Datei, die einen Kommentar enthält, der die automatische Generierung beschreibt.
    2. Fügen Sie den DNS-Eintrag von (1) oben als den ersten Eintrag in der Liste der DNS-Server hinzu.
    3. Schließen Sie die -Datei.

Nachdem Sie die VPN-Verbindung getrennt haben, müssen Sie die Änderungen /etc/resolv.confwiederherstellen. Gehen Sie dazu wie folgt vor:

sudo mv /etc/resolv.conf /etc/resolv.conf.bak
sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf

Probleme mit dem Global Secure Access Client in Verbindung mit WSL

Der globale Secure Access-Client (/entra/global-secure-access/how-to-install-windows-client) kann sich auf die WSL-Konnektivität auswirken, da es über ein Feature verfügt, um eine temporäre Adresse zurückzugeben, wenn ein Name aufgelöst wird. Anschließend wird die Adresse an die tatsächliche Adresse ausgetauscht, wenn eine Netzwerkverbindung hergestellt wird. Dies kann WSL unterbrechen, da der WSL-Datenverkehr unterhalb eines Großteils der GSA-Client-Hooks weitergeleitet wird.

Es wird empfohlen, DNS-Tunneling (dnsTunneling=false) zu deaktivieren oder den gespiegelten Modus (networkingMode=nat) zu deaktivieren.

Cisco Anyconnect VPN-Probleme mit WSL im NAT-Modus

Das Cisco AnyConnect-VPN ändert Routen auf eine Weise, die verhindert, dass NAT funktioniert. Es gibt eine problemumgehung speziell für WSL 2: Siehe Cisco AnyConnect Secure Mobility Client Administrator Guide, Release 4.10 – Problembehandlung bei AnyConnect.

WSL-Konnektivitätsprobleme mit VPNs, wenn der Spiegelungsnetzwerkmodus aktiviert ist

Der Gespiegelte Netzwerkmodus ist derzeit eine experimentelle Einstellung in der WSL-Konfiguration. Die herkömmliche NAT-Netzwerkarchitektur von WSL kann auf einen völlig neuen Netzwerkmodus aktualisiert werden, der als "Gespiegelter Netzwerkmodus" bezeichnet wird. Wenn das networkingMode experimentelle mirrored festgelegt ist, werden die unter Windows vorhandenen Netzwerkschnittstellen in Linux gespiegelt, um die Kompatibilität zu verbessern. Weitere Informationen finden Sie im Befehlszeilenblog: WSL-Update vom September 2023.

Einige VPNs wurden getestet und bestätigt, dass sie nicht mit WSL kompatibel sind, darunter:

  • "Bitdefender" Version 26.0.2.1
  • "OpenVPN" Version 2.6.501
  • "Mcafee Safe Connect" Version 2.16.1.124

Überlegungen bei der Verwendung von autoProxy für das HttpProxy-Mirroring in WSL

HTTP/S-Proxyspiegelung kann mithilfe der autoProxy Einstellung im experimentellen Abschnitt der WSL-Konfigurationsdatei konfiguriert werden. Beachten Sie beim Anwenden dieser Einstellung die folgenden Überlegungen:

  • PAC-Proxy: WSL konfiguriert die Einstellung unter Linux durch Festlegen der WSL_PAC_URL Umgebungsvariable. Linux unterstützt standardmäßig keine PAC-Proxys.
  • Interaktionen mit WSLENV: Benutzerdefinierte Umgebungsvariablen haben Vorrang vor den von diesem Feature angegebenen Variablen.

Wenn diese Option aktiviert ist, gelten die folgenden Proxyeinstellungen für Ihre Linux-Distributionen:

  • Die Linux-Umgebungsvariable HTTP_PROXY wird auf einen oder mehrere in der Windows-HTTP-Proxykonfiguration installierte HTTP-Proxies festgelegt.
  • Die Linux-Umgebungsvariable HTTPS_PROXYist auf die in der Windows HTTPS-Proxykonfiguration installierten HTTPS-Proxys festgelegt.
  • Die Linux-Umgebungsvariable ist so festgelegt, NO_PROXYdass alle HTTP/S-Proxys umgangen werden, die in den Windows-Konfigurationszielen enthalten sind.
  • Jede Umgebungsvariable mit Ausnahme von WSL_PAC_URL wird sowohl in Klein- als auch in Großbuchstaben festgelegt. Beispiel: HTTP_PROXY und http_proxy.

Es gibt ein bekanntes Problem, das durch ZScaler-Konfigurationen verursacht wird, bei dem ZScaler wiederholt Windows-Proxykonfigurationen aktiviert und deaktiviert, was zu WSL führt, wodurch wiederholt die Benachrichtigung "Eine Http-Proxyänderung wurde auf dem Host erkannt" angezeigt wird.

Weitere Informationen finden Sie im Befehlszeilenblog: WSL-Update vom September 2023.

Überlegungen zum Netzwerk mit DNS-Tunneling

Wenn WSL keine Verbindung mit dem Internet herstellen kann, liegt dies möglicherweise daran, dass der DNS-Aufruf an den Windows-Host blockiert ist. Dies liegt daran, dass das Netzwerkpaket für DNS, das von der WSL-VM an den Windows-Host gesendet wird, durch die vorhandene Netzwerkkonfiguration blockiert wird. Durch DNS-Tunneling wird dies behoben, indem ein Virtualisierungs-Feature genutzt wird, um direkt mit Windows zu kommunizieren, sodass der DNS-Name aufgelöst werden kann, ohne ein Netzwerkpaket zu senden. Dieses Feature sollte die Netzwerkkompatibilität verbessern und es Ihnen ermöglichen, eine bessere Internetverbindung zu erzielen, auch wenn Sie über ein VPN, eine bestimmte Firewalleinrichtung oder andere Netzwerkkonfigurationen verfügen.

DNS-Tunneling kann mithilfe der dnsTunneling Einstellung im experimentellen Abschnitt der WSL-Konfigurationsdatei konfiguriert werden. Beachten Sie beim Anwenden dieser Einstellung die folgenden Überlegungen:

  • Wenn Sie ein VPN mit WSL verwenden, aktivieren Sie die DNS-Tunnelung. Viele VPNs verwenden NRPT-Richtlinien, die nur auf WSL-DNS-Abfragen angewendet werden, wenn DNS-Tunneling aktiviert ist.
  • Die /etc/resolv.conf Datei in Ihrer Linux-Verteilung hat eine maximale Beschränkung von 3 DNS-Servern, während Windows möglicherweise mehr als 3 DNS-Server verwendet. Die Verwendung von DNS-Tunneling entfernt diese Einschränkung – alle Windows-DNS-Server können jetzt von Linux verwendet werden.
  • WSL verwendet Windows-DNS-Suffixe in der folgenden Reihenfolge (ähnlich der Reihenfolge, die vom Windows-DNS-Client verwendet wird):
    1. Globale DNS-Suffixe
    2. Ergänzende DNS-Suffixe
    3. DNS-Suffixe pro Schnittstelle
    4. Wenn die DNS-Verschlüsselung (DoH, DoT) unter Windows aktiviert ist, wird die Verschlüsselung auf DNS-Abfragen von WSL angewendet. Wenn Benutzer DoH und DoT in Linux aktivieren möchten, müssen sie DNS-Tunneling deaktivieren.
  • DNS-Abfragen von Docker-Containern, die von Docker Desktop verwaltet werden, umgehen DNS-Tunneling. Docker Desktop hat eine eigene Methode (anders als DNS-Tunneling) zum Anwenden von Host-DNS-Einstellungen und -Richtlinien auf DNS-Abfragen von Docker-Containern.
  • Damit DNS-Tunneling erfolgreich aktiviert werden kann, sollte die Option "generateResolvConf" in der Datei "wsl.conf" nicht deaktiviert werden.
  • Wenn DNS-Tunneling aktiviert ist, wird die generateHosts Option in der Datei "wsl.conf" ignoriert (die Datei "Windows DNS-Hosts" wird nicht in die Datei "Linux /etc/hosts" kopiert). Die Richtlinien in der Windows-Hosts-Datei werden auf DNS-Abfragen von Linux angewendet, ohne dass die Datei in Linux kopiert werden muss.

Weitere Informationen finden Sie im Befehlszeilenblog: WSL-Update vom September 2023.

Probleme beim Steuern des eingehenden Datenverkehrs, den der Windows-Host auf den virtuellen WSL-Computer empfängt

Bei Verwendung des Spiegelungsnetzwerkmodus (wenn der experimentelle networkingMode auf mirrored gesetzt ist), wird einiger eingehender Datenverkehr, der vom Windows-Host empfangen wird, niemals an die Linux-VM weitergeleitet. Dieser Datenverkehr lautet wie folgt:

  • UDP-Port 68 (DHCP)
  • TCP-Port 135 (DCE-Endpunktauflösung)
  • TCP-Port 1900 (UPnP)
  • TCP-Port 2869 (SSDP)
  • TCP-Port 5004 (RTP)
  • TCP-Port 3702 (WSD)
  • TCP-Port 5357 (WSD)
  • TCP-Port 5358 (WSD)

WSL konfiguriert bei Verwendung des gespiegelten Netzwerkmodus automatisch bestimmte Linux-Netzwerkeinstellungen. Alle Benutzerkonfigurationen dieser Einstellungen beim Verwenden des gespiegelten Netzwerkmodus werden nicht unterstützt. Hier ist die Liste der Einstellungen, die WSL konfiguriert:

Einstellungsname Wert
https://sysctl-explorer.net/net/ipv4/accept_local/ Aktiviert (1)
https://sysctl-explorer.net/net/ipv4/route_localnet/ Aktiviert (1)
https://sysctl-explorer.net/net/ipv4/rp_filter/ Deaktiviert (0)
https://sysctl-explorer.net/net/ipv6/accept_ra/ Deaktiviert (0)
https://sysctl-explorer.net/net/ipv6/autoconf/ Deaktiviert (0)
https://sysctl-explorer.net/net/ipv6/use_tempaddr/ Deaktiviert (0)
addr_gen_mode Deaktiviert (0)
IPv6 deaktivieren Deaktiviert (0)
https://sysctl-explorer.net/net/ipv4/arp_filter/ Aktiviert (1)

Probleme mit Docker-Containern in WSL2 mit aktiviertem Gespiegelten Netzwerkmodus, wenn sie unter dem Standardnetzwerknamespace ausgeführt werden

Es gibt ein bekanntes Problem, bei dem Docker Desktop-Container mit veröffentlichten Ports (docker run –publish/–p) nicht erstellt werden. Das WSL-Team arbeitet mit dem Docker Desktop-Team zusammen, um dieses Problem zu beheben. Um das Problem zu umgehen, verwenden Sie den Netzwerknamespace des Hosts im Docker-Container. Legen Sie den Netzwerktyp über die Option fest, die --network hostdocker run im Befehl verwendet wird. Eine alternative Problemumgehung besteht darin, die veröffentlichte Portnummer in der ignoredPorts Einstellung des experimentellen Abschnitts in der WSL-Konfigurationsdatei auflisten.

Docker-Containerprobleme beim Ausführen des Netzwerk-Managers

Es gibt ein bekanntes Problem mit Docker-Containern, die den Netzwerk-Manager-Dienst ausführen. Symptome umfassen Fehler beim Versuch, Loopbackverbindungen mit dem Host herzustellen. Es wird empfohlen, den Netzwerk-Manager-Dienst für WSL-Netzwerke zu beenden, um ordnungsgemäß konfiguriert zu werden.

sudo systemctl disable network-manager.service

Auflösung von .local-Namen in WSL

Um Hostnamen in IP-Adressen innerhalb eines lokalen Netzwerks aufzulösen, ohne dass ein herkömmlicher DNS-Server erforderlich ist, werden häufig .local-Namen verwendet. Dies wird über das mDNS-Protokoll (Multicast DNS) erreicht, das auf Multicastdatenverkehr basiert, um zu funktionieren.

networkingMode NATauf :

Derzeit wird dieses Feature nicht unterstützt, wenn DNS-Tunneling aktiviert ist. Um die Auflösung von .local-Namen zu aktivieren, empfehlen wir die folgenden Lösungen:

  • Dns-Tunneling deaktivieren.
  • Verwenden Sie den gespiegelten Netzwerkmodus.

networkingMode Mirroredauf :

Hinweis: Sie müssen auf WSL Build 2.3.17 oder höher sein, um die unten aufgeführten Funktionen zu erhalten.

Da der Spiegelmodus Multicastdatenverkehr unterstützt, kann das mDNS-Protokoll (Multicast DNS) verwendet werden, um .local-Namen aufzulösen. Linux muss so konfiguriert sein, dass mDNS unterstützt wird, da dies nicht standardmäßig der Fall ist. Eine Möglichkeit, sie zu konfigurieren, besteht in den folgenden beiden Schritten:

  1. Installieren Sie das libnss-mdns-Paket

    sudo apt-get install libnss-mdns

    *Das libnss-mdns Paket ist ein Plugin für die GNU Name Service Switch (NSS)-Funktionalität der GNU C Library (glibc), die Hostnamenauflösung über Multicast DNS (mDNS) bereitstellt. Dieses Paket ermöglicht es effektiv gängige Unix/Linux-Programme, Namen in der Ad-hoc-mDNS-Domäne .local aufzulösen.

  2. Konfigurieren Sie die /etc/nsswitch.conf Datei, um die mdns_minimal Einstellung im hosts Abschnitt zu aktivieren. Beispielinhalt der Datei:

    />cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat systemd
group:          compat systemd
shadow:         compat
gshadow:        files

hosts:          files mdns_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

DNS-Suffixe in WSL

Abhängig von den Konfigurationen in der Wslconfig-Datei verfügt WSL über das folgende Verhalten von DNS-Suffixen:

Wann networkingMode ist auf :NAT

Fall 1: Standardmäßig ist kein DNS-Suffix in Linux konfiguriert

Fall 2: Wenn DNS-Tunneling aktiviert ist (dnsTunneling ist true auf ".wslconfig") alle Windows-DNS-Suffixe in Linux konfiguriert, in der search Einstellung "/etc/resolv.conf"

Die Suffixe sind in /etc/resolv.conf in der folgenden Reihenfolge konfiguriert, ähnlich der Reihenfolge, in der Windows DNS-Client Suffixe beim Auflösen eines Namens versucht: globale DNS-Suffixe zuerst, dann ergänzende DNS-Suffixe und dann pro Schnittstelle DNS-Suffixe.

Wenn es eine Änderung in den Windows-DNS-Suffixen gibt, wird diese Änderung automatisch in Linux übernommen.

Fall 3: Wenn DNS-Tunneling deaktiviert ist und SharedAccess-DNS-Proxy deaktiviert ist (dnsTunneling und dnsProxy in Wslconfig festgelegt false ist). Ein einzelnes DNS-Suffix ist unter Linux in der Einstellung "domain" von /etc/resolv.conf konfiguriert.

Wenn es eine Änderung der Windows-DNS-Suffixe gibt, wird diese Änderung nicht in Linux übernommen.

Das in Linux konfigurierte einzelne DNS-Suffix wird aus den DNS-Suffixen pro Schnittstelle ausgewählt (globale und ergänzende Suffixe werden ignoriert)

Wenn Windows über mehrere Schnittstellen verfügt, wird eine Heuristik verwendet, um das einzelne DNS-Suffix auszuwählen, das in Linux konfiguriert wird. Wenn beispielsweise eine VPN-Schnittstelle unter Windows vorhanden ist, wird das Suffix von dieser Schnittstelle ausgewählt. Wenn keine VPN-Schnittstelle vorhanden ist, wird das Suffix von der Schnittstelle ausgewählt, die höchstwahrscheinlich eine Internetverbindung gibt.

Wann networkingMode ist auf :Mirrored

Alle Windows-DNS-Suffixe sind unter Linux in der search Einstellung "/etc/resolv.conf" konfiguriert.

Die Suffixe sind in /etc/resolv.conf in der gleichen Reihenfolge wie bei 2) aus dem NAT-Modus konfiguriert.

Wenn es eine Änderung in den Windows-DNS-Suffixen gibt, wird diese Änderung automatisch in Linux übernommen.

Hinweis

Zusätzliche DNS-Suffixe können in Windows konfiguriert werden.

SetInterfaceDnsSettings-Funktion (netioapi.h), wobei das Flag DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST im Settings Parameter festgelegt ist.

Problembehandlung von DNS in WSL

Die Standardmäßige DNS-Konfiguration, wenn WSL einen Container im NAT-Modus startet, besteht darin, dass das NAT-Gerät auf dem Windows-Host als DNS-"Server" für den WSL-Container dient. Wenn DNS-Abfragen vom WSL-Container an dieses NAT-Gerät auf dem Windows-Host gesendet werden, wird das DNS-Paket vom NAT-Gerät an den freigegebenen Zugriffsdienst auf dem Host weitergeleitet; die Antwort wird in umgekehrter Richtung zurück an den WSL-Container gesendet. Für diesen Paketweiterleitungsprozess für den freigegebenen Zugriff ist eine Firewallregel erforderlich, um dieses eingehende DNS-Paket zuzulassen, das vom HNS-Dienst erstellt wird, wenn WSL zunächst HNS fragt, das virtuelle NAT-Netzwerk für seinen WSL-Container zu erstellen.

Aufgrund dieses NAT- freigegebenen Zugriffsdesigns gibt es einige bekannte Konfigurationen, die die Namensauflösung von WSL unterbrechen können.

  1. Ein Unternehmen kann Richtlinien pushen, die keine lokal definierten Firewallregeln zulassen, sodass nur definierte Regeln für Unternehmensrichtlinien zulässig sind.

    Wenn dies von einem Unternehmen festgelegt wird, wird die von HNS erstellte Firewallregel ignoriert, da es sich um eine lokal definierte Regel handelt.

    Damit diese Konfiguration funktioniert, muss das Unternehmen eine Firewallregel erstellen, um UDP-Port 53 für den freigegebenen Zugriffsdienst zuzulassen, oder WSL kann für die Verwendung von DNS-Tunneling festgelegt werden.

    Sie können sehen, ob dies so konfiguriert ist, dass lokal definierte Firewallregeln nicht zulässig sind, indem Sie Folgendes ausführen. Beachten Sie, dass dadurch Einstellungen für alle 3 Profile angezeigt werden: Domäne, Privat und Öffentlich. Wenn es für ein Profil festgelegt ist, werden Pakete blockiert, wenn dem Profil die WSL-vNIC zugewiesen ist (Standardeinstellung).Public Dies ist nur ein Codeausschnitt des ersten Firewallprofils, das in Powershell zurückgegeben wird:

    PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name                    : Domain
Enabled                 : True
DefaultInboundAction    : Block
DefaultOutboundAction   : Allow
AllowInboundRules       : True
AllowLocalFirewallRules : False
...

    AllowLocalFirewallRules: False bedeutet, dass die lokal definierten Firewallregeln, z. B. von HNS, nicht angewendet oder verwendet werden.

  2. Und Enterprise kann Gruppenrichtlinien- und MDM-Richtlinieneinstellungen pushen, die alle eingehenden Regeln blockieren.

    Diese Einstellungen setzen jede Allow-Inbound Firewallregel außer Kraft. Diese Einstellung blockiert somit die von HNS erstellte UDP-Firewallregel und verhindert daher, dass WSL Namen auflösen kann.

    Damit diese Konfiguration funktioniert, muss WSL für die Verwendung von DNS-Tunneling festgelegt sein. Diese Einstellung blockiert immer den NAT-DNS-Proxy.

    Aus Gruppenrichtlinie:

    Computerkonfiguration \ Administrative Vorlagen \ Netzwerk \ Netzwerkverbindungen \ Windows Defender Firewall \ Domänenprofil | Standardprofil

    "Windows Defender Firewall: Ausnahmen nicht zulassen" – Aktiviert

    Aus MDM-Richtlinie:

    ./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/Abgeschirmt

    ./Vendor/MSFT/Firewall/MdmStore/DomainProfile/Geschützt

    ./Vendor/MSFT/Firewall/MdmStore/PublicProfile/Shielded

    Sie können sehen, ob dies so konfiguriert ist, dass eingehende Firewallregeln nicht zulässig sind, indem Sie folgendes ausführen (siehe oben beschriebene Einschränkungen in Firewallprofilen). Dies ist nur ein Codeausschnitt des ersten Firewallprofils, das in Powershell zurückgegeben wird:

    
PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name                  : Domain
Enabled               : True
DefaultInboundAction  : Block
DefaultOutboundAction : Allow
AllowInboundRules     : False
...

    AllowInboundRules: False bedeutet, dass keine eingehenden Firewallregeln angewendet werden.

  3. Ein Benutzer durchläuft die Windows-Sicherheitseinstellungs-Apps und überprüft das Steuerelement auf "Blockiert alle eingehenden Verbindungen, einschließlich derjenigen in der Liste der zulässigen Apps".

    Windows unterstützt eine Benutzerzustimmung für dieselbe Einstellung, die von einem Unternehmen angewendet werden kann, wie oben in Punkt #2 angegeben. Benutzer können die Einstellungsseite "Windows-Sicherheit" öffnen, die Option "Firewall & Netzwerkschutz" auswählen, das Firewallprofil auswählen, das sie konfigurieren möchten (Domäne, Privat oder Öffentlich), und aktivieren Sie unter "Eingehende Verbindungen" das Steuerelement mit der Bezeichnung "Alle eingehenden Verbindungen blockiert, einschließlich derjenigen in der Liste der zulässigen Apps".

    Wenn dies für das öffentliche Profil festgelegt ist (dies ist das Standardprofil für die WSL vNIC), wird die Firewallregel, die von HNS erstellt wurde, blockiert, damit die UDP-Pakete gemeinsam genutzt werden können.

    Dies muss deaktiviert sein, damit die NAT-DNS-Proxykonfiguration von WSL funktioniert, oder WSL kann für die Verwendung von DNS-Tunneling festgelegt werden.

  4. Die HNS-Firewallregel, damit die DNS-Pakete für den freigegebenen Zugriff ungültig werden können und auf einen vorherigen WSL-Schnittstellenbezeichner verweisen.

    Dies ist ein Fehler in HNS, der mit der neuesten Windows 11-Version behoben wurde. In früheren Versionen, wenn dies passiert, ist es nicht einfach zu erkennen, aber es gibt eine einfache Umgehungslösung:

    • WSL beenden

      wsl.exe –shutdown

    • Löschen Sie die alte HNS-Firewallregel. Dieser PowerShell-Befehl sollte in den meisten Fällen funktionieren:

      Get-NetFirewallRule -Name "HNS*" | Get-NetFirewallPortFilter | where Protocol -eq UDP | where LocalPort -eq 53 | Remove-NetFirewallRule

    • Entfernen Sie alle HNS-Endpunkte. Hinweis: Wenn HNS zum Verwalten anderer Container verwendet wird, z. B. MDAG oder Windows Sandbox, sollten diese ebenfalls beendet werden.

      hnsdiag.exe delete all

    • Starten Sie den HNS-Dienst neu oder führen Sie einen Neustart durch.

      Restart-Service hns

    • Wenn WSL neu gestartet wird, erstellt HNS neue Firewallregeln, die korrekt auf die WSL-Netzwerkschnittstelle abzielen.

Problembehandlung bei Netzwerkzugriffsproblemen unter Windows

Wenn Sie keinen Netzwerkzugriff haben, kann dies auf eine Fehlkonfiguration zurückzuführen sein. Überprüfen Sie, ob der FSE-Treiber ausgeführt wird:

Get-Service FSE

Wenn fsE nicht ausgeführt wird, überprüfen Sie, ob der PortTrackerEnabledMode Registrierungswert unter diesem Registrierungsschlüssel beendet wird:

Get-ItemProperty HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters

Wenn FSE nicht ausgeführt oder installiert ist und PortTrackerEnabledMode vorhanden ist, löschen Sie diesen Registrierungswert, und starten Sie es neu.

Manuelle Methode zum Löschen von Phantomadaptern

Ghost Adapter oder Phantom Plug and Play (PnP)-Geräte beziehen sich auf Hardwarekomponenten, die in Ihrem System angezeigt werden, aber nicht physisch verbunden sind. Diese "Ghost"-Geräte können Verwirrung und Unübersichtlichkeit in Ihren Systemeinstellungen verursachen. Wenn beim Ausführen von WSL auf einem virtuellen Computer (VM) Ghost Adapter angezeigt werden, führen Sie diese manuellen Schritte aus, um diese Phantom PnP-Geräte zu suchen und zu löschen. Microsoft arbeitet an einer automatisierten Lösung, die keinen manuellen Eingriff erfordert. Weitere Informationen werden in Kürze verfügbar sein.

  1. Öffnen Sie den Geräte-Manager.

  2. Anzeige ausgeblendeter Geräte >

    Screenshot des Menüs

  3. Netzwerkadapter öffnen

    Screenshot der Liste der Netzwerkadapter

  4. Klicken Sie mit der rechten Maustaste auf den Ghosted-Netzwerkadapter, und wählen Sie "Gerät deinstallieren" aus.

    Screenshot des Rechtsklicks auf ein Phantom-PnP aus der Netzwerkliste und der Auswahl von „Gerät deinstallieren“

Beim Starten von WSL oder installieren einer Verteilung wird ein Fehlercode zurückgegeben.

Befolgen Sie die Anweisungen zum Sammeln von WSL-Protokollen im WSL-Repository auf GitHub, um detaillierte Protokolle zu sammeln und ein Problem auf unserem GitHub zu speichern.

Aktualisieren von WSL

Es gibt zwei Komponenten des Windows-Subsystems für Linux, die eine Aktualisierung erfordern können.

  1. Um das Windows-Subsystem für Linux selbst zu aktualisieren, verwenden Sie bitte den folgenden Befehl.

    wsl.exe --update

  2. Um die spezifischen Binärdateien für Linux-Distributionen zu aktualisieren, verwenden Sie bitte den folgenden Befehl in der Linux-Verteilung, die Sie aktualisieren möchten.

    apt-get update | apt-get upgrade

Fehler bei apt-get upgrade

Einige Pakete verwenden Features, die wir noch nicht implementiert haben. udevwird beispielsweise noch nicht unterstützt und verursacht mehrere apt-get upgrade Fehler.

Führen Sie zum Beheben von Problemen im Zusammenhang mit udev die folgenden Schritte aus:

  1. Schreiben Sie Folgendes in /usr/sbin/policy-rc.d und speichern Sie Ihre Änderungen.

    #!/bin/sh
exit 101

  2. Hinzufügen von Ausführungsberechtigungen zu /usr/sbin/policy-rc.d:

    chmod +x /usr/sbin/policy-rc.d

  3. Führen Sie die folgenden Befehle aus:

    dpkg-divert --local --rename --add /sbin/initctl
ln -s /bin/true /sbin/initctl

"Fehler: 0x80040306" bei der Installation

Dies hat mit der Tatsache zu tun, dass wir die Ältere Konsole nicht unterstützen. So deaktivieren Sie die Legacy-Konsole:

  1. Öffnen von cmd.exe
  2. Klicken Sie mit der rechten Maustaste auf die Titelleiste –> Eigenschaften –> Deaktivieren Sie die Verwendung der Legacy-Konsole
  3. OK klicken

"Fehler: 0x80040154" nach dem Windows-Update

Das Windows-Subsystem für Linux-Feature kann während eines Windows-Updates deaktiviert werden. Wenn dies geschieht, muss das Windows-Feature erneut aktiviert werden. Anweisungen zum Aktivieren des Windows-Subsystems für Linux finden Sie im Handbuch zur manuellen Installation.

Ändern der Anzeigesprache

Die WSL-Installation versucht, das Gebietsschema von Ubuntu automatisch so zu ändern, dass es mit dem Gebietsschema Ihrer Windows-Installation übereinstimmt. Wenn Sie dieses Verhalten nicht möchten, können Sie diesen Befehl ausführen, um das Gebietsschema von Ubuntu nach Abschluss der Installation zu ändern. Sie müssen bash.exe neu starten, damit diese Änderung wirksam wird.

Im folgenden Beispiel wird das Gebietsschema zu en-US geändert.

sudo update-locale LANG=en_US.UTF8

Installationsprobleme nach der Windows-Systemwiederherstellung

  1. Löschen Sie den Ordner %SystemRoot%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux.

    Warnung

    Führen Sie dies nicht aus, wenn Ihr optionales Feature vollständig installiert und funktioniert.

  2. Aktivieren des optionalen WSL-Features (sofern noch nicht geschehen)

  3. Neustart

  4. lxrun /uninstall /full

  5. Installieren von bash

Kein Internetzugriff in WSL

Einige Benutzer haben Probleme mit bestimmten Firewallanwendungen gemeldet, die den Internetzugriff in WSL blockieren. Die gemeldeten Firewalls sind:

  1. Kaspersky
  2. AVG
  3. Avast
  4. Symantec Endpoint Protection

In einigen Fällen ermöglicht das Deaktivieren der Firewall den Zugriff. In einigen Fällen scheint das Vorhandensein einer installierten Firewall einfach den Zugriff zu blockieren.

Wenn Sie Microsoft Defender Firewall verwenden, deaktivieren Sie "Alle eingehenden Verbindungen blockiert, einschließlich derjenigen in der Liste der zulässigen Apps". Ermöglicht den Zugriff.

Fehler "Berechtigung verweigert" beim Ausführen des Befehls 'ping'

Für Windows Anniversary Update, Version 1607, müssen Administratorrechte in Windows in WSL ausgeführt werden ping . pingFühren Sie Bash unter Ubuntu unter Windows als Administrator aus, oder führen Sie sie bash.exe über eine PowerShell-Eingabeaufforderung mit Administratorrechten aus.

Für spätere Versionen von Windows , Build 14926+, sind keine Administratorrechte mehr erforderlich.

Bash ist aufgehängt

Wenn Sie beim Arbeiten mit Bash feststellen, dass Bash hängt oder in einer Deadlock-Situation ist und nicht auf Eingaben reagiert, helfen Sie uns, das Problem zu diagnostizieren, indem Sie ein Speicherabbild sammeln und es melden. Beachten Sie, dass diese Schritte ihr System abstürzen. Tun Sie dies nicht, wenn Sie damit nicht vertraut sind, oder speichern Sie Ihre Arbeit, bevor Sie dies tun.

So erfassen Sie ein Speicherabbild:

  1. Ändern Sie den Speicherabbildtyp in "Vollständiges Speicherabbild". Notieren Sie sich beim Ändern des Dumptyps Ihren aktuellen Typ.

  2. Führen Sie die Schritte zum Konfigurieren des Absturzes mithilfe der Tastatursteuerung aus.

  3. Reproduzieren Sie den Systemstillstand oder die Verklemmung.

  4. Das System mithilfe der Tastenfolge von (2) zum Absturz bringen.

  5. Das System stürzt ab und sammelt das Speicherabbild.

  6. Sobald das System neu gestartet wird, melden Sie den memory.dmpsecure@microsoft.com Der Standardspeicherort der Speicherabbilddatei ist %SystemRoot%\memory.dmp oder C:\Windows\memory.dmp ob C: es sich um das Systemlaufwerk handelt. Beachten Sie in der E-Mail, dass das Dump für das WSL- oder Bash-Team unter Windows gilt.

  7. Stellen Sie den ursprünglichen Speicherabbildtyp wieder her.

Überprüfen Sie die Buildnummer

Um die Architektur und die Windows-Buildnummer Ihres PCs zu finden, öffnen Sie Einstellungen>System>Info

Suchen Sie nach den Feldern Betriebssystembuild und Systemtyp. Screenshot der Felder

Führen Sie die folgenden Schritte in PowerShell aus, um ihre Windows Server-Buildnummer zu finden:

systeminfo | Select-String "^OS Name","^OS Version"

Bestätigen, dass WSL aktiviert ist

Sie können bestätigen, dass das Windows-Subsystem für Linux aktiviert ist, indem Sie Folgendes in einem PowerShell-Fenster mit erhöhten Rechten ausführen:

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

OpenSSH-Server Verbindungsprobleme

Fehler beim Versuch, den SSH-Server zu verbinden: "Verbindung wurde durch 127.0.0.1 Port 22 geschlossen".

  1. Stellen Sie sicher, dass ihr OpenSSH-Server ausgeführt wird:

    sudo service ssh status

    und Sie haben diesem Lernprogramm gefolgt: https://ubuntu.com/server/docs/service-openssh

  2. Beenden Sie den sshd-Dienst, und starten Sie sshd im Debugmodus:

    sudo service ssh stop
sudo /usr/sbin/sshd -d

  3. Überprüfen Sie die Startprotokolle, und stellen Sie sicher, dass HostKeys verfügbar sind und keine Protokollmeldungen angezeigt werden, z. B.:

    debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: key_load_private: incorrect passphrase supplied to decrypt private key
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_rsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_dsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_ed25519_key

Wenn solche Meldungen angezeigt werden und die Schlüssel unter /etc/ssh/ fehlen, müssen Sie die Schlüssel regenerieren oder einfach löschen&installieren openssh-server.

sudo apt-get purge openssh-server
sudo apt-get install openssh-server

"Die referenzierte Assembly konnte nicht gefunden werden." beim Aktivieren des optionalen WSL-Features

Dieser Fehler bezieht sich auf einen fehlerhaften Installationszustand. Führen Sie die folgenden Schritte aus, um dieses Problem zu beheben:

  • Wenn Sie den WSL-Featurebefehl über PowerShell aktivieren, versuchen Sie stattdessen, die GUI zu verwenden, indem Sie das Startmenü öffnen, nach "Windows-Features ein- oder ausschalten" suchen und dann in der Liste "Windows-Subsystem für Linux" auswählen, wodurch die optionale Komponente installiert wird.

  • Aktualisieren Sie Ihre Windows-Version, indem Sie zu "Einstellungen", "Updates" wechseln und auf "Nach Updates suchen" klicken.

  • Wenn beide Fehler auftreten und Sie auf WSL zugreifen müssen, sollten Sie ein Upgrade durchführen, indem Sie Windows mithilfe von Installationsmedien erneut installieren und "Alles beibehalten" auswählen, um sicherzustellen, dass Ihre Apps und Dateien beibehalten werden. Anweisungen dazu finden Sie auf der Seite "Windows 10 neu installieren".

Wenn dieser Fehler angezeigt wird:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/user/.ssh/private-key.pem' are too open.

Um dieses Problem zu beheben, fügen Sie folgendes an die /etc/wsl.conf Datei an:

[automount]
enabled = true
options = metadata,uid=1000,gid=1000,umask=0022

Bitte beachten Sie, dass das Hinzufügen dieses Befehls Metadaten enthält und die Dateiberechtigungen für die Windows-Dateien ändert, die von WSL angezeigt werden. Weitere Informationen finden Sie in den Dateisystemberechtigungen .

WSL kann nicht remote mittels OpenSSH unter Windows genutzt werden.

Wenn Sie den Openssh-Server unter Windows verwenden und remote auf WSL zugreifen möchten, wird dieser Fehler angezeigt: Auf die Datei kann nicht vom System zugegriffen werden.

Es ist ein bekanntes Problem, wenn Sie die Store-Version von WSL verwenden. Sie können dies heute umgehen, indem Sie WSL 1 oder die In-Windows-Version von WSL verwenden. Weitere Informationen finden Sie unter WSL im Microsoft Store .

Ausführen von Windows-Befehlen schlägt innerhalb einer Verteilung fehl

Einige im Microsoft Store verfügbare Verteilungen sind noch nicht vollständig kompatibel, um Windows-Befehle sofort auszuführen. Wenn ein Fehler "-bash: powershell.exe: Befehl nicht gefunden" oder powershell.exe /c start . ein anderer Windows-Befehl angezeigt wird, können Sie ihn wie folgt beheben:

  1. Führen Sie in der WSL-Distribution echo $PATH aus. Wenn dies nicht enthalten ist: /mnt/c/Windows/system32 wird die Standard-PATH-Variable von etwas anderem neu definiert.
  2. Überprüfen Sie die Profileinstellungen mit cat /etc/profile. Wenn die Datei die Zuordnung der PATH-Variablen enthält, kommentieren Sie den PATH-Zuordnungsblock mit einem # Symbol aus.
  3. Überprüfen Sie, ob wsl.conf vorhanden ist cat /etc/wsl.conf und stellen Sie sicher, dass es appendWindowsPath=false nicht enthält, andernfalls kommentieren Sie es aus.
  4. Starten Sie die Verteilung neu, indem Sie gefolgt vom Verteilungsnamen eingeben wsl -t <Distro> oder entweder in PowerShell ausführen wsl --shutdown .

Nach der Installation von WSL 2 kann nicht gestartet werden.

Wir sind uns eines Problems bewusst, das sich auf Benutzer auswirkt, bei denen sie nach der Installation von WSL 2 nicht starten können. Während wir dieses Problem vollständig diagnostizieren, haben Die Benutzer berichtet, dass das Ändern der Puffergröße oder die Installation der richtigen Treiber dazu beitragen kann. Sehen Sie sich dieses GitHub-Issue an, um die neuesten Aktualisierungen zu diesem Thema zu sehen.

WSL 2-Fehler, wenn ICS deaktiviert ist

Die Internetverbindungsfreigabe (Internet Connection Sharing, ICS) ist eine erforderliche Komponente von WSL 2. Der ICS-Dienst wird vom Host Network Service (HNS) verwendet, um das zugrunde liegende virtuelle Netzwerk zu erstellen, auf dem WSL 2 für NAT, DNS, DHCP und Hostverbindungsfreigabe basiert.

Wenn Sie den ICS-Dienst (SharedAccess) deaktivieren oder ICS über eine Gruppenrichtlinie deaktivieren, wird verhindert, dass das WSL HNS-Netzwerk erstellt wird. Dies führt zu Fehlern beim Erstellen eines neuen WSL Version 2-Images, und der folgende Fehler beim Versuch, ein Image der Version 1 in Version 2 zu konvertieren: Es sind keine weiteren Endpunkte aus der Endpunktzuordnung verfügbar.

Systeme, die WSL 2 erfordern, sollten den ICS-Dienst (SharedAccess) im Standardstartzustand belassen – Manuell (Trigger Start) – und alle Richtlinien, die ICS deaktivieren, sollten überschrieben oder entfernt werden. Beim Deaktivieren des ICS-Diensts wird WSL 2 unterbrochen, und es wird nicht empfohlen, ICS zu deaktivieren, Teile von ICS können mithilfe dieser Anweisungen deaktiviert werden.

Verwenden älterer Versionen von Windows und WSL

Es gibt mehrere Unterschiede zu beachten, wenn Sie eine ältere Version von Windows und WSL ausführen, z. B. das Windows 10 Creators Update (Okt 2017, Build 16299) oder Anniversary Update (August 2016, Build 14393). Es wird empfohlen, auf die neueste Windows-Version zu aktualisieren, aber wenn dies nicht möglich ist, haben wir einige der unten aufgeführten Unterschiede beschrieben.

Unterschiede bei Interoperabilitätsbefehlen

  • bash.exe wurde durch wsl.exe ersetzt. Linux-Befehle können über die PowerShell ausgeführt werden, aber für frühe Windows-Versionen müssen Sie möglicherweise den bash Befehl verwenden. Beispiel: C:\temp> bash -c "ls -la". Die WSL-Befehle, die in bash -c übergeben werden, werden ohne Änderung an den WSL-Prozess weitergeleitet. Dateipfade müssen im WSL-Format angegeben werden, und darauf sollte geachtet werden, relevante Zeichen zu escapen. Beispiel: C:\temp> bash -c "ls -la /proc/cpuinfo" oder C:\temp> bash -c "ls -la \"/mnt/c/Program Files\"".
  • Um zu sehen, welche Befehle für eine bestimmte Verteilung verfügbar sind, führen Sie aus [distro.exe] /?. Beispiel: mit Ubuntu: C:\> ubuntu.exe /?.
  • Der Windows-Pfad ist in der WSL $PATHenthalten.
  • Beim Aufrufen eines Windows-Tools aus einer WSL-Verteilung in einer früheren Version von Windows 10 müssen Sie den Verzeichnispfad angeben. Um beispielsweise die Windows Notepad-App über die WSL-Befehlszeile aufzurufen, geben Sie Folgendes ein: /mnt/c/Windows/System32/notepad.exe
  • Um den Standardbenutzer auf root zu ändern, verwenden Sie diesen Befehl in PowerShell: C:\> lxrun /setdefaultuser root und führen Sie dann Bash.exe aus, um sich anzumelden: C:\> bash.exe. Setzen Sie Ihr Kennwort mithilfe des Befehls "Verteilungskennwort" zurück: $ passwd username und schließen Sie dann die Linux-Befehlszeile: $ exit. Setzen Sie an der Eingabeaufforderung von Windows oder PowerShell Ihr Standardbenutzerkonto auf Ihr normales Linux-Benutzerkonto zurück: C:\> lxrun.exe /setdefaultuser username.

Deinstallieren der Legacyversion von WSL

Wenn Sie WSL ursprünglich vor dem Creators-Update (Oct 2017, Build 16299) auf einer Version von Windows 10 installiert haben, empfehlen wir, alle erforderlichen Dateien, Daten usw. von der älteren Linux-Verteilung, die Sie installiert haben, zu einer neueren Verteilung zu migrieren, die über den Microsoft Store installiert ist. Um die alte Distribution von Ihrem Computer zu entfernen, führen Sie das Folgende aus einer Befehlszeilen- oder PowerShell-Instanz aus: wsl --unregister Legacy Sie haben auch die Möglichkeit, die ältere Legacyverteilung manuell zu entfernen, indem Sie den Ordner (und alle Unterinhalte) mithilfe des %LocalAppData%\lxss\ Windows-Datei-Explorers oder mit PowerShell löschen: Remove-Item -Recurse $env:localappdata/lxss/

Fehlercode 0x8000FFFF unerwarteten Fehler

Dieser Fehlercode bedeutet in der Regel, dass ein unerwarteter oder "katastrophaler" Fehler während des Systemvorgangs aufgetreten ist, wenn versucht wird, eine Linux-Distrubution (z. B. Ubuntu) mit WSL zu installieren oder zu verwenden. Es gibt viele Gründe, die zu diesem Fehler führen können. Überprüfen Sie zunächst Folgendes:

  • Ist dies ein Berechtigungsproblem? Überprüfen Sie, ob Sie als erwarteter Benutzer in Ihrer Befehlszeile angemeldet sind und über die erforderlichen Administratorrechte verfügen, wenn Sie eine Linux-Distrubution mit WSL installieren. (Klicken Sie mit der rechten Maustaste auf ihr Terminal- oder Befehlszeilen-Taskleistensymbol, um "Als Administrator ausführen" auszuwählen.)
  • Haben Sie WSL auf die neueste Version aktualisiert? Verwenden Sie den Befehl: wsl --update Zum Aktualisieren auf die neueste Version. Möglicherweise möchten Sie auch auf die neueste Version von Windows aktualisieren.
  • Stellen Sie sicher, dass Sie den wsl --install Befehl richtig verwenden und die Linux-Distrubution angeben, die Sie installieren möchten.
  • Versuchen Sie, WSL herunterzufahren und anschließend mit dem Befehl neu zu starten: wsl --shutdown.
  • Wenn Sie Windows Server verwenden, stellen Sie sicher, dass Ihre Version auf dem neuesten Stand ist, und befolgen Sie das Windows Server-Installationshandbuch.
  • Wenn Sie vermuten, dass dies mit fehlenden oder beschädigten Systemdateien zusammenhängt, können Sie über eine Eingabeaufforderung mit erhöhten Rechten (Als Administrator ausführen) Systemdateien überprüfen und reparieren und/oder das Windows-Betriebssystemimage reparieren. Um nach beschädigten oder fehlenden Windows-Systemdateien zu suchen und zu reparieren, verwenden Sie den Befehl: SFC /SCANNOW. Um das Windows-Image selbst zu reparieren, verwenden Sie den Befehl: DISM /Online /Cleanup-Image /RestoreHealth.
  • Siehe verwandtes WSL-Produkt-Repository-Problem 9420.
  • Last updated on