Problembehandlung des Windows-Subsystems für Linux

  • Artikel

Im Folgenden werden einige häufige Problembehandlungsszenarien im Zusammenhang mit WSL behandelt. Sie sollten jedoch auch die im WSL-Produkt-Repository auf GitHub aufgeführten Probleme durchsuchen.

Problem melden, Fehlerbericht, Featureanforderung

Die Probleme im WSL-Produkt-Repository ermöglichen Ihnen Folgendes:

  • Durchsuchen vorhandener Probleme, um zu schauen, ob ähnliche Probleme wie das bei Ihnen aufgetretene Problem beschrieben werden. Beachten Sie, dass Sie in der Suchleiste „is:open“ entfernen können, um bereits behobene Probleme in Ihre Suche einzubeziehen. Bitte kommentieren Sie offene Probleme, oder markieren Sie sie mit „Gefällt mir“, um auszudrücken, dass diese in Ihren Augen mit Priorität behandelt werden sollten.
  • Melden Sie ein neues Problem. Wenn bei Ihnen ein Problem mit WSL aufgetreten ist, das anscheinend noch nicht im Repository aufgeführt ist, wählen Sie die grüne Schaltfläche Neues Problem und dann WSL – Fehlerbericht aus. Sie müssen folgende Angaben machen: Titel für das Problem, Ihre Windows-Buildnummer (führen Sie cmd.exe /c ver aus, um die aktuelle Buildnummer anzuzeigen), ob Sie WSL 1 oder 2 ausführen, Ihre aktuelle Linux-Kernelversionsnummer (führen Sie wsl.exe --status oder cat /proc/version aus), die Versionsnummer Ihrer Verteilung (führen Sie lsb_release -r aus), alle anderen beteiligten Softwareversionen, die Reproduktionsschritte, das erwartete Verhalten, das tatsächliche Verhalten und die Diagnoseprotokolle, falls verfügbar und angemessen. Weitere Informationen finden Sie unter Mitwirken an WSL.
  • Erstellen Sie eine Featureanforderung, indem Sie die grüne Schaltfläche Neues Problem und dann Featureanforderung auswählen. Sie müssen einige Fragen beantworten, die Ihre Anforderung beschreiben.

Sie können außerdem:

Probleme bei der Installation

  • Installation failed with error 0x80070003 (Installationsfehler mit Fehlercode 0x80070003)

    • Das Windows-Subsystem für Linux wird nur auf dem Systemlaufwerk ausgeführt (in der Regel ist dies Ihr Laufwerk C:). Stellen Sie sicher, dass die Verteilungen auf dem Systemlaufwerk gespeichert sind:
    • Öffnen Sie in Windows 10 Einstellungen>System>Speicher>Weitere Speichereinstellungen: Speicherort für neue Inhalte ändernAbbildung der Systemeinstellungen für die Installation von Apps auf dem Laufwerk C: (Windows 10)
    • Öffnen Sie in Windows 11 Einstellungen>System>Speicher>Erweiterte Speichereinstellungen>Speicherort für neue InhalteAbbildung der Systemeinstellungen für die Installation von Apps auf dem Laufwerk C: (Windows 11)

  • WslRegisterDistribution failed with error 0x8007019e (WslRegisterDistribution-Fehler mit Fehlercode 0x8007019e)

    • Die optionale Komponente des Windows-Subsystems für Linux ist nicht aktiviert:
    • Öffnen Sie Systemsteuerung>Programme und Funktionen>Windows-Funktion aktivieren oder deaktivieren. Aktivieren Sie die Option Windows-Subsystem für Linux, oder verwenden Sie das PowerShell-Cmdlet, das am Anfang dieses Artikels erwähnt wurde.

  • Fehler 0x80070003 oder Fehler 0x80370102 während der Installation

    • Stellen Sie sicher, dass im BIOS Ihres Computers die Virtualisierung aktiviert ist. Die Anweisungen zur Aktivierung variieren je nach Computer. Die entsprechenden Optionen befinden sich wahrscheinlich in den CPU-bezogenen Einstellungen.
    • WSL2 setzt voraus, dass Ihre CPU das SLAT-Feature (Second Level Address Translation) 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 VM-Plattform erfolgreich installiert wurde.

  • Fehler beim Upgradeversuch: Invalid command line option: wsl --set-version Ubuntu 2

    • Vergewissern Sie sich, dass das Windows-Subsystem für Linux aktiviert wurde und Sie die Windows-Buildversion 18362 oder höher verwenden. Führen Sie zum Aktivieren von WSL in einer PowerShell-Eingabeaufforderung mit Administratorberechtigungen diesen Befehl aus: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux.

  • Der angeforderte Vorgang konnte aufgrund einer Einschränkung des virtuellen Dateisystems nicht abgeschlossen werden. Dateien für virtuelle Festplatten müssen unkomprimiert und unverschlüsselt sein und dürfen keine geringe Dichte aufweisen.

    • Heben Sie die Auswahl von „Inhalte komprimieren“ (sowie „Inhalte verschlüsseln“, falls aktiviert) auf, indem Sie den Profilordner Ihrer Linux-Verteilung öffnen. Er sollte sich in einem Ordner auf Ihrem Windows-Dateisystem befinden, der etwa folgendermaßen heißt: %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited....
    • In diesem Linux-Verteilungsprofil sollte ein Ordner "LocalState" 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 „Inhalt komprimieren, um Speicherplatz zu sparen“ und „Inhalt verschlüsseln, um Daten zu schützen“ nicht ausgewählt (nicht aktiviert) sind. Wenn Sie gefragt werden, ob Sie diese Einstellung nur auf den aktuellen Ordner oder auf alle Unterordner und Dateien anwenden möchten, wählen Sie „nur dieser Ordner“ aus, da Sie nur das Komprimierungsflag löschen. Danach sollte der Befehl wsl --set-version funktionieren.

Screenshot der Eigenschafteneinstellungen der WSL-Verteilung

Hinweis

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

Prüfen Sie den GitHub-Thread #4103 in der WSL-Dokumentation, der diesem Thema gewidmet ist, auf aktualisierte Informationen.

  • Der Ausdruck 'wsl' wurde nicht als Name eines Cmdlets, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt.

  • Fehler: Für das Windows-Subsystem für Linux wurden keine Distributionen installiert.

    • Gehen Sie wie folgt vor, wenn dieser Fehler angezeigt wird, nachdem Sie bereits WSL-Distributionen installiert haben:
    1. Führen Sie die Distribution mindestens einmal aus, bevor Sie sie über die Befehlszeile aufrufen.
    2. Überprüfen Sie, ob Sie möglicherweise separate Benutzerkonten ausführen. Beim Ausführen Ihres primären Benutzerkontos mit erhöhten Berechtigungen (im Administratormodus) sollte dieser Fehler nicht auftreten, Sie sollten jedoch sicherstellen, dass Sie nicht versehentlich das integrierte Administratorkonto von Windows ausführen. Dies ist ein separates Benutzerkonto, unter dem installierte WSL-Distributionen standardmäßig nicht sichtbar sind. Weitere Informationen finden Sie unter Aktivieren und Deaktivieren des integrierten Administratorkontos.
    3. Die ausführbare WSL-Datei wird nur im nativen Systemverzeichnis installiert. Wenn Sie einen 32-Bit-Prozess unter 64-Bit-Windows (oder unter ARM64 oder einer beliebigen nicht nativen Kombination) ausführen, ist für den gehosteten nicht nativen Prozess tatsächlich ein anderer System32-Ordner zugänglich. (Der für einen 32-Bit-Prozess unter x64-Windows sichtbare Prozess wird auf dem Datenträger unter \Windows\SysWOW64 gespeichert.) Sie können auf den „nativen“ system32-Prozess von einem gehosteten Prozess aus zugreifen, indem Sie in den virtuellen Ordner schauen: \Windows\sysnative. Beachten Sie, dass dieser auf dem Datenträger nicht tatsächlich vorhanden ist, die Pfadauflösung des Dateisystems findet ihn aber.

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

    • Zum Installieren des MSI-Updatepakets für den Linux-Kernel ist WSL erforderlich und sollte zuerst aktiviert werden. Wenn ein Fehler auftritt, wird die folgende Meldung angezeigt: This update only applies to machines with the Windows Subsystem for Linux.
    • Es gibt drei mögliche Gründe, warum diese Meldung angezeigt wird:

    1. Sie befinden sich immer noch in der alten Version von Windows, die WSL 2 nicht unterstützt. In Schritt 2 finden Sie Versionsanforderungen und Links zum Update.

    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, muss ein Neustart durchgeführt werden, damit es wirksam wird. Starten Sie den Computer neu, und wiederholen Sie den Vorgang.

  • Fehler: WSL 2 erfordert ein Update der zugehörigen Kernel-Komponente. Weitere Informationen finden Sie unter https://aka.ms/wsl2kernel.

    • Wenn das Linux-Kernelpaket im Ordner „%SystemRoot%\system32\lxss\tools“ fehlt, wird tritt dieser Fehler auf. Lösen Sie dieses Problem, indem Sie das MSI-Updatepaket für den Linux-Kernel (siehe Schritt 4 dieser Installationsanleitung) installieren. Sie müssen den MSI möglicherweise über Software deinstallieren und dann erneut installieren.

Allgemeine Probleme

Ich verwende Windows 10, Version 1903, und es werden trotzdem keine Optionen für WSL 2 angezeigt

Dies liegt wahrscheinlich daran, dass auf Ihrem Computer der Backport für WSL 2 noch nicht eingerichtet ist. Die einfachste Möglichkeit zur Lösung des Problems besteht darin, zu den Windows-Einstellungen zu wechseln und auf „Nach Updates suchen“ zu klicken, um die neuesten Updates auf Ihrem System zu installieren. Schauen Sie sich die vollständigen Anweisungen zur Einrichtung des Backports finden an.

Wenn Sie auf „Nach Updates suchen“ klicken und das Update immer noch nicht erhalten, können Sie KB4566116 manuell installieren.

„Fehler: 0x1bc wenn wsl --set-default-version 2

Dies kann vorkommen, wenn die Einstellung „Anzeigesprache“ oder „Systemgebietsschema“ nicht auf Englisch festgelegt ist.

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

Der tatsächliche Fehler für 0x1bc lautet:

WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel

Weitere Informationen finden Sie im Problem 5749.

Kein Zugriff auf WSL-Dateien von Windows aus möglich

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

Um dies zu überprüfen, können Sie die Startprotokolle mit dmesg |grep 9p überprüfen. Dadurch werden Fehler angezeigt. 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 Problem finden Sie in diesem GitHub-Thread.

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

Wenn Ihre Anzeigesprache nicht Englisch ist, sehen Sie möglicherweise eine abgeschnittene Version eines Fehlertexts.

C:\Users\me>wsl
WSL 2

Um dieses Problem zu beheben, navigieren Sie zu https://aka.ms/wsl2kernel, und installieren Sie den Kernel manuell, indem Sie die Anweisungen auf der doc-Seite befolgen.

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

Benutzer können ausführbare Windows-Programmdateien wie „notepad.exe“ direkt aus Linux ausführen. Manchmal kann es vorkommen, dass "Befehl nicht gefunden" angezeigt wird, wie unten dargestellt:

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

Wenn es keine Win32-Pfade in Ihrem $PATH gibt, findet interop die EXE-Datei nicht. Sie können dies überprüfen, indem Sie echo $PATH in Linux ausführen. In der Ausgabe sollte ein Win32-Pfad (z. B. „/mnt/c/Windows“) angezeigt werden. Werden keine Windows-Pfade angezeigt, wird Ihr PATH höchstwahrscheinlich von Ihrer Linux-Shell außer Kraft gesetzt.

Im folgenden Beispiel hat „/etc/profile“ auf Debian zu diesem Problem beigetragen:

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

Die richtige Vorgehensweise unter Debian besteht darin, die obigen Zeilen zu entfernen. Sie können auch $PATH während der Zuweisung anhängen, wie unten beschrieben, aber das 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 den Problemen 5296 und 5779.

„Error: 0x80370102 Der virtuelle Computer konnte nicht gestartet werden, weil ein erforderliches Feature nicht installiert ist.“

Aktivieren Sie das Windows-Feature "Virtual Machine Platform", und stellen Sie sicher, dass Virtualisierung im BIOS aktiviert ist.

  1. Klicken Sie auf Systemanforderungen von Hyper-V.

  2. Wenn es sich bei dem 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 Sie <VMName> mit den Namem 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 zu erfahren, wie Sie die Virtualisierung aktivieren. Dadurch müssen Sie möglicherweise den System-BIOS verwenden, um sicherzustellen, dass diese Features auf Ihrer CPU aktiviert sind. Die Anweisungen für diesen Prozess können von Computer zu Computer variieren. In diesem Artikel von Bleeping Computer finden Sie ein Beispiel.

  4. Starten Sie den Computer neu, nachdem Sie die optionale Virtual Machine Platform-Komponente aktiviert haben.

  5. Vergewissern Sie sich, 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 Sie hypervisorlaunchtype Off sehen, ist der Hypervisor deaktiviert. Zum Aktivieren führen Sie dies in einer PowerShell mit erhöhten Rechten aus:

     bcdedit /set hypervisorlaunchtype Auto

  6. Wenn Sie Hypervisoren von Drittanbietern installiert haben (z. B. VMware oder VirtualBox), müssen Sie außerdem sicherstellen, dass Sie die neuesten Versionen verwenden, die HyperV unterstützen (VMware 15.5.5+ und VirtualBox 6+), oder dass diese deaktiviert sind.

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

Erfahren Sie mehr über das Konfigurieren der geschachtelten Virtualisierung beim Ausführen von Hyper-V auf einem virtuellen Computer.

WSL hat auf meinem Arbeitsrechner oder in einer Unternehmensumgebung keine Netzwerkverbindung

In Geschäfts- oder Unternehmensumgebungen sind möglicherweise Einstellungen für die Windows Defender Firewall konfiguriert, um nicht autorisierten Netzwerkdatenverkehr zu blockieren. Wenn das Zusammenführen lokaler Regeln auf „Nein“ festgelegt ist, kann das WSL-Netzwerk standardmäßig nicht verwendet werden, und Ihr Administrator muss eine Firewallregel hinzufügen, um die Verbindung zuzulassen.

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

Screenshot: Windows Firewall-Einstellungen

  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 in dem neu geöffneten Fenster die Registerkarte „Öffentliches Profil“ aus.
  5. Wählen Sie im Abschnitt „Einstellungen“ die Option „Anpassen“ aus.
  6. Vergewissern Sie sich in dem anschließend geöffneten Fenster „Einstellungen für das öffentliche Profil anpassen“, ob „Regelzusammenführung“ auf „Nein“ festgelegt ist. Dadurch wird der Zugriff auf WSL blockiert.

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

WSL hat nach dem Herstellen einer Verbindung mit einem VPN keine Netzwerkkonnektivität

Wenn Bash nach dem Herstellen einer Verbindung mit einem VPN unter Windows die Netzwerkkonnektivität verliert, können Sie diese Problemumgehung innerhalb von Bash versuchen. Mit dieser Problemumgehung können Sie die DNS-Auflösung manuell durch /etc/resolv.conf außer Kraft setzen.

  1. Notieren Sie sich den DNS-Server des VPN (ipconfig.exe /all).
  2. Erstellen Sie eine Kopie der vorhandenen Datei „resolv.conf“ (sudo cp /etc/resolv.conf /etc/resolv.conf.new).
  3. Heben Sie die Verknüpfung der aktuellen Datei „resolv.conf“ auf (sudo unlink /etc/resolv.conf).
  4. sudo mv /etc/resolv.conf.new /etc/resolv.conf
  5. Bearbeiten Sie /etc/wsl.conf, und fügen Sie diesen Inhalt zur Datei hinzu. (Weitere Informationen zu diesem Setup finden Sie in der Konfiguration der erweiterte Einstellungen.)
[network]
generateResolvConf=false
  1. Öffnen Sie /etc/resolv.conf und
    a. Löschen sie die erste Zeile aus der Datei, die einen Kommentar enthält, der die automatische Generation beschreibt.
    b. Fügen Sie den DNS-Eintrag aus (1) oben als ersten Eintrag in der Liste der DNS-Server hinzu.
    c. Schließen Sie die Datei.

Nachdem Sie die Verbindung mit dem VPN getrennt haben, müssen Sie die Änderungen auf /etc/resolv.conf zurücksetzen. Gehen Sie dazu folgendermaßen vor:

  1. cd /etc
  2. sudo mv resolv.conf resolv.conf.new
  3. sudo ln -s ../run/resolvconf/resolv.conf resolv.conf

Cisco Anyconnect VPN-Probleme mit WSL im NAT-Modus

Cisco AnyConnect VPN ändert Routen auf eine Weise, die verhindert, dass NAT funktioniert. Es gibt eine Problemumgehung spezifisch für WSL 2: Siehe Cisco AnyConnect Secure Mobility Client-Administratorhandbuch, Release 4.10 – Problembehandlung von AnyConnect.

WSL-Konnektivitätsprobleme mit VPNs, wenn der Netzwerkmodus „Gespiegelt“ aktiviert ist

Der Netzwerkmodus „Gespiegelt“ 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 der experimentelle networkingMode auf mirrored festgelegt ist, werden die Netzwerkschnittstellen, die Sie unter Windows haben, 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 als nicht kompatibel mit WSL bezeichnet, 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 HttpProxy-Spiegelung in WSL

Die HTTP/S-Proxyspiegelung kann mithilfe der autoProxy-Einstellung im experimentellen Abschnitt der WSL-Konfigurationsdatei konfiguriert werden. Bei der Anwendung dieser Einstellung sind folgende Punkte zu beachten:

  • PAC-Proxy: WSL wird die Einstellung unter Linux durch Festlegen der Umgebungsvariable „WSL_PAC_URL“ konfigurieren. 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, gilt Folgendes für Proxyeinstellungen für Ihre Linux-Distributionen:

  • Die Linux-Umgebungsvariable HTTP_PROXY ist auf einen oder mehrere HTTP-Proxys festgelegt, die in der Windows-HTTP-Proxykonfiguration gefunden werden.
  • Die Linux-Umgebungsvariable ist auf einen oder mehrere HTTPHTTPS_PROXYS-Proxys festgelegt, die in der Windows-HTTP-Proxykonfiguration gefunden werden.
  • Die Linux-Umgebungsvariable NO_PROXY ist so festgelegt, dass alle HTTP/S-Proxys umgangen werden, die in den Windows-Konfigurationszielen gefunden werden.
  • Jede Umgebungsvariable mit Ausnahme von WSL_PAC_URL ist sowohl auf Groß- als auch auf Kleinschreibung festgelegt. Beispiel: HTTP_PROXY und http_proxy.

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

Netzwerküberlegungen 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 mithilfe eines Virtualisierungsfeatures für die direkte Kommunikation mit Windows behoben, 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, ein bestimmtes Firewallsetup oder andere Netzwerkkonfigurationen verfügen.

DNS-Tunneling kann mithilfe der dnsTunneling-Einstellung im experimentellen Abschnitt der WSL-Konfigurationsdatei konfiguriert werden. Bei der Anwendung dieser Einstellung sind folgende Punkte zu beachten:

  • Native Docker können Konnektivitätsprobleme in WSL haben, wenn DNS-Tunneling aktiviert ist – wenn das Netzwerk über eine Richtlinie zum Blockieren des DNS-Datenverkehrs zu 8.8.8.8.8 verfügt
  • Wenn Sie ein VPN mit WSL verwenden, aktivieren Sie die DNS-Tunneling. 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 auf 3 DNS-Server, 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 wird Windows-DNS-Suffixe in der folgenden Reihenfolge (ähnlich der Reihenfolge, die vom Windows-DNS-Client verwendet wird) verwenden:
    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, DoT in Linux deaktivieren wollen, müssen sie DNS-Tunneling deaktivieren.
  • DNS-Abfragen von Docker-Containern (entweder Docker Desktop oder native Docker, die in WSL ausgeführt werden) werden DNS-Tunneling umgehen. DNS-Tunneling kann nicht genutzt werden, um Host-DNS-Einstellungen und -Richtlinien auf Docker-DNS-Datenverkehr anzuwenden.
  • Docker Desktop hat eine eigene Methode (anders als DNS-Tunneling) zum Anwenden von Host-DNS-Einstellungen und -Richtlinien auf DNS-Abfragen von Docker-Containern.

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

Probleme beim Steuern des eingehenden Datenverkehrs, der vom Windows-Host empfangen wird, zur WSL-VM

Bei Verwendung des Netzwerkmodus „Gespiegelt“ (der experimentelle networkingMode ist auf mirrored festgelegt) wird ein Teil des eingehenden Datenverkehrs, der vom Windows-Host empfangen wird, niemals auf die Linux-VM geleitet. Dieser Datenverkehr ist wie folgt:

  • UDP-Port 68 (DHCP)
  • TCP-Port 135 (DCE-Endpunktauflösung)
  • UDP-Port 5353 (mDNS)
  • 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 wird bei Verwendung des gespiegelten Netzwerkmodus automatisch bestimmte Linux-Netzwerkeinstellungen konfigurieren. Alle Benutzerkonfigurationen dieser Einstellungen werden beim Verwenden des gespiegelten Netzwerkmodus nicht unterstützt. Hier ist die Liste der Einstellungen, die WSL konfigurieren wird:

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)
disable_ipv6 Deaktiviert (0)
https://sysctl-explorer.net/net/ipv4/arp_filter/ Aktiviert (1)

Probleme mit Docker-Containern in WSL2 mit aktiviertem Netzwerkmodus „Gespiegelt“, wenn sie unter dem Standard-Netzwerknamespace ausgeführt werden

Es gibt ein bekanntes Problem, bei dem Docker Desktop-Container mit veröffentlichten Ports (docker run –publish/-p) nicht erstellt werden können. 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 „--network host“ fest, die im Befehl „docker run“ verwendet wird. Eine alternative Problemumgehung besteht darin, die veröffentlichte Portnummer in der ignoredPorts-Einstellung des experimentellen Abschnitts in der WSL-Konfigurationsdatei aufzulisten.

DNS-Suffixe in WSL

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

Wenn networkingMode auf NAT festgelegt ist:

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

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

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 widergespiegelt

Fall 3) Wenn DNS-Tunneling deaktiviert ist und der SharedAccess-DNS-Proxy deaktiviert ist (dnsTunneling ist in .wslconfig auf false und dnsProxy auf false gesetzt), wird unter Linux in der Einstellung „domain“ von /etc/resolv.conf ein einziger DNS-Suffix konfiguriert

Wenn es eine Änderung in den Windows-DNS-Suffixen gibt, wird diese Änderung nicht in Linux widergespiegelt

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.

Wenn networkingMode auf Mirrorred festgelegt ist:

Alle Windows-DNS-Suffixe sind in Linux konfiguriert, in der Einstellung „search“ von /etc/resolv.conf

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 widergespiegelt

Hinweis: Ergänzende DNS-Suffixe können in Windows mit SetInterfaceDnsSettings - Win32-Apps konfiguriert werden | Microsoft Learn mit dem Flag DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST, das im Parameter Einstellungen festgelegt ist

Problembehandlung bei 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 Eine Richtlinie pushen, die keine lokal definierten Firewallregeln zulässt, und nur unternehmensrichtliniendefinierte Regeln zulassen.

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 drei Profile angezeigt werden: Domain, Privat und Öffentlich. Wenn es für ein Profil festgelegt ist, werden Pakete blockiert, wenn dem Profil die WSL-vNIC zugewiesen ist (Standardeinstellung ist Öffentlich). 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 means the locally defined firewall rules, like that by HNS, will not be applied or used.

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

Diese Einstellungen haben Vorrang vor allen Firewallregeln, die den Eingang zulassen. 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 werden. Diese Einstellung blockiert immer den NAT-DNS-Proxy.

Aus Gruppenrichtlinie:

Computerkonfiguration \ Administrative Vorlagen \ Netzwerk \ Netzwerkverbindungen \ Windows Defender Firewall \ Domainprofil | Standardprofil

„Windows Defender Firewall: Keine Ausnahmen zulassen“ – Aktiviert

Aus MDM-Richtlinie:

./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/Shielded

./Vendor/MSFT/Firewall/MdmStore/DomainProfile/Shielded

./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 means that no inbound Firewall rules will be applied.

3. Ein Benutzer durchläuft die Windows-Sicherheit Einstellungs-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 Benutzer-Opt-In für dieselbe Einstellung, die von einem Enterprise-Element angewendet werden kann, auf das oben in #2 verwiesen wird. Benutzer können die Einstellungsseite „Windows-Sicherheit“ öffnen, die Option „Firewall & Netzwerkschutz“ auswählen, das Firewallprofil auswählen, das sie konfigurieren möchten (Domain, Privat oder Öffentlich), und unter „Eingehende Verbindungen“ das Steuerelement mit der Bezeichnung „Blockiert alle eingehenden Verbindungen, einschließlich derjenigen in der Liste der zulässigen Apps“ aktivieren.

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 ist dies nicht leicht zu erkennen, aber es gibt eine einfache Lösung dafür:

  • 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 wie MDAG oder Windows-Sandbox verwendet wird, sollten diese ebenfalls beendet werden.

    hnsdiag.exe delete all

  • Starten oder rebooten Sie den HNS-Dienst neu

    Restart-Service hns

  • Wenn WSL neu gestartet wird, erstellt HNS neue Firewallregeln, die korrekt auf die WSL-Schnittstelle ausgerichtet sind.

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: „sc queryex FSE“. Wenn FSE nicht ausgeführt wird, überprüfen Sie, ob der PortTrackerEnabledMode-Registrierungswert unter diesem Registrierungsschlüssel vorhanden ist: reg query 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 Phantom-Adaptern

Ghost-Adapter, die auch als Phantom-Plug-and-Play-Geräte (PnP) bezeichnet werden, 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. Navigieren Sie zu „Anzeigen“ > „Ausgeblendete Geräte anzeigen“.

Screenshot des Menüs „Ausgeblendete Geräte“ des Geräte-Managers

  1. Öffnen Sie die Option „Netzwerkadapter“.

Screenshot der Liste der Netzwerkadapter

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

Screenshot des Rechtsklicks auf einen Phantom pnp aus der Netzwerkliste und Auswählen des Deinstallationsgeräts

Beim Starten von WSL oder beim Installieren einer Distribution 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 einzureichen.

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 den Befehl wsl --update in PowerShell oder CMD.

  2. Um die spezifischen Benutzerbinärdateien der Linux-Verteilung zu aktualisieren, verwenden Sie den Befehl apt-get update | apt-get upgrade in der Linux-Verteilung, die Sie aktualisieren möchten.

Apt-get-Upgradefehler

In einigen Paketen werden Features verwendet, die noch nicht implementiert wurden. udev wird z.B. noch nicht unterstützt und verursacht mehrere apt-get upgrade-Fehler.

Führen Sie die folgenden Schritte aus, um Probleme im Zusammenhang mit udev zu beheben:

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

    #!/bin/sh
exit 101

  2. Fügen Sie /usr/sbin/policy-rc.d Ausführungsberechtigungen hinzu:

    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

„Error: 0x80040306“ bei der Installation

Dies hat mit der Tatsache zu tun, dass die Legacykonsole nicht unterstützt wird. So deaktivieren Sie die Legacykonsole:

  1. Öffnen Sie „cmd. exe“.
  2. Klicken Sie mit der rechten Maustaste auf der Titelleiste auf „Eigenschaften“. Deaktivieren Sie die Option „Legacykonsole verwenden“.
  3. Auf "OK" klicken

„Error: 0x80040154“ nach Windows-Update

Das Feature „Windows-Subsystem für Linux“ ist möglicherweise während eines Windows-Updates deaktiviert. Wenn dies der Fall ist, muss das Windows-Feature erneut aktiviert werden. Anweisungen zum Aktivieren des Windows-Subsystems für Linux finden Sie im Leitfaden zur manuellen Installation.

Ändern der Anzeigesprache

Die WSL-Installation versucht, das Ubuntu-Gebietsschema automatisch so zu ändern, dass es dem Gebietsschema Ihrer Windows-Installation entspricht. Wenn Sie dieses Verhalten nicht wünschen, können Sie diesen Befehl ausführen, um das Ubuntu-Gebietsschema zu ändern, nachdem die Installation abgeschlossen wurde. Sie müssen „bash.exe“ neu starten, damit diese Änderung wirksam wird.

Im folgenden Beispiel wird das Gebietsschema in en-US geändert:

sudo update-locale LANG=en_US.UTF8

Installationsprobleme nach der Windows-Systemwiederherstellung

  1. Löschen Sie den Ordner %windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux.
    Hinweis: Unterlassen Sie dies, wenn Ihre optionale Funktion vollständig installiert und funktionsfähig ist.
  2. Aktivieren Sie das optionale WSL-Feature (falls 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 sieht es so aus, als ob bereits die Installation der Firewall den Zugriff blockiert.

Wenn Sie Microsoft Defender Firewall verwenden, wird der Zugriff durch Deaktivieren des Kontrollkästchens „Blockiert alle eingehenden Verbindungen, einschließlich der in der Liste zugelassener Apps“ ermöglicht.

Fehler des Typs „Berechtigung verweigert“ bei Verwendung von Ping

Für Windows Anniversary Update, Version 1607, sind Administratorberechtigungen in Windows erforderlich, um Ping in WSL auszuführen. Um Ping auszuführen, führen Sie Bash unter Ubuntu unter Windows als Administrator aus, oder starten Sie „bash.exe“ über eine CMD-/PowerShell-Eingabeaufforderung mit Administratorrechten.

Für spätere Versionen von Windows, ab Build 14926, sind Administratorberechtigungen nicht mehr erforderlich.

Bash reagiert nicht

Wenn Sie beim Arbeiten mit Bash feststellen, dass Bash hängt (oder blockiert ist) und nicht mehr auf Eingaben reagiert, helfen Sie uns, das Problem zu diagnostizieren, indem Sie ein Speicherabbild erfassen und melden. Beachten Sie, dass diese Schritte zu einem Absturz Ihres Systems führen. Unterlassen Sie dies, wenn Sie damit nicht einverstanden sind, oder speichern Sie Ihre Arbeit zuvor.

So erfassen Sie ein Speicherabbild

  1. Ändern Sie den Typ des Speicherabbilds in „Vollständiges Speicherabbild“. Notieren Sie sich den aktuellen Typ, bevor Sie den Speicherabbildtyp ändern.

  2. Verwenden Sie diese Schritte zum Konfigurieren von Abstürzen mithilfe der Tastatursteuerung.

  3. Reproduzieren Sie das Hängen oder die Blockade.

  4. Lassen Sie das System mithilfe der Tastensequenz aus (2) abstürzen.

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

  6. Nachdem das System neu gestartet wurde, übermitteln Sie die Datei „memory.dmp“ an secure@microsoft.com. Der Standardspeicherort der Speicherabbilddatei ist „%SystemRoot%\memory.dmp“ oder „C:\Windows\memory.dmp“, wenn „C:“ das Systemlaufwerk ist. Geben Sie in der E-Mail an, dass das Speicherabbild für das WSL- oder Bash unter Windows-Team vorgesehen ist.

  7. Stellen Sie die ursprünglichen Einstellung für den Speicherabbildtyp wieder her.

Überprüfen der Buildnummer

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

Suchen Sie nach den Feldern Betriebssystembuild und Systemtyp.
Screenshot: die Felder „Build“ und „Systemtyp“

Führen Sie Folgendes in PowerShell aus, um die Windows Server-Buildnummer zu ermitteln:

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

Verbindungsprobleme des OpenSSH-Servers

Beim Versuch, den SSH-Server zu verbinden, tritt ein Fehler auf: „Connection closed by 127.0.0.1 port 22“ (Verbindung wurde durch 127.0.0.1 Port 22 geschlossen).

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

    sudo service ssh status

    und Sie dieses Tutorial befolgt haben: 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 wie die folgenden angezeigt werden:

    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 neu generieren oder openssh-server einfach bereinigen und installieren:

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

„Die Assembly, auf die verwiesen wird, wurde nicht gefunden.“ beim Aktivieren des optionalen WSL-Features

Dieser Fehler bezieht sich auf einen fehlerhaften Installationsstatus. Führen Sie die folgenden Schritte aus, um eine Behebung dieses Problems zu versuchen:

  • Wenn Sie den Befehl zum Aktivieren des WSL-Features aus PowerShell ausführen, versuchen Sie stattdessen, die grafische Benutzeroberfläche zu verwenden, indem Sie das Startmenü öffnen, nach „Windows-Features aktivieren oder deaktivieren“ 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 dann auf „Nach Updates suchen“ klicken

  • Wenn beide Versuche erfolglos bleiben und Sie auf WSL zugreifen müssen, erwägen Sie, ein lokales Upgrade auszuführen, indem Sie Windows mithilfe der Installationsmedien erneut installieren und „Alles beibehalten“ auswählen, um sicherzustellen, dass Ihre Apps und Dateien erhalten bleiben. Anweisungen dazu finden Sie auf der Seite Erneutes Installieren von Windows 10.

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

Beachten Sie, dass durch Hinzufügen dieses Befehls Metadaten hinzugefügt und die in WSL angezeigten Dateiberechtigungen für die Windows-Dateien geändert werden. Weitere Informationen finden Sie in den Dateisystemberechtigungen.

Fehler bei der Remoteverwendung von WSL mithilfe von OpenSSH unter Windows

Wenn Sie „openssh-server“ unter Windows verwenden und versuchen, remote auf WSL zuzugreifen, sehen Sie möglicherweise folgenden Fehler:

The file cannot be accessed by the system.

Es handelt sich um ein bekanntes Problem, wenn Sie die Store-Version von WSL verwenden. Sie können dies derzeit umgehen, indem Sie WSL 1 oder die in Windows enthaltene Version von WSL verwenden. Weitere Informationen finden Sie unter https://aka.ms/wslstoreinfo.

Fehler beim Ausführen von Windows-Befehlen innerhalb einer Verteilung

Einige im Microsoft Store verfügbare Verteilungen sind noch nicht vollständig kompatibel, um Windows-Befehle sofort auszuführen. Wenn Sie beim Ausführen von powershell.exe /c start . oder eines anderen Windows-Befehls der Fehler -bash: powershell.exe: command not found angezeigt wird, können Sie ihn mit den folgenden Schritten beheben:

  1. Führen Sie echo $PATH in Ihrer WSL-Verteilung aus.
    Wenn /mnt/c/Windows/system32 nicht enthalten ist, wird die PATH-Standardvariable von irgendeiner Komponente neu definiert.
  2. Prüfen Sie die Profileinstellungen mit cat /etc/profile.
    Ist die Zuweisung der PATH-Variablen enthalten, bearbeiten Sie die Datei, um den PATH-Zuweisungsblock mit einem # -Zeichen auszukommentieren.
  3. Prüfen Sie, ob „wsl.conf“ vorhanden ist (cat /etc/wsl.conf), und stellen Sie sicher, dass appendWindowsPath=false nicht enthalten ist. Andernfalls kommentieren Sie es aus.
  4. Starten Sie die Verteilung neu, indem Sie wsl -t eingeben, gefolgt vom Namen der Verteilung, oder indem Sie wsl --shutdown entweder in cmd oder PowerShell ausführen.

Starten nach der Installation von WSL 2 nicht möglich

Es ist ein Problem bekannt, das Benutzer betrifft, wenn Sie nach der Installation von WSL 2 nicht starten können. Während unserer umfassenden Diagnose dieser Probleme haben Benutzer berichtet, dass das Ändern der Puffergröße oder das Installieren der richtigen Treiber helfen kann, dieses Problem zu beheben. Im folgenden GitHub-Artikel finden Sie die neuesten Updates zu diesem Problem.

WSL 2-Fehler, wenn ICS deaktiviert ist

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

Das Deaktivieren des ICS-Dienstes (SharedAccess) oder das Deaktivieren von ICS über eine Gruppenrichtlinie verhindert, dass das WSL HNS-Netzwerk erstellt wird. Dies führt zu Fehlern beim Erstellen eines neuen WSL Version 2-Images und dem folgenden Fehler beim Versuch, ein Image der Version 1 in Version 2 zu konvertieren.

There are no more endpoints available from the endpoint mapper.

Systeme, für die WSL 2 erforderlich ist, sollten den ICS-Dienst (SharedAccess) im Standardstartstatus „Manuell“ (Start durch Auslöser) belassen, und alle Richtlinien, die ICS deaktivieren, sollten außer Kraft gesetzt oder entfernt werden. Beim Deaktivieren des ICS-Diensts wird die Ausführung von WSL 2 abgebrochen, daher wird von der Deaktivierung von ICS abgeraten. Eine teilweise Deaktivierung von ICS ist anhand dieser Anweisungen möglich.

Verwenden älterer Versionen von Windows und WSL

Es gibt mehrere Unterschiede, die SIe beachten sollten, wenn Sie eine ältere Version von Windows und WSL ausführen, z. B. Windows 10 Creators Update (Oktober 2017, Build 16299) oder Anniversary Update (August 2016, Build 14393). Es wird empfohlen, auf die neueste Windows Version zu aktualisieren. Wenn dies jedoch nicht möglich ist, werden nachfolgend einige der Unterschiede beschrieben.

Unterschiede bei Interoperabilitätsbefehlen:

  • bash.exe wurde durch wsl.exe ersetzt. Linux-Befehle können an der Windows-Eingabeaufforderung oder in PowerShell ausgeführt werden. Für frühe Windows-Versionen müssen Sie jedoch möglicherweise den Befehl bash verwenden. Beispiel: C:\temp> bash -c "ls -la". Die an bash -c übergebenen WSL-Befehle werden ohne Änderung an den WSL-Prozess weitergeleitet. Dateipfade müssen im WSL-Format angegeben werden, und es muss darauf geachtet werden, dass relevante Zeichen mit Escapezeichen versehen werden. Beispiel: C:\temp> bash -c "ls -la /proc/cpuinfo" oder C:\temp> bash -c "ls -la \"/mnt/c/Program Files\"".
  • Um anzuzeigen, welche Befehle für eine bestimmte Distribution verfügbar sind, führen Sie [distro.exe] /? aus. Beispielsweise mit Ubuntu: C:\> ubuntu.exe /?.
  • Der Windows-Pfad ist in $PATH von WSL enthalten.
  • Wenn Sie ein Windows-Tool aus einer WSL-Verteilung in einer früheren Version von Windows 10 aufrufen, müssen Sie den Verzeichnispfad angeben. Geben Sie beispielsweise Folgendes ein, um die Windows Editor-App über die WSL-Befehlszeile aufzurufen: /mnt/c/Windows/System32/notepad.exe.
  • Um den Standardbenutzer in root zu ändern, verwenden Sie in PowerShell den Befehl C:\> lxrun /setdefaultuser root, und führen Sie dann „Bash.exe“ aus, um sich anzumelden: C:\> bash.exe. Setzen Sie Ihr Kennwort mit dem Kennwortbefehl der Verteilung $ passwd username zurück, und schließen Sie die Linux-Befehlszeile: $ exit. Setzen Sie ihren Standardbenutzer über die Windows-Eingabeaufforderung oder PowerShell wieder auf Ihr normales Linux-Benutzerkonto zurück: C:\> lxrun.exe /setdefaultuser username.

Deinstallieren der Vorgängerversion von WSL

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