Dela via

Felsöka Windows-undersystem för Linux

Vi har gått igenom några vanliga felsökningsscenarier som är associerade med WSL nedan, men överväg att söka i de problem som finns i WSL-produktrepo på GitHub också.

Skapa ett problem, felrapport, funktionsbegäran

Funktionerna i WSL-produktens lagringsplats ger dig möjlighet att:

  • Sök efter befintliga frågor för att se om det finns några som är kopplade till problem som du upplever. Observera att du i sökfältet kan ta bort "is:open" för att inkludera problem som redan har lösts i sökningen. Överväg att kommentera eller ge tummen upp till eventuella öppna ärenden som du vill uttrycka ditt intresse för att få prioriterade.
  • Skapa ett nytt problem. Om du har hittat ett problem med WSL och det inte verkar finnas något befintligt problem kan du välja den gröna knappen Nytt problem och sedan välja WSL – Felrapport. Du måste ta med en rubrik för problemet, ditt Versionsnummer för Windows (kör cmd.exe /c ver för att se din aktuella version #), oavsett om du kör WSL 1 eller 2, din aktuella Linux Kernel-version # (kör wsl.exe --status eller cat /proc/version), version # av distributionen (kör lsb_release -r), eventuella andra programvaruversioner som ingår, repro-stegen, förväntat beteende, faktiskt beteende, diagnostikloggar om det är tillgängligt och lämpligt. För mer information, se om WSL-.
  • Skicka en funktionsbegäran genom att välja den gröna knappen Nytt problem och sedan välja funktionsbegäran. Du måste besvara några frågor som beskriver din begäran.

Du kan också:

  • Fila ett dokumentationsproblem med hjälp av lagringsplatsen för WSL-dokument. Information om hur du bidrar till WSL-dokumenten finns i deltagarguiden för Microsoft Docs.
  • Anmäl ett Windows Terminal- problem med Windows Terminal-produktens repo om problemet är mer relaterat till Windows Terminal, Windows Console eller kommandoradsgränssnittet.

Installationsproblem

  • Installationen misslyckades med fel 0x80070003

    • Windows-undersystemet för Linux körs bara på systemenheten (vanligtvis är det här din C: enhet). Kontrollera att distributionerna lagras på systemenheten:
    • I Windows 10 öppnar du Inställningar –>System –>Storage –>Fler lagringsinställningar: Ändra var nytt innehåll sparasBild av systeminställningar för att installera appar på C: enhet (Windows 10)
    • I Windows 11 öppnar du Inställningar –>System –>Storage –>Avancerade lagringsinställningar –>Där nytt innehåll sparasBild av systeminställningar för att installera appar på C: enhet (Windows 11)

  • WslRegisterDistribution misslyckades med fel 0x8007019e

    • Den valfria Komponenten Windows-undersystem för Linux är inte aktiverad:
    • Öppna Kontrollpanelen –>program och funktioner –>Aktivera eller inaktivera Windows-funktionen –> Kontrollera Windows-undersystem för Linux eller med powershell-cmdleten som nämns i början av den här artikeln.

  • Installationen misslyckades med fel 0x80070003 eller fel 0x80370102

    • Kontrollera att virtualisering är aktiverat i datorns BIOS. Instruktionerna för hur du gör detta varierar från dator till dator, och kommer sannolikt att finnas under CPU-relaterade alternativ.
    • WSL2 kräver att processorn stöder SLAT-funktionen (Second Level Address Translation), som introducerades i Intel Nehalem-processorer (Intel Core 1:a generationen) och AMD Opteron. Äldre processorer (till exempel Intel Core 2 Duo) kommer inte att kunna köra WSL2, även om den virtuella datorplattformen har installerats.

  • fel vid uppgradering: Invalid command line option: wsl --set-version Ubuntu 2

    • Kontrollera att Windows-undersystemet för Linux är aktiverat och att du använder Windows Build version 18362 eller senare. Om du vill aktivera WSL kör du det här kommandot i en PowerShell-prompt med administratörsbehörighet: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux.

  • Det gick inte att slutföra den begärda åtgärden på grund av en systembegränsning för virtuella diskar. Virtuella hårddiskfiler måste vara okomprimerade och okrypterade och får inte vara glesa.

    • Avmarkera "Komprimera innehåll" (samt "Kryptera innehåll" om det är markerat) genom att öppna profilmappen för Din Linux-distribution. Den bör finnas i en mapp i ditt Windows-filsystem, ungefär som: %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...
    • I den här Linux-distributionsprofilen bör det finnas en LocalState-mapp. Högerklicka på den här mappen om du vill visa en meny med alternativ. Markera Egenskaper > Avancerat och kontrollera sedan att kryssrutorna "Komprimera innehåll för att spara diskutrymme" och "Kryptera innehåll för att skydda data" är avmarkerade (inte markerat). Om du tillfrågas om du bara vill tillämpa detta på den aktuella mappen eller på alla undermappar och filer väljer du "bara den här mappen" eftersom du bara rensar komprimeringsflaggan. Därefter bör kommandot wsl --set-version fungera.

Skärmbild av egenskapsinställningar för WSL-distribution

Not

I mitt fall fanns mappen LocalState för min Ubuntu 18.04-distribution på C:\Users<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc

Kontrollera WSL Docs GitHub-tråd #4103 där det här problemet spåras för uppdaterad information.

  • Termen "wsl" identifieras inte som namnet på en cmdlet, funktion, skriptfil eller ett fungerande program.

  • Fel: Windows-undersystem för Linux har inga installerade distributioner.

    • Om du får det här felet när du redan har installerat WSL-distributioner:
    1. Kör fördelningen minst en gång innan du anropar den från kommandoraden.
    2. Kontrollera om du kan köra separata användarkonton. Att köra ditt primära användarkonto med utökade behörigheter (i administratörsläge) bör inte resultera i det här felet, men du bör se till att du inte av misstag kör det inbyggda administratörskontot som medföljer Windows. Det här är ett separat användarkonto och visar inga installerade WSL-distributioner avsiktligt. Mer information finns i Aktivera och inaktivera det inbyggda administratörskontot.
    3. Den körbara WSL-filen installeras endast i den interna systemkatalogen. När du kör en 32-bitarsprocess i 64-bitars Windows (eller på ARM64, alla icke-interna kombinationer) ser den värdbaserade icke-interna processen faktiskt en annan System32-mapp. (Den som en 32-bitarsprocess ser på x64 Windows lagras på disken på \Windows\SysWOW64.) Du kan komma åt det "ursprungliga" system32 från en värdbaserad process genom att titta i den virtuella mappen: \Windows\sysnative. Det kommer faktiskt inte att finnas på disken, men filsystemets sökvägslösare hittar den.

  • Fel: Den här uppdateringen gäller endast för datorer med Windows-undersystemet för Linux.

    • För att installera MSI-paketet för Linux-kerneluppdatering krävs WSL och bör aktiveras först. Om det misslyckas visas meddelandet: This update only applies to machines with the Windows Subsystem for Linux.
    • Det finns tre möjliga orsaker till att du ser det här meddelandet:

    1. Du är fortfarande i den gamla versionen av Windows som inte stöder WSL 2. Se steg 2 för versionskrav och länkar för uppdatering.

    2. WSL är inte aktiverat. Du måste återgå till steg 1 och se till att den valfria WSL-funktionen är aktiverad på datorn.

    3. När du har aktiverat WSL krävs en omstart för att den ska börja gälla, starta om datorn och försök igen.

  • Fel: WSL 2 kräver en uppdatering av dess kernelkomponent. Mer information finns i https://aka.ms/wsl2kernel .

    • Om Linux-kernelpaketet saknas i mappen %SystemRoot%\system32\lxss\tools visas det här felet. Lös det genom att installera MSI-paketet för Linux-kerneluppdatering i steg 4 i de här installationsanvisningarna. Du kan behöva avinstallera MSI från Lägg till eller ta bort programoch installera det igen.

Vanliga problem

Jag är på Windows 10 version 1903 och jag fortfarande inte ser alternativ för WSL 2

Detta beror troligen på att datorn ännu inte har tagit backporten för WSL 2. Det enklaste sättet att lösa detta är genom att gå till Windows-inställningar och klicka på "Sök efter uppdateringar" för att installera de senaste uppdateringarna i systemet. Läs de fullständiga instruktionerna för hur du installerar backporten.

Om du trycker på Sök efter uppdateringar och fortfarande inte får uppdateringen kan du installera KB KB4566116 manuellt.

Fel: 0x1bc när wsl --set-default-version 2

Detta kan inträffa när inställningen "Visningsspråk" eller "Systemspråk" inte är engelska.

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

Det faktiska felet för 0x1bc är:

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

Mer information finns i ärende 5749

Det går inte att komma åt WSL-filer från Windows

En 9p-protokollfilserver tillhandahåller tjänsten på Linux-sidan så att Windows kan komma åt Linux-filsystemet. Om du inte kan komma åt WSL med hjälp av \\wsl$ i Windows kan det bero på att 9P inte startade korrekt.

Om du vill kontrollera detta kan du kontrollera startloggarna med hjälp av: dmesg |grep 9p, och då visas eventuella fel. Ett lyckat resultat ser ut så här:

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

Se den här GitHub-tråden för vidare diskussion om det här problemet.

Det går inte att starta WSL 2-distributionen och bara se "WSL 2" i utdata

Om ditt visningsspråk inte är engelska är det möjligt att du ser en trunkerad version av en feltext.

C:\Users\me>wsl
WSL 2

Lös problemet genom att gå till https://aka.ms/wsl2kernel och installera kerneln manuellt genom att följa anvisningarna på den dokumentsidan.

command not found vid körning av Windows .exe i Linux

Användare kan köra körbara Windows-filer som notepad.exe direkt från Linux. Ibland kan du trycka på "kommandot hittades inte" som nedan:

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

Om det inte finns några Win32-sökvägar i $PATH kommer inte interop att hitta .exe. Du kan verifiera det genom att köra echo $PATH i Linux. Du förväntas se en Win32-sökväg (till exempel /mnt/c/Windows) i utdata. Om du inte kan se några Windows-sökvägar är det troligt att din PATH skrivs över av Linux-gränssnittet.

Här är ett exempel som /etc/profile på Debian bidrog till problemet:

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

Det rätta sättet på Debian är att ta bort ovanstående rader. Du kan också lägga till $PATH under tilldelningen som nedan, men detta leder till vissa andra problem med WSL och 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

Mer information finns i ärende 5296 och ärende 5779.

"Fel: 0x80370102 Det gick inte att starta den virtuella datorn eftersom en nödvändig funktion inte är installerad."

Aktivera Windows-funktionen Virtual Machine Platform och se till att virtualisering är aktiverad i BIOS.

  1. Kontrollera Hyper-V systemkraven

  2. Om datorn är en virtuell dator aktiverar du kapslad virtualisering manuellt. Starta powershell med administratör och kör följande kommando och ersätt <VMName> med namnet på den virtuella datorn i värdsystemet (du hittar namnet i Hyper-V Manager):

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

  3. Följ riktlinjerna från datorns tillverkare om hur du aktiverar virtualisering. I allmänhet kan detta innebära att du använder systemets BIOS för att säkerställa att dessa funktioner är aktiverade på processorn. Anvisningar för den här processen kan skilja sig åt mellan olika datorer, se den här artikeln från Bleeping Computer för ett exempel.

  4. Starta om datorn när du har aktiverat den Virtual Machine Platform valfria komponenten.

  5. Kontrollera att hypervisor-starten är aktiverad i startkonfigurationen. Du kan verifiera detta genom att köra PowerShell med administrativa rättigheter:

     bcdedit /enum | findstr -i hypervisorlaunchtype

    Om du ser hypervisorlaunchtype Offinaktiveras hypervisor-programmet. Så här aktiverar du den genom att köra den i ett upphöjt powershell:

     bcdedit /set hypervisorlaunchtype Auto

  6. Om du har installerat hypervisor-program från tredje part (till exempel VMware eller VirtualBox) kontrollerar du att du har dessa på de senaste versionerna som kan stödja HyperV (VMware 15.5.5+ och VirtualBox 6+) eller är avstängda.

  7. Om du får det här felet på en virtuell Azure-dator kontrollerar du att Betrodd start är inaktiverad. Kapslad virtualisering stöds inte på virtuella Azure-datorer med betrodd start.

Läs mer om hur du konfigurerar kapslad virtualisering när du kör Hyper-V i en virtuell maskin.

WSL har ingen nätverksanslutning på min arbetsdator eller i en Företagsmiljö

Företags- eller företagsmiljöer kan ha Windows Defender-brandväggsinställningar som konfigurerats för att blockera obehörig nätverkstrafik. Om lokala regel som sammanfogar är inställd på "Nej" fungerar inte WSL-nätverk som standard, och administratören måste lägga till en brandväggsregel för att tillåta det.

Du kan bekräfta inställningen för sammanslagning av lokala regler genom att följa dessa steg:

Windows-brandväggsinställningar skärmbild

  1. Öppna "Windows Defender-brandväggen med avancerad säkerhet" (detta skiljer sig från "Windows Defender-brandväggen" på Kontrollpanelen)
  2. Högerklicka på fliken "Windows Defender-brandväggen med avancerad säkerhet på den lokala datorn"
  3. Välj "Egenskaper"
  4. Välj fliken Offentlig profil i det nya fönstret som öppnas
  5. Välj "Anpassa" under avsnittet "Inställningar"
  6. Kontrollera i fönstret "Anpassa inställningar för den offentliga profilen" som öppnas för att se om "Regelsammanslagningen" är inställd på "Nej". Detta blockerar åtkomsten till WSL.

Du hittar anvisningar om hur du ändrar den här brandväggsinställningen i Konfigurera Hyper-V brandvägg.

WSL har ingen nätverksanslutning när den är ansluten till ett VPN

Om bash förlorar nätverksanslutningen när du har anslutit till ett VPN i Windows kan du prova den här lösningen inifrån bash. Med den här lösningen kan du åsidosätta DNS-matchningen manuellt via /etc/resolv.conf.

  1. Notera DNS-servern för VPN från steg ipconfig.exe /all
  2. Skapa en kopia av den befintliga resolve.conf-sudo cp /etc/resolv.conf /etc/resolv.conf.new
  3. Ta bort kopplingen för den aktuella resolv.conf sudo unlink /etc/resolv.conf
  4. sudo mv /etc/resolv.conf.new /etc/resolv.conf
  5. Redigera /etc/wsl.conf och lägg till det här innehållet i filen. (Mer information om den här konfigurationen finns i Konfiguration av avancerade inställningar)
[network]
generateResolvConf=false
  1. Öppna /etc/resolv.conf och
    a. Ta bort den första raden från filen som har en kommentar som beskriver automatisk generering
    b) Lägg till DNS-posten från (1) ovan som den allra första posten i listan över DNS-servrar.
    Punkt c Stäng filen.

När du har kopplat från VPN måste du återställa ändringarna till /etc/resolv.conf. Gör detta genom att göra:

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

Problem med global säker åtkomstklient med WSL

Den globala klienten för säker åtkomst (/entra/global-secure-access/how-to-install-windows-client) kan påverka WSL-anslutningen eftersom den har en funktion för att returnera en tillfällig adress när ett namn matchas. Sedan växlas adressen till den faktiska adressen när en nätverksanslutning upprättas. Detta kan störa WSL eftersom WSL-trafiken vidarebefordras under många av GSA-klientanknytningarna.

Vi rekommenderar att du inaktiverar DNS-tunnlar (dnsTunneling=false) eller inaktiverar speglat läge (networkingMode=nat).

Cisco Anyconnect VPN-problem med WSL i NAT-läge

Cisco AnyConnect VPN ändrar vägar på ett sätt som hindrar NAT från att fungera. Det finns en lösning som är specifik för WSL 2: Se administratörsguiden för Cisco AnyConnect Secure Mobility Client, version 4.10 – Felsöka AnyConnect.

WSL-anslutningsproblem med VPN när läget för speglat nätverk är aktiverat

Speglat nätverksläge är för närvarande en experimentell inställning i WSL-konfigurationen. Den traditionella NAT-nätverksarkitekturen för WSL kan uppdateras till ett helt nytt nätverksläge med namnet "Speglat nätverksläge". När den experimentella networkingMode är inställd på mirroredspeglas de nätverksgränssnitt som du har i Windows i Linux för att förbättra kompatibiliteten. Läs mer i kommandoradsbloggen: WSL september 2023-uppdatering.

Vissa VPN-nätverk har testats och bekräftats vara inkompatibla med WSL, inklusive:

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

Överväganden vid användning av autoProxy för HttpProxy-spegling i WSL

HTTP/S-proxyspegling kan konfigureras med hjälp av inställningen autoProxy i den experimentella sektionen i WSL-konfigurationsfilen. När du tillämpar den här inställningen bör du tänka på följande:

  • PAC Proxy: WSL konfigurerar inställningen i Linux genom att ange miljövariabeln "WSL_PAC_URL". Linux stöder inte PAC-proxyservrar som standard.
  • Interaktioner med WSLENV: Användardefinierade miljövariabler har företräde framför de som anges av den här funktionen.

När det är aktiverat gäller följande proxyinställningar för dina Linux-distributioner:

  • Miljövariabeln för Linux, HTTP_PROXY, är inställd på en eller flera HTTP-proxyservrar som finns installerade i Windows HTTP-proxykonfigurationen.
  • Miljövariabeln för Linux, HTTPS_PROXY, är inställd på en eller flera HTTP-S- proxyservrar som finns installerade i Windows HTTP-proxykonfigurationen.
  • Miljövariabeln för Linux, NO_PROXY, är inställd på att kringgå alla HTTP/S-proxyservrar som finns i Windows-konfigurationsmålen.
  • Varje miljövariabel, förutom WSL_PAC_URL, anges i både gemener och versaler. Till exempel: HTTP_PROXY och http_proxy.

Det finns ett känt problem som orsakas av ZScaler-konfigurationerna, där ZScaler upprepade gånger aktiverar och inaktiverar Windows-proxykonfigurationer, vilket leder till att WSL upprepade gånger visar meddelandet "En HTTP-proxyändring har identifierats på värden".

Läs mer i kommandoradsbloggen: WSL september 2023-uppdatering.

Nätverksöverväganden med DNS-tunnlar

När WSL inte kan ansluta till Internet kan det bero på att DNS-anropet till Windows-värden är blockerat. Detta beror på att nätverkspaketet för DNS som skickas av den virtuella WSL-datorn till Windows-värden blockeras av den befintliga nätverkskonfigurationen. DNS-tunnlar åtgärdar detta med hjälp av en virtualiseringsfunktion för att kommunicera direkt med Windows, vilket gör att DNS-namnet kan matchas utan att skicka ett nätverkspaket. Den här funktionen bör förbättra nätverkskompatibiliteten och ge dig bättre internetanslutning även om du har ett VPN, en specifik brandväggskonfiguration eller andra nätverkskonfigurationer.

DNS-tunnlar kan konfigureras med inställningen dnsTunneling i den experimentella sektionen i WSL-konfigurationsfilen. När du tillämpar den här inställningen bör du tänka på följande:

  • Om du använder ett VPN med WSL aktiverar du DNS-tunnlar. Många VPN-nätverk använder NRPT-principer, som endast tillämpas på WSL DNS-frågor när DNS-tunneltrafik är aktiverat.
  • Den /etc/resolv.conf filen i Linux-distributionen har en maximal begränsning på 3 DNS-servrar, medan Windows kan använda fler än 3 DNS-servrar. Om du använder DNS-tunnlar tas den här begränsningen bort – alla Windows DNS-servrar kan nu användas av Linux.
  • WSL använder Windows DNS-suffix i följande ordning (liknar den ordning som används av Windows DNS-klienten):
    1. Globala DNS-suffix
    2. Kompletterande DNS-suffix
    3. DNS-suffixer per gränssnitt
    4. Om DNS-kryptering (DoH, DoT) är aktiverat i Windows tillämpas kryptering på DNS-frågor från WSL. Om användarna vill aktivera DoH, DoT i Linux, måste de inaktivera DNS-tunnlar.
  • DNS-frågor från Docker-containrar som hanteras av Docker Desktop kringgår DNS-tunnlar. Docker Desktop har sitt eget sätt (skiljer sig från DNS-tunneltrafik) att tillämpa DNS-värdinställningar och principer på DNS-frågor från Docker-containrar.
  • Alternativet generateResolvConf i filen wsl.conf ska inte inaktiveras för att DNS-tunnlar ska aktiveras på ett lyckat sätt.
  • När DNS-tunneling är aktiverad ignoreras alternativet generateHosts i filen wsl.conf (Windows DNS hosts-fil kopieras inte i Linux-filen /etc/hosts). Principerna i Windows-värdfilen tillämpas på DNS-frågor från Linux, utan att filen behöver kopieras i Linux.

Läs mer i kommandoradsbloggen: WSL september 2023-uppdatering.

Problem med styrning av den inkommande trafik som tas emot av Windows-värden till WSL:s virtuella maskin

När du använder det speglade nätverksläget (den experimentella networkingMode inställd på mirrored) kommer viss inkommande trafik som tas emot av Windows-värden aldrig att styras till den virtuella Linux-datorn. Den här trafiken är följande:

  • UDP-port 68 (DHCP)
  • TCP-port 135 (DCE-ändpunktsupplösning)
  • 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 konfigurerar automatiskt vissa Linux-nätverksinställningar när du använder speglat nätverksläge. Alla användarkonfigurationer av de här inställningarna när du använder speglat nätverksläge stöds inte. Här är listan över inställningar som WSL konfigurerar:

Inställningsnamn Värde
https://sysctl-explorer.net/net/ipv4/accept_local/ Aktiverad (1)
https://sysctl-explorer.net/net/ipv4/route_localnet/ Aktiverad (1)
https://sysctl-explorer.net/net/ipv4/rp_filter/ Inaktiverad (0)
https://sysctl-explorer.net/net/ipv6/accept_ra/ Inaktiverad (0)
https://sysctl-explorer.net/net/ipv6/autoconf/ Inaktiverad (0)
https://sysctl-explorer.net/net/ipv6/use_tempaddr/ Inaktiverad (0)
addr_gen_mode Inaktiverad (0)
inaktivera_ipv6 Inaktiverad (0)
https://sysctl-explorer.net/net/ipv4/arp_filter/ Aktiverad (1)

Problem med Docker-container i WSL2 med läget Speglat nätverk aktiverat när det körs under standardnamnet för nätverk

Det finns ett känt problem där Docker Desktop-containrar med publicerade portar (docker run –publish/-p) inte kan skapas. WSL-teamet arbetar med Docker Desktop-teamet för att åtgärda problemet. Du kan undvika problemet genom att använda värdens nätverksnamnområde i Docker-containern. Ange nätverkstypen via alternativet "--network host" som används i kommandot "docker run". En alternativ lösning är att lista det publicerade portnumret i inställningen ignoredPorts för det experimentella avsnittet i WSL-konfigurationsfilen.

Problem med Docker-containern när nätverkshanteraren körs

Det finns ett känt problem med Docker-containrar som har Network Manager-tjänsten igång. Symtomen är bland annat fel vid försök att upprätta loopbackanslutningar till värddatorn. Vi rekommenderar att du stoppar Network Manager-tjänsten för WSL-nätverk så att den är korrekt konfigurerad.

sudo systemctl disable network-manager.service

Lösa .local-namn i WSL

För att matcha värdnamn till IP-adresser i ett lokalt nätverk utan att behöva en vanlig DNS-server används ofta lokala namn. Detta uppnås via protokollet mDNS (Multicast DNS), som förlitar sig på multicast-trafik för att fungera.

networkingMode inställd på NAT:

Den här funktionen stöds för närvarande inte när DNS-tunnlar är aktiverade. För att möjliggöra upplösning av .local-namn rekommenderar vi följande lösningar:

  • Inaktivera DNS-tunneltrafik.
  • Använd speglat nätverksläge.

nätverksläge inställd på Speglad:

Obs! Du måste ha WSL-version 2.3.17 eller senare för att kunna använda funktionerna nedan.

Eftersom speglingsläge stöder multicast-trafik kan protokollet mDNS (Multicast DNS) användas för att lösa .local-namn. Linux måste konfigureras för att stödja mDNS, eftersom det inte gör det som standard. Ett sätt att konfigurera det är att använda följande två steg:

  1. Installera paketet "libnss-mdns"
sudo apt-get install libnss-mdns

*Paketet "libnss-mdns" är en insticksmodul för funktionaliteten i GNU Name Service Switch (NSS) i GNU C-biblioteket (glibc) som tillhandahåller upplösning av värdnamn via Multicast DNS (mDNS). Det här paketet gör att vanliga Unix/Linux-program kan matcha namn i den ad hoc mDNS-domänen .local.

  1. Konfigurera /etc/nsswitch.conf-filen för att aktivera inställningen "mdns_minimal" i avsnittet "hosts". Exempelinnehåll i filen:
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-suffix i WSL

Beroende på konfigurationerna i .wslconfig-filen har WSL följande beteende med avseende på DNS-suffix:

När networkingMode är inställt på NAT:

Fall 1) Som standard konfigureras inget DNS-suffix i Linux

Fall 2) Om DNS-tunnling är aktiverad (dnsTunneling är inställt på true i .wslconfig) är alla Windows DNS-suffixer konfigurerade i Linux i inställningen "search" för /etc/resolv.conf

Suffixen konfigureras i /etc/resolve.conf i följande ordning, ungefär som i den ordning windows DNS-klienten försöker använda suffix när ett namn matchas: globala DNS-suffix först, sedan kompletterande DNS-suffix och sedan DNS-suffix per gränssnitt.

När det sker en ändring i Windows DNS-suffixen återspeglas den ändringen automatiskt i Linux

Fall 3) Om DNS-tunnlar är inaktiverade och DNS-proxyn SharedAccess är inaktiverad (dnsTunneling är inställt på false och dnsProxy är inställt på false i .wslconfig) konfigureras ett enda DNS-suffix i Linux i inställningen "domän" för /etc/resolve.conf

När det sker en ändring i Windows DNS-suffixen återspeglas inte ändringen i Linux

Det enskilda DNS-suffixet som konfigurerats i Linux väljs från DNS-suffixen per gränssnitt (globala och kompletterande suffix ignoreras)

Om Windows har flera gränssnitt används en heuristisk för att välja det enda DNS-suffix som ska konfigureras i Linux. Om det till exempel finns ett VPN-gränssnitt i Windows väljs suffixet från det gränssnittet. Om det inte finns något VPN-gränssnitt väljs suffixet från det gränssnitt som mest sannolikt ger Internetanslutning.

När networkingMode är inställt på Speglad:

Alla Windows DNS-suffix har konfigurerats i Linux i inställningen "sök" för /etc/resolve.conf

Suffixen konfigureras i /etc/resolve.conf i samma ordning som i fall 2) från NAT-läge

När det sker en ändring i Windows DNS-suffixen återspeglas den ändringen automatiskt i Linux

Obs! Kompletterande DNS-suffix kan konfigureras i Windows med SetInterfaceDnsSettings – Win32-appar | Microsoft Learn, med flaggan DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST i parametern Inställningar

Felsökning av DNS i WSL

Standard-DNS-konfigurationen när WSL startar en container i NAT-läge är att NAT-enheten på Windows-värden ska fungera som DNS-server för WSL-containern. När DNS-frågor skickas från WSL-containern till NAT-enheten på Windows-värden vidarebefordras DNS-paketet från NAT-enheten till tjänsten för delad åtkomst på värddatorn; Svaret skickas i omvänd riktning tillbaka till WSL-containern. Den här paketvidarebefordringsprocessen till delad åtkomst kräver en brandväggsregel för att tillåta det inkommande DNS-paketet, som skapas av HNS-tjänsten när WSL först ber HNS att skapa det virtuella NAT-nätverket för sin WSL-container.

På grund av denna NAT-design för delad åtkomst finns det några kända konfigurationer som kan förhindra namnuppslagning från WSL.

1. Ett företag kan pusha policyer som inte tillåter lokalt definierade brandväggsregler, och endast tillåter regler definierade av företagspolicy.

När detta anges av ett företag ignoreras den HNS-skapade brandväggsregeln eftersom det är en lokalt definierad regel. För att den här konfigurationen ska fungera måste Enterprise skapa en brandväggsregel för att tillåta UDP-port 53 till tjänsten för delad åtkomst, eller så kan WSL anges att använda DNS-tunnlar. Man kan se om detta är konfigurerat för att inte tillåta lokalt definierade brandväggsregler genom att köra följande. Observera att detta visar inställningar för alla tre profiler: Domän, Privat och Offentlig. Om det är inställt på någon profil kommer paket att blockeras om WSL vNIC tilldelas den profilen (standardvärdet är Offentligt). Det här är bara ett kodfragment av den första brandväggsprofilen som returneras i PowerShell:

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. Och Enterprise kan skicka ned inställningar för gruppprincip- och MDM-principer som blockerar alla regler för inkommande anslutningar.

De här inställningarna åsidosätter alla Allow-Inbound brandväggsregel. Den här inställningen blockerar därför den HNS-skapade UDP-brandväggsregeln och förhindrar därför att WSL löser namn. För att den här konfigurationen ska fungera måste WSL anges för att använda DNS-tunneltrafik. Den här inställningen blockerar alltid NAT DNS-proxyn.

från gruppolicy:

Datorkonfiguration \ Administrativa mallar \ Nätverk \ Nätverksanslutningar \ Windows Defender-brandväggen \ Domänprofil | Standardprofil

"Windows Defender-brandväggen: Tillåt inte undantag" – Aktiverad

från MDM-policy:

./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/Skärmad

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

./Vendor/MSFT/Firewall/MdmStore/PublicProfile/Skärmad

Man kan se om detta är konfigurerat för att inte tillåta några inkommande brandväggsregler genom att köra följande (se ovan varningar på brandväggsprofiler). Det här är bara ett kodfragment av den första brandväggsprofilen som returneras i PowerShell:


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. En användare går igenom windowssäkerhetsinställningsapparna och kontrollerar kontrollen för "Blockerar alla inkommande anslutningar, inklusive de i listan över tillåtna appar"

Windows har stöd för en användaranmälning för samma inställning som kan tillämpas av ett företag som refereras till i #2 ovan. Användare kan öppna inställningssidan "Windows-säkerhet", väljer alternativet "Brandvägg & nätverksskydd", väljer den brandväggsprofil som de vill konfigurera (domän, privat eller offentlig) och under "Inkommande anslutningar" kontrollerar du kontrollen "Blockerar alla inkommande anslutningar, inklusive de i listan över tillåtna appar".

Om detta anges för den offentliga profilen (detta är standardprofilen för WSL vNIC) blockeras brandväggsregeln som skapats av HNS för att tillåta UDP-paketen till delad åtkomst.

Detta måste avmarkeras för att NAT DNS-proxykonfigurationen ska fungera från WSL, eller WSL kan specificeras för att använda DNS-tunnling.

4. HNS-brandväggsregeln för att tillåta DNS-paketen till delad åtkomst kan bli ogiltig och referera till en tidigare WSL-gränssnittsidentifierare. Detta är ett fel i HNS som har åtgärdats med den senaste Windows 11-versionen. I tidigare versioner är det inte lätt att upptäcka om detta inträffar, men det finns en enkel lösning.

  • Stoppa WSL

    wsl.exe –shutdown

  • Ta bort den gamla HNS-brandväggsregeln. Det här PowerShell-kommandot bör fungera i de flesta fall:

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

  • Ta bort alla HNS-slutpunkter. Obs! Om HNS används för att hantera andra containrar, till exempel MDAG eller Windows Sandbox, bör de också stoppas.

    hnsdiag.exe delete all

  • Starta eller starta om HNS-tjänsten

    Restart-Service hns

  • När WSL startas om skapar HNS nya brandväggsregler som är korrekt inriktade på WSL-gränssnittet.

Felsöka problem med nätverksåtkomst i Windows

Om du inte har någon nätverksåtkomst kan det bero på en felkonfiguration. Kontrollera om FSE-drivrutinen är igång: "sc queryex FSE". Om det inte visar att FSE är igång, kontrollerar du om registervärdet PortTrackerEnabledMode finns under den här registernyckeln: reg query HKLM\System\CurrentControlSet\Services\Tcpip\Parameters. Om FSE inte körs eller installeras och PortTrackerEnabledMode finns tar du bort registervärdet och startar om

Manuellt sätt att ta bort fantomadaptrar

Ghost-adaptrar, eller fantomenheter för Plug and Play (PnP), avser hårdvarukomponenter som visas i systemet men som inte är fysiskt anslutna. Dessa "spök"-enheter kan orsaka förvirring och oreda i systeminställningarna. Om du ser spökadaptrar när du kör WSL på virtuella datorer följer du dessa manuella steg för att hitta och ta bort dessa spök-PnP-enheter. Microsoft arbetar med en automatiserad lösning som inte kräver manuella åtgärder. Mer information kommer snart.

  1. Öppna Enhetshanteraren
  2. Visa > Visa dolda enheter

Skärmbild av Enhetshanteraren som visar menyn för dolda enheter

  1. Öppna nätverkskort

Skärmbild av listan över nätverkskort

  1. Högerklicka över det spökbaserade nätverkskortet och välj Avinstallera enhet

Skärmbild av att högerklicka på en fantom-pnp i nätverkslistan och välja avinstallera enheten

Om du startar WSL eller installerar en distribution returneras en felkod

Följ anvisningarna för att Samla in WSL-loggar i WSL-databasen på GitHub för att få detaljerade loggar och rapportera ett ärende på vår GitHub.

Uppdaterar WSL

Det finns två komponenter i Windows-undersystemet för Linux som kan kräva uppdatering.

  1. Om du vill uppdatera Själva Windows-undersystemet för Linux använder du kommandot wsl --update i PowerShell eller CMD.

  2. Om du vill uppdatera specifika binärfiler för Linux-distributionsanvändare använder du kommandot: apt-get update | apt-get upgrade i Linux-distributionen som du vill uppdatera.

Apt-get-uppgraderingsfel

Vissa paket använder funktioner som vi inte har implementerat ännu. udevstöds till exempel inte ännu och orsakar flera apt-get upgrade fel.

Följ följande steg för att åtgärda problem som rör udev:

  1. Skriv följande till /usr/sbin/policy-rc.d och spara ändringarna.

    #!/bin/sh
exit 101

  2. Lägg till körningsbehörigheter i /usr/sbin/policy-rc.d:

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

  3. Kör följande kommandon:

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

"Fel: 0x80040306" vid installationen

Detta har att göra med att vi inte stöder den äldre konsolen. Så här inaktiverar du den äldre konsolen:

  1. Öppna cmd.exe
  2. Högerklicka på titelraden –> Egenskaper –> Avmarkera Använd äldre konsol
  3. Klicka på OK

"Fel: 0x80040154" efter Windows-uppdateringen

Windows-undersystemet för Linux-funktionen kan inaktiveras under en Windows-uppdatering. Om detta händer måste Windows-funktionen återaktiveras. Instruktioner för att aktivera Windows-undersystemet för Linux finns i manuella installationsguiden.

Ändra visningsspråket

WSL-installationen försöker automatiskt ändra Ubuntu-språkvarianten så att den matchar nationella inställningar för din Windows-installation. Om du inte vill att det här beteendet ska fungera kan du köra det här kommandot för att ändra Ubuntu-språkvarianten när installationen har slutförts. Du måste starta om bash.exe för att ändringen ska börja gälla.

I exemplet nedan ändras nationella inställningar till en-US:

sudo update-locale LANG=en_US.UTF8

Installationsproblem efter windows-systemåterställning

  1. Ta bort mappen %windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux.
    Obs! Gör inte detta om den valfria funktionen är helt installerad och fungerar.
  2. Aktivera den valfria WSL-funktionen (om inte redan)
  3. Omstart
  4. lxrun /uninstall /full
  5. Installera bash

Ingen internetåtkomst i WSL

Vissa användare har rapporterat problem med specifika brandväggsprogram som blockerar Internetåtkomst i WSL. De brandväggar som rapporteras är:

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

I vissa fall tillåter avstängning av brandväggen åtkomst. I vissa fall verkar det som om bara installationen av brandväggen blockerar åtkomst.

Om du använder Microsoft Defender-brandväggen avmarkerar du "Blockerar alla inkommande anslutningar, inklusive de i listan över tillåtna appar." tillåter åtkomst.

Fel: Åtkomst nekad vid användning av ping

För Windows Anniversary Update, version 1607krävs administratörsbehörigheter i Windows för att köra ping i WSL. Om du vill köra ping kör du Bash på Ubuntu i Windows som administratör eller kör bash.exe från en CMD/PowerShell-prompt med administratörsbehörighet.

För senare versioner av Windows krävs inte längre administratörsbehörigheter Build 14926+.

Bash är hängd

Om du arbetar med bash och upptäcker att bash är låst (eller fastlåst) och inte svarar på inmatningar, hjälp oss att diagnostisera problemet genom att samla in och rapportera en minnesdump. Observera att de här stegen kraschar systemet. Gör inte detta om du inte är bekväm med det eller spara ditt arbete innan du gör detta.

Samla in en minnesdump

  1. Ändra minnesdumptypen till "fullständig minnesdump". Anteckna den aktuella typen när du ändrar dumptypen.

  2. Använd steg för att konfigurera krasch med hjälp av tangentbordskontroll.

  3. Återskapa hängningen eller dödläget.

  4. Krascha systemet med hjälp av nyckelsekvensen från (2).

  5. Systemet kraschar och samlar in minnesdumpen.

  6. När systemet startas om rapporterar du memory.dmp till secure@microsoft.com. Standardplatsen för dumpfilen är %SystemRoot%\memory.dmp eller C:\Windows\memory.dmp om C: är systemenheten. Observera i e-postmeddelandet att dumpen gäller för WSL- eller Bash-teamet i Windows.

  7. Återställ minnesdumptypen till den ursprungliga inställningen.

Kontrollera ditt versionsnummer

Om du vill hitta datorns arkitektur och Versionsnummer för Windows öppnar du
Inställningar>System>Om

Leta efter fälten OS Build och System Type.
Skärmbild av fälten Bygg och Systemtyp

Om du vill hitta ditt Windows Server-versionsnummer kör du följande i PowerShell:

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

Bekräfta att WSL är aktiverat

Du kan bekräfta att Windows-undersystemet för Linux är aktiverat genom att köra följande i ett upphöjt PowerShell-fönster:

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

OpenSSH-Server anslutningsproblem

Det gick inte att ansluta SSH-servern med följande fel: "Anslutningen stängdes av 127.0.0.1 port 22".

  1. Kontrollera att OpenSSH-servern körs:

    sudo service ssh status

    och du har följt den här självstudien: https://ubuntu.com/server/docs/service-openssh

  2. Stoppa sshd-tjänsten och starta sshd i felsökningsläge:

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

  3. Kontrollera startloggarna och kontrollera att HostKeys är tillgängliga och att du inte ser loggmeddelanden som:

    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

Om du ser sådana meddelanden och nycklarna saknas under /etc/ssh/måste du återskapa nycklarna eller bara rensa&installera openssh-server:

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

"Det gick inte att hitta den refererade sammansättningen." när du aktiverar den valfria WSL-funktionen

Det här felet är relaterat till ett felaktigt installationstillstånd. Utför följande steg för att försöka åtgärda problemet:

  • Om du kör kommandot aktivera WSL-funktion från PowerShell kan du prova att använda användargränssnittet i stället genom att öppna Start-menyn, söka efter "Aktivera eller inaktivera Windows-funktioner" och i listan väljer du sedan "Windows-undersystem för Linux" som installerar den valfria komponenten.

  • Uppdatera din version av Windows genom att gå till Inställningar, Uppdateringar och klicka på "Sök efter uppdateringar"

  • Om båda dessa misslyckas och du behöver komma åt WSL bör du överväga att uppgradera på plats genom att installera om Windows med installationsmedia och välja "Behåll allt" för att säkerställa att dina appar och filer bevaras. Du hittar anvisningar om hur du gör det på sidan Installera om Windows 10.

Om du ser det här felet:

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

Åtgärda detta genom att lägga till följande i filen /etc/wsl.conf:

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

Observera att om du lägger till det här kommandot inkluderas metadata och filbehörigheterna för Windows-filerna som visas från WSL ändras. Se filsystembehörigheter för mer information.

Det går inte att fjärransluta WSL med OpenSSH i Windows

Om du använder openssh-server i Windows och försöker komma åt WSL via fjärranslutning visas det här felet:

The file cannot be accessed by the system.

Det är ett känt problemnär du använder Store-versionen av WSL. Du kan kringgå detta i dag med hjälp av WSL 1 eller med hjälp av WSL-versionen i Windows. Mer information finns i https://aka.ms/wslstoreinfo.

Det går inte att köra Windows-kommandon i en distribution

Vissa distributioner tillgängliga i Microsoft Store är ännu inte helt kompatibla för att köra Windows-kommandon direkt. Om du får fel -bash: powershell.exe: command not found när du kör powershell.exe /c start . eller något annat Windows-kommando kan du lösa det genom att följa dessa steg:

  1. Kör echo $PATHi din WSL-distribution.
    Om den inte innehåller: /mnt/c/Windows/system32 något omdefinierar standardvariabeln PATH.
  2. Kontrollera profilinställningarna med cat /etc/profile.
    Om den innehåller tilldelning av PATH-variabeln redigerar du filen för att kommentera ut PATH-tilldelningsblocket med ett # tecken.
  3. Kontrollera om wsl.conf finns cat /etc/wsl.conf och se till att den inte innehåller appendWindowsPath=false, annars kommentera ut den.
  4. Starta om distributionen genom att skriva wsl -t följt av distributionsnamn eller köra wsl --shutdown antingen i cmd eller PowerShell.

Det går inte att starta efter installationen av WSL 2

Vi är medvetna om ett problem som påverkar användare där de inte kan starta efter installationen av WSL 2. Medan vi håller på att diagnostisera problemen fullt ut, har användarna rapporterat att ändra buffertstorleken eller installera rätt drivrutiner kan hjälpa att åtgärda detta. Visa det här GitHub-problemet för att se de senaste uppdateringarna om det här problemet.

WSL 2-fel när ICS är inaktiverat

Internet-anslutningsdelning (ICS) är en nödvändig komponent i WSL 2. ICS-tjänsten används av värdnätverkstjänsten (HNS) för att skapa det underliggande virtuella nätverket som WSL 2 förlitar sig på för NAT, DNS, DHCP och värdanslutningsdelning.

Om du inaktiverar ICS-tjänsten (SharedAccess) eller inaktiverar ICS via en grupprincip hindrar du WSL HNS-nätverket från att skapas. Detta resulterar i fel när du skapar en ny WSL version 2-avbildning och följande fel när du försöker konvertera en version 1-avbildning till version 2.

There are no more endpoints available from the endpoint mapper.

System som kräver WSL 2 bör lämna ICS-tjänsten (SharedAccess) i standardstarttillståndet, Manuell (utlösarstart) och alla principer som inaktiverar ICS ska skrivas över eller tas bort. Om du inaktiverar ICS-tjänsten kommer WSL 2 att sluta fungera. Vi rekommenderar inte att inaktivera ICS, men delar av ICS kan inaktiveras med hjälp av dessa instruktioner

Använda äldre versioner av Windows och WSL

Det finns flera skillnader att notera om du kör en äldre version av Windows och WSL, till exempel Windows 10 Creators Update (okt 2017, Build 16299) eller Anniversary Update (Aug 2016, Build 14393). Vi rekommenderar att du uppdatera till den senaste Windows-versionen, men om det inte är möjligt har vi beskrivit några av skillnaderna nedan.

Skillnader i kommandon för interoperabilitet:

  • bash.exe har ersatts med wsl.exe. Linux-kommandon kan köras från Windows-kommandotolken eller från PowerShell, men för tidiga Windows-versioner kan du behöva använda kommandot bash. Till exempel: C:\temp> bash -c "ls -la". De WSL-kommandon som skickas till bash -c vidarebefordras till WSL-processen utan ändringar. Filsökvägar måste anges i WSL-format och du måste vara noga med att undvika relevanta tecken. Till exempel: C:\temp> bash -c "ls -la /proc/cpuinfo" eller C:\temp> bash -c "ls -la \"/mnt/c/Program Files\"".
  • Om du vill se vilka kommandon som är tillgängliga för en viss distribution kör du [distro.exe] /?. Till exempel med Ubuntu: C:\> ubuntu.exe /?.
  • Windows-sökvägen ingår i WSL-$PATH.
  • När du anropar ett Windows-verktyg från en WSL-distribution i en tidigare version av Windows 10 måste du ange katalogsökvägen. Om du till exempel vill anropa Windows Notepad-appen från WSL-kommandoraden anger du: /mnt/c/Windows/System32/notepad.exe
  • Om du vill ändra standardanvändaren till root använder du det här kommandot i PowerShell: C:\> lxrun /setdefaultuser root och kör sedan Bash.exe för att logga in: C:\> bash.exe. Återställ lösenordet med kommandot distributionslösenord: $ passwd username och stäng sedan Linux-kommandoraden: $ exit. Från Windows-kommandotolken eller PowerShell återställer du standardanvändaren till ditt vanliga Linux-användarkonto: C:\> lxrun.exe /setdefaultuser username.

Avinstallera äldre version av WSL

Om du ursprungligen installerade WSL på en version av Windows 10 före Creators-uppdateringen (okt 2017, version 16299) rekommenderar vi att du migrerar alla nödvändiga filer, data osv. från den äldre Linux-distributionen som du installerade till en nyare distribution installerad via Microsoft Store. Om du vill ta bort den äldre distributionen från datorn kör du följande från en kommandorad eller PowerShell-instans: wsl --unregister Legacy. Du kan också ta bort den äldre äldre distributionen manuellt genom att ta bort mappen %localappdata%\lxss\ (och allt dess underinnehåll) med Utforskaren i Windows eller med PowerShell: rm -Recurse $env:localappdata/lxss/.