Solução de problemas do Subsistema do Windows para Linux

2025-05-20

Abordamos alguns cenários comuns de solução de problemas associados ao WSL abaixo, mas considere pesquisar os problemas arquivados no repositório de produtos WSL no GitHub também.

Registrar um problema, relatório de bugs, solicitação de recurso

Os problemas do repositório de produtos do WSL permitem que você:

Pesquisar problemas existentes para ver se há algum associado a um problema que você está tendo. Observe que, na barra de pesquisa, você pode remover "is:open" para incluir problemas que já foram resolvidos em sua pesquisa. Considere comentar ou dar um joinha em qualquer problema aberto para expressar seu interesse em avançar como prioridade.
Registre um novo problema. Se você tiver encontrado um problema com o WSL e não parecer haver um problema existente, poderá selecionar o botão verde Novo problema e, em seguida, escolher WSL – Relatório de Bugs. Você precisará incluir um título para o problema, seu número de build do Windows (execute cmd.exe /c ver para ver seu build atual #), se você estiver executando o WSL 1 ou 2, sua versão atual do Kernel do Linux # (executar wsl.exe --status ou cat /proc/version), a versão # da distribuição (executar lsb_release -r), quaisquer outras versões de software envolvidas, as etapas de reprodução, o comportamento esperado, o comportamento real, e logs de diagnóstico, se disponíveis e apropriados. Para obter mais informações, consulte contribuir para o WSL.
Registre uma solicitação de recurso selecionando o botão Novo problema verde e, em seguida, selecione Solicitação de recurso. Você precisará responder a algumas perguntas que descrevem sua solicitação.

Você também pode:

Registre um problema de documentação usando o repositório de documentação do WSL . Para contribuir com a documentação do WSL, consulte o Guia do colaborador do Microsoft Docs.
Registre um problema do Terminal do Windows usando o repositório de produtos do Terminal do Windows se o problema estiver mais relacionado ao Terminal do Windows, Console do Windows ou à interface de linha de comando.

Problemas de instalação

A instalação falhou com o erro 0x80070003
- O Subsistema do Windows para Linux é executado apenas em sua unidade do sistema (geralmente esta é sua unidade de C:). Verifique se as distribuições estão armazenadas na unidade do sistema:
- No Windows 10, abra Configurações –>Sistema –> de Armazenamento –>Mais Configurações de Armazenamento: Alterar onde o novo conteúdo é salvo
- No Windows 11, abra Configurações ->Sistema ->Armazenamento ->Configurações avançadas de armazenamento ->Onde o novo conteúdo é salvo
falha no WslRegisterDistribution com o erro 0x8007019e
- O componente opcional do Subsistema do Windows para Linux não está habilitado:
- Abra o Painel de Controle ->Programas e Recursos ->Ativar ou Desativar recursos do Windows -> Marque Subsistema Windows para Linux ou use o cmdlet do PowerShell mencionado no início desse artigo.
Falha na instalação com erro 0x80070003 ou erro 0x80370102
- Verifique se a virtualização está habilitada dentro do BIOS do computador. As instruções sobre como fazer isso variarão de computador para computador e provavelmente estarão em opções relacionadas à CPU.
- O WSL2 requer que sua CPU dê suporte ao recurso SLAT (Conversão de Endereços de Segundo Nível), que foi introduzido nos processadores Intel Nehalem (Intel Core 1ª Geração) e AMD Opteron. CPUs mais antigas (como o Intel Core 2 Duo) não poderão executar o WSL2, mesmo que a Plataforma de Máquina Virtual seja instalada com êxito.
Erro ao tentar atualizar: Invalid command line option: wsl --set-version Ubuntu 2
- Verifique se você tem o Subsistema do Windows para Linux habilitado e se está usando o Windows Build versão 18362 ou posterior. Para habilitar o WSL, execute este comando em um prompt do PowerShell com privilégios de administrador: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux.
A operação solicitada não pôde ser concluída devido a uma limitação do sistema de disco virtual. Os arquivos de disco rígido virtual devem ser descompactados e não criptografados e não devem ser esparsos.
- Desmarque "Compactar conteúdo" (bem como "Criptografar conteúdo" se isso for verificado) abrindo a pasta de perfil para sua distribuição do Linux. Ele deve estar localizado em uma pasta no sistema de arquivos do Windows, algo como: %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...
- Neste perfil de distribuição do Linux, deve haver uma pasta LocalState. Clique com o botão direito do mouse nesta pasta para exibir um menu de opções. Selecione Propriedades > Avançado e verifique se as caixas de seleção "Compactar conteúdo para economizar espaço em disco" e "Criptografar conteúdo para proteger dados" não estão selecionadas (não marcadas). Se for perguntado se você deve aplicar isso apenas à pasta atual ou a todas as subpastas e arquivos, selecione "apenas esta pasta" porque você está apenas limpando o sinalizador de compactação. Depois disso, o comando wsl --set-version deve funcionar.

Captura de tela das configurações de propriedade da distribuição do WSL

Nota

No meu caso, a pasta LocalState para minha distribuição do Ubuntu 18.04 estava localizada em C:\Usuários<meu nome de usuário>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc

Verifique o tópico #4103 do GitHub WSL Docs onde esse problema está sendo monitorado para obter informações atualizadas.

O termo 'wsl' não é reconhecido como o nome de um cmdlet, função, arquivo de script ou programa operável.
- Verifique se o Componente Opcional do Subsistema Windows para Linux está instalado. Além disso, se você estiver usando um dispositivo ARM64 e executando esse comando do PowerShell, receberá esse erro. Em vez disso, execute wsl.exe no PowerShell Core ou no Prompt de Comando.
Erro: o Subsistema do Windows para Linux não tem distribuições instaladas.
- Se você receber esse erro depois de já ter instalado as distribuições do WSL:
1. Execute a distribuição pelo menos uma vez antes de invocá-la da linha de comando.
2. Verifique se você pode estar executando contas de usuário separadas. Executar sua conta de usuário primária com permissões elevadas (no modo de administrador) não deve resultar nesse erro, mas você deve garantir que não esteja executando acidentalmente a conta de Administrador interna que vem com o Windows. Essa é uma conta de usuário separada e não mostrará nenhuma distribuição WSL instalada por design. Para obter mais informações, consulte Habilitar e desabilitar a conta de administrador interna.
3. O executável WSL só é instalado no diretório do sistema nativo. Quando você está executando um processo de 32 bits no Windows de 64 bits (ou em ARM64, qualquer combinação não nativa), o processo não nativo hospedado realmente vê uma pasta system32 diferente. (O que um processo de 32 bits vê no Windows x64 é armazenado em disco em \Windows\SysWOW64.) Você pode acessar o sistema "nativo"32 de um processo hospedado examinando a pasta virtual: \Windows\sysnative. Na verdade, ele não estará presente no disco, vale lembrar, mas o resolvedor de caminhos do sistema de arquivos o encontrará.
Erro: essa atualização só se aplica a computadores com o Subsistema do Windows para Linux.
- Para instalar o pacote MSI de atualização do kernel do Linux, o WSL é necessário e deve ser habilitado primeiro. Se falhar, você verá a mensagem: This update only applies to machines with the Windows Subsystem for Linux.
- Há três motivos possíveis para você ver esta mensagem:
1. Você ainda está na versão antiga do Windows que não dá suporte ao WSL 2. Consulte a etapa nº 2 para obter requisitos de versão e links para atualizar.
2. O WSL não está habilitado. Você precisará retornar à etapa nº 1 e garantir que o recurso WSL opcional esteja habilitado em seu computador.
3. Depois que você habilitou o WSL, uma reinicialização é necessária para que ela entre em vigor, reinicialize o computador e tente novamente.
Erro: o WSL 2 requer uma atualização para o componente do kernel. Para obter informações, visite https://aka.ms/wsl2kernel .
- Se o pacote do kernel do Linux estiver ausente na pasta %SystemRoot%\system32\lxss\tools, você encontrará esse erro. Resolva-o instalando o pacote MSI de atualização do kernel do Linux na etapa nº 4 dessas instruções de instalação. Talvez seja necessário desinstalar o MSI de 'Adicionar ou Remover Programas' e instalá-lo novamente.

Problemas comuns

Estou no Windows 10 versão 1903 e ainda não vejo opções para o WSL 2

Isso provavelmente ocorre porque seu computador ainda não recebeu o backport para WSL 2. A maneira mais simples de resolver isso é acessando as Configurações do Windows e clicando em "Verificar se há atualizações" para instalar as atualizações mais recentes em seu sistema. Consulte as instruções completas sobre como fazer o backport.

Se você pressionar "Verificar se há atualizações" e ainda não receber a atualização, poderá instalar o KB KB4566116manualmente.

Erro: 0x1bc ao `wsl --set-default-version 2`

Isso pode acontecer quando a configuração "Idioma de Exibição" ou "Localidade do Sistema" não é inglês.

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

O erro real para 0x1bc é:

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

Para obter mais informações, consulte o problema 5749

Não é possível acessar arquivos WSL do Windows

Um servidor de arquivos de protocolo 9p fornece o serviço no lado do Linux para permitir que o Windows acesse o sistema de arquivos Linux. Se você não puder acessar o WSL usando \\wsl$ no Windows, pode ser porque o 9P não foi iniciado corretamente.

Para verificar isso, você pode verificar os logs de inicialização usando: dmesg |grep 9pe isso mostrará quaisquer erros. Uma saída bem-sucedida se parece com o seguinte:

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

Consulte esse tópico do GitHub para obter mais informações sobre esse problema.

Não é possível iniciar a distribuição do WSL 2 e ver apenas 'WSL 2' na saída

Se o idioma de exibição não for inglês, é possível que você esteja vendo uma versão truncada de um texto de erro.

C:\Users\me>wsl
WSL 2

Para resolver esse problema, visite https://aka.ms/wsl2kernel e instale o kernel manualmente seguindo as instruções nessa página do documento.

`command not found` ao executar o Windows .exe no Linux

Os usuários podem executar executáveis do Windows como notepad.exe diretamente do Linux. Às vezes, você pode receber a mensagem "comando não encontrado", como abaixo:

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

Se não houver caminhos Win32 no seu $PATH, a interoperabilidade não encontrará o .exe. Você pode verificar isso executando echo $PATH no Linux. Espera-se que você veja um caminho Win32 (por exemplo, /mnt/c/Windows) na saída. Se você não conseguir ver nenhum caminho do Windows, provavelmente seu PATH está sendo substituído pelo shell do Linux.

Aqui está um exemplo de que /etc/profile no Debian contribuiu para o problema:

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

A maneira correta no Debian é remover as linhas acima. Você também pode acrescentar $PATH durante a atribuição como abaixo, mas isso pode causar outros problemas com o WSL e o 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

Para obter mais informações, consulte o problema 5296 e o problema 5779.

"Erro: 0x80370102 A máquina virtual não pôde ser iniciada porque um recurso necessário não está instalado."

Habilite o recurso Windows da Plataforma de Máquina Virtual e verifique se a virtualização está habilitada no BIOS.

Verifique os requisitos do sistema Hyper-V
Se o seu computador for uma VM, habilite a virtualização aninhada manualmente. Inicie o PowerShell com o administrador e execute o seguinte comando, substituindo <VMName> pelo nome da máquina virtual em seu sistema host (você pode encontrar o nome em seu gerenciador de Hyper-V):
```
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
```
Siga as diretrizes do fabricante do computador sobre como habilitar a virtualização. Em geral, isso pode envolver o uso do BIOS do sistema para garantir que esses recursos estejam habilitados em sua CPU. As instruções para esse processo podem variar de computador para computador, consulte este artigo do Bleeping Computer para obter um exemplo.
Reinicie o computador depois de habilitar o componente opcional Virtual Machine Platform.
Verifique se a inicialização do hipervisor está habilitada na configuração de inicialização. Você pode validar isso executando (PowerShell em modo elevado):
```
 bcdedit /enum | findstr -i hypervisorlaunchtype
```
Se você vir hypervisorlaunchtype Off, o hipervisor estará desabilitado. Para habilitá-lo, execute no PowerShell com privilégios elevados:
```
 bcdedit /set hypervisorlaunchtype Auto
```
Além disso, se você tiver hipervisores de terceiros instalados (como VMware ou VirtualBox), verifique se os tem nas versões mais recentes que podem dar suporte ao HyperV (VMware 15.5.5+ e VirtualBox 6+) ou que estão desativados.
Se você estiver recebendo esse erro em uma Máquina Virtual do Azure, verifique se Inicialização Confiável está desabilitada. Não há suporte para virtualização aninhada em máquinas virtuais do Azure com Início Confiável.

Saiba mais sobre como Configurar a Virtualização Aninhada ao executar o Hyper-V em uma Máquina Virtual.

O WSL não tem nenhuma conexão de rede no meu computador de trabalho ou em um ambiente Enterprise

Ambientes corporativos ou empresariais podem ter configurações de firewall do Windows Defender configuradas para bloquear o tráfego de rede não autorizado. Se a mesclagem de regras locais estiver definida como "Não", o sistema de rede do WSL não funcionará por padrão e o administrador precisará adicionar uma regra de firewall para permiti-la.

Você pode confirmar a configuração da mesclagem de regras locais seguindo estas etapas:

captura de tela de configurações do Firewall do Windows

Abra o "Windows Defender Firewall com segurança avançada" (isso é diferente do "Firewall do Windows Defender" no Painel de Controle)
Clique com o botão direito do mouse na guia "Firewall do Windows Defender com segurança avançada no Computador Local"
Selecione "Propriedades"
Selecione a guia "Perfil Público" na nova Janela que é aberta
Selecione "Personalizar" na seção "Configurações"
Verifique a janela "Personalizar Configurações para o Perfil Público" que se abre para verificar se a "Mesclagem de Regras" está configurada como "Não". Isso bloqueará o acesso ao WSL.

Você pode encontrar instruções sobre como alterar essa configuração de Firewall no Configurar Hyper-V firewall.

O WSL não tem conectividade de rede uma vez conectado a uma VPN

Se, após conectar-se a uma VPN no Windows, o bash perder a conectividade de rede, tente esta solução alternativa no bash. Essa solução alternativa permitirá que você substitua manualmente a resolução DNS por meio de /etc/resolv.conf.

Anote o servidor DNS da VPN ao fazer ipconfig.exe /all
Faça uma cópia do sudo cp /etc/resolv.conf /etc/resolv.conf.new resolv.conf existente
Desvincule o resolv.conf atual sudo unlink /etc/resolv.conf
sudo mv /etc/resolv.conf.new /etc/resolv.conf
Edite /etc/wsl.conf e adicione esse conteúdo ao arquivo. (Mais informações sobre essa configuração podem ser encontradas em Definição das configurações avançadas)

[network]
generateResolvConf=false

Abra /etc/resolv.conf e
um. Excluir a primeira linha do arquivo que tem um comentário que descreve a geração automática
b. Adicione a entrada DNS de (1) acima como a primeira entrada na lista de servidores DNS.
c. Feche o arquivo.

Depois de desconectar a VPN, você precisará reverter as alterações para /etc/resolv.conf. Para fazer isso, faça:

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

Problemas do Cliente Global Secure Access com o WSL

O Cliente de Acesso Seguro Global (/entra/global-secure-access/how-to-install-windows-client) pode afetar a conectividade WSL, pois ele tem um recurso para retornar um endereço temporário ao resolver um nome. Em seguida, o endereço é trocado para o endereço real quando uma conexão de rede é feita. Isso pode interromper o WSL, pois o tráfego WSL é encaminhado abaixo de grande parte dos ganchos de cliente GSA.

É recomendável desabilitar o Túnel DNS (dnsTunneling=false) ou desabilitar o Modo Espelhado (networkingMode=nat).

Problemas de VPN do Cisco Anyconnect com o WSL no modo NAT

A VPN Cisco AnyConnect modifica as rotas de uma maneira que impede que o NAT funcione. Existe uma solução alternativa específica para o WSL 2: consulte Guia do Administrador do Cliente Cisco AnyConnect Secure Mobility, versão 4.10 – Solucionar problemas do AnyConnect.

Problemas de conectividade WSL com VPNs quando o modo de rede espelhado está ativado

O modo de sistema de rede espelhado é atualmente uma configuração experimental na Configuração do WSL. A arquitetura de rede NAT tradicional do WSL pode ser atualizada para um modo de rede totalmente novo chamado "Modo de rede espelhada". Quando o networkingMode experimental é definido como mirrored, as interfaces de rede que você tem no Windows são espelhadas no Linux para melhorar a compatibilidade. Saiba mais no blog da Linha de Comando: Atualização do WSL de setembro de 2023.

Algumas VPNs foram testadas e confirmadas como incompatíveis com o WSL, incluindo:

"Bitdefender" versão 26.0.2.1
"OpenVPN" versão 2.6.501
"Mcafee Safe Connect" versão 2.16.1.124

Considerações ao usar autoProxy para espelhamento de HttpProxy no WSL

O espelhamento de proxy HTTP/S pode ser configurado usando a configuração autoProxy na seção experimental do arquivo de Configuração do WSL. Ao aplicar essa configuração, observe estas considerações:

Proxy PAC: o WSL configurará a configuração no Linux definindo a variável de ambiente "WSL_PAC_URL". O Linux não dá suporte a proxies PAC por padrão.
Interações com o WSLENV: as variáveis de ambiente definidas pelo usuário têm precedência sobre aquelas especificadas por esse recurso.

Quando habilitado, o seguinte se aplica às configurações de proxy em suas distribuições do Linux:

A variável de ambiente do Linux, HTTP_PROXY, é definida como um ou mais proxies HTTP encontrados instalados na configuração de proxy HTTP do Windows.
A variável de ambiente do Linux, HTTPS_PROXY, é configurada para um ou mais proxies HTTPS encontrados instalados na configuração de proxy HTTP do Windows.
A variável de ambiente do Linux, NO_PROXY, está definida para ignorar quaisquer proxies HTTP/S encontrados nos destinos de configuração do Windows.
Cada variável de ambiente, exceto WSL_PAC_URL, é definida tanto em minúsculas quanto em maiúsculas. Por exemplo: HTTP_PROXY e http_proxy.

Há um problema conhecido causado pelas configurações do ZScaler, em que o ZScaler habilita e desabilita repetidamente as configurações de proxy do Windows, levando o WSL a mostrar repetidamente a notificação "Uma alteração de proxy Http foi detectada no host".

Saiba mais no blog da Linha de Comando: Atualização do WSL de setembro de 2023.

Considerações de rede com túnel DNS

Quando o WSL não pode se conectar à Internet, pode ser porque a chamada DNS para o host do Windows está bloqueada. Isso ocorre porque o pacote de rede para DNS enviado pela VM WSL para o host do Windows é bloqueado pela configuração de rede existente. O túnel DNS corrige isso usando um recurso de virtualização para se comunicar diretamente com o Windows, permitindo que o nome DNS seja resolvido sem enviar um pacote de rede. Esse recurso deve melhorar a compatibilidade com a rede e permitir que você obtenha melhor conectividade com a Internet, mesmo se você tiver uma VPN, uma configuração de firewall específica ou outras configurações de rede.

O Túnel DNS pode ser configurado usando a configuração de dnsTunneling na seção experimental do arquivo de Configuração do WSL. Ao aplicar essa configuração, observe estas considerações:

Se você usar uma VPN com WSL, ative o túnel DNS. Muitas VPNs usam políticas NRPT, que só são aplicadas a consultas DNS do WSL quando o túnel DNS está habilitado.
O arquivo /etc/resolv.conf na distribuição do Linux tem uma limitação máxima de 3 servidores DNS, enquanto o Windows pode usar mais de 3 servidores DNS. O uso do túnel DNS remove essa limitação– todos os servidores DNS do Windows agora podem ser usados pelo Linux.
O WSL usará sufixos DNS do Windows na seguinte ordem (semelhante à ordem usada pelo cliente DNS do Windows):
1. Sufixos DNS globais
2. Sufixos DNS complementares
3. Sufixos DNS por interface
4. Se a criptografia DNS (DoH, DoT) estiver habilitada no Windows, a criptografia será aplicada a consultas DNS do WSL. Se os usuários quiserem habilitar o DoH, o DoT dentro do Linux, eles precisarão desabilitar o túnel DNS.
Consultas DNS de contêineres do Docker gerenciados pelo Docker Desktop ignorarão o túnel DNS. O Docker Desktop possui uma maneira própria (diferente do túnel DNS) de aplicar configurações e políticas de DNS de host a consultas de DNS feitas por contêineres do Docker.
Para que o túnel DNS seja habilitado com êxito, a opção generateResolvConf no arquivo wsl.conf não deve ser desabilitada.
Quando o túnel DNS está habilitado, a opção generateHosts no arquivo wsl.conf é ignorada (o arquivo de hosts DNS do Windows não é copiado no arquivo Linux /etc/hosts). As políticas no arquivo de hosts do Windows serão aplicadas a consultas DNS do Linux, sem a necessidade de que o arquivo seja copiado no Linux.

Saiba mais no blog da Linha de Comando: Atualização do WSL de setembro de 2023.

Problemas ao direcionar o tráfego de entrada recebido pelo host do Windows para a Máquina Virtual WSL

Ao usar o modo de rede espelhado (o networkingMode experimental definido como mirrored), algum tráfego de entrada recebido pelo host do Windows nunca será direcionado para a VM do Linux. Esse tráfego é o seguinte:

Porta UDP 68 (DHCP)
Porta TCP 135 (resolução de ponto de extremidade DCE)
Porta TCP 1900 (UPnP)
Porta TCP 2869 (SSDP)
Porta TCP 5004 (RTP)
Porta TCP 3702 (WSD)
Porta TCP 5357 (WSD)
Porta TCP 5358 (WSD)

O WSL definirá automaticamente determinadas configurações de rede do Linux ao usar o modo de rede espelhado. Não há suporte para qualquer configuração de usuário dessas configurações ao usar o modo de rede espelhada. Esta é a lista de configurações que o WSL definirá:

Nome da Configuração	Valor
https://sysctl-explorer.net/net/ipv4/accept_local/	Habilitado (1)
https://sysctl-explorer.net/net/ipv4/route_localnet/	Habilitado (1)
https://sysctl-explorer.net/net/ipv4/rp_filter/	Desabilitado (0)
https://sysctl-explorer.net/net/ipv6/accept_ra/	Desabilitado (0)
https://sysctl-explorer.net/net/ipv6/autoconf/	Desabilitado (0)
https://sysctl-explorer.net/net/ipv6/use_tempaddr/	Desabilitado (0)
addr_gen_mode	Desabilitado (0)
disable_ipv6	Desabilitado (0)
https://sysctl-explorer.net/net/ipv4/arp_filter/	Habilitado (1)

Problemas de contêiner do Docker no WSL2 com o modo de rede espelhado habilitado ao executar no namespace de rede padrão

Há um problema conhecido em que os contêineres do Docker Desktop com portas publicadas (docker run –publish/-p) não serão criados. A equipe do WSL está trabalhando com a equipe do Docker Desktop para resolver esse problema. Para contornar o problema, use o namespace de rede do host no contêiner do Docker. Defina o tipo de rede por meio da opção "--host de rede" usada no comando "docker run". Uma solução alternativa é listar o número da porta publicada na configuração ignoredPorts da seção experimental no arquivo de configuração do WSL.

Problemas de contêiner do Docker quando o Gerenciador de Rede está em execução

Há um problema conhecido com contêineres do Docker que têm o serviço Gerenciador de Rede em execução. Os sintomas incluem falhas ao tentar fazer conexões de loopback com o host. É recomendável interromper o serviço do Gerenciador de Rede para que a rede WSL seja configurada corretamente.

sudo systemctl disable network-manager.service

Resolução de nomes .local no WSL

Para resolver nomes de host para endereços IP em uma rede local sem a necessidade de um servidor DNS convencional, os nomes .local são frequentemente usados. Isso é feito por meio do protocolo mDNS (DNS multicast), que depende do tráfego multicast para funcionar.

Modo de rede configurado como NAT:

Atualmente, esse recurso não tem suporte quando o túnel DNS está habilitado. Para habilitar a resolução de nomes .local, recomendamos as seguintes soluções:

Desabilite o túnel DNS.
Use o modo de rede espelhada.

networkingMode definido como Espelhado:

Observação: você precisa estar no build WSL 2.3.17 ou superior para ter a funcionalidade abaixo.

Como o modo Espelhado dá suporte ao tráfego multicast, o protocolo mDNS (DNS multicast) pode ser usado para resolver nomes .local. O Linux deve ser configurado para dar suporte ao mDNS, pois ele não o faz por padrão. Uma maneira de configurá-lo é usando as seguintes duas etapas:

Instalar o pacote "libnss-mdns"

sudo apt-get install libnss-mdns

*O pacote "libnss-mdns" é um plug-in para a funcionalidade NSS (GNU Name Service Switch) da biblioteca GNU C (glibc) que fornece resolução de nome de host por meio do MDNS (Multicast DNS). Esse pacote efetivamente permite que programas comuns do Unix/Linux resolvam nomes no domínio mDNS .local ad hoc.

Configure o arquivo /etc/nsswitch.conf para habilitar a configuração "mdns_minimal" na seção "hosts". Conteúdo de exemplo do arquivo:

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

Sufixos DNS no WSL

Dependendo das configurações no arquivo .wslconfig, o WSL terá o seguinte comportamento em relação aos sufixos DNS:

Quando networkingMode é definido como NAT:

Caso 1) Por padrão, nenhum sufixo DNS está configurado no Linux

Caso 2) Se o túnel DNS estiver habilitado (o dnsTunneling é definido como true em .wslconfig) Todos os sufixos DNS do Windows são configurados no Linux, na configuração de "pesquisa" de /etc/resolv.conf

Os sufixos são configurados em /etc/resolv.conf na seguinte ordem, semelhante à ordem em que o cliente DNS do Windows tenta sufixos ao resolver um nome: sufixos DNS globais primeiro, depois sufixos DNS suplementares e, em seguida, sufixos DNS por interface.

Quando houver uma alteração nos sufixos DNS do Windows, essa alteração será refletida automaticamente no Linux

Caso 3) Se o túnel DNS estiver desabilitado e o proxy DNS SharedAccess estiver desabilitado (dnsTunneling é definido como false e dnsProxy é definido como false em .wslconfig) Um único sufixo DNS é configurado no Linux, na configuração "domain" de /etc/resolv.conf

Quando há uma alteração nos sufixos DNS do Windows, essa alteração não é refletida no Linux

O sufixo DNS único configurado no Linux é escolhido entre os sufixos DNS por interface (sufixos globais e complementares são ignorados)

se o Windows tiver várias interfaces, uma heurística será usada para escolher o sufixo DNS único que será configurado no Linux. Por exemplo, se houver uma interface VPN no Windows, o sufixo será escolhido nessa interface. Se nenhuma interface VPN estiver presente, o sufixo será escolhido da interface que provavelmente fornecerá conectividade com a Internet.

Quando networkingMode é definido como Espelhado:

Todos os sufixos DNS do Windows são configurados no Linux, na configuração de "pesquisa" de /etc/resolv.conf

Os sufixos são configurados em /etc/resolv.conf na mesma ordem que no caso 2) do modo NAT

Quando houver uma alteração nos sufixos DNS do Windows, essa alteração será refletida automaticamente no Linux

Observação: sufixos DNS suplementares podem ser configurados no Windows usando SetInterfaceDnsSettings - Aplicativos Win32 | Microsoft Learn, com o sinalizador DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST definido no parâmetro Configurações

Solução de problemas de DNS no WSL

A configuração DNS padrão quando o WSL inicia um contêiner no modo NAT é fazer com que o dispositivo NAT no Host do Windows sirva como o 'servidor' DNS para o contêiner WSL. Quando as consultas DNS são enviadas do contêiner WSL para esse dispositivo NAT no Host do Windows, o pacote DNS é encaminhado do dispositivo NAT para o serviço de acesso compartilhado no Host; a resposta é enviada na direção inversa de volta para o contêiner WSL. Esse processo de encaminhamento de pacotes para acesso compartilhado requer uma regra de Firewall para permitir esse pacote DNS de entrada, que é criado pelo serviço HNS quando o WSL inicialmente solicita ao HNS que crie a rede virtual NAT para seu contêiner WSL.

Devido a esse NAT - projeto de acesso compartilhado, há algumas configurações conhecidas que podem interromper a resolução de nomes do WSL.

1. Uma empresa pode enviar por push uma política que não permite regras de Firewall definidas localmente, permitindo apenas regras definidas pela política empresarial.

Quando isso é definido por uma Empresa, a regra de Firewall criada por HNS é ignorada, pois é uma regra definida localmente. Para que essa configuração funcione, a Empresa deve criar uma regra de Firewall para permitir a porta UDP 53 para o serviço de acesso compartilhado ou o WSL pode ser definido para usar o Túnel DNS. É possível ver se isso está configurado para não permitir regras de Firewall definidas localmente executando o seguinte. Observe que isso mostrará as configurações para todos os três perfis: Domínio, Privado e Público. Se ele estiver definido em qualquer perfil, os pacotes serão bloqueados se a vNIC do WSL for atribuída a esse perfil (o padrão é Público). Este é apenas um snippet do primeiro perfil de Firewall que é retornado no 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. E o Enterprise pode aplicar configurações de política de grupo e política MDM que bloqueiam todas as regras de entrada.

Essas configurações substituem qualquer regra de firewall Allow-Inbound. Dessa forma, essa configuração bloqueará a regra de Firewall UDP criada pelo HNS e, portanto, impedirá que o WSL resolva nomes. Para que essa configuração funcione, WSL deve ser definido para usar DNS Tunneling. Essa configuração sempre bloqueará o proxy DNS NAT.

Da Política de Grupo:

Configuração do computador \ Modelos Administrativos \ Rede \ Conexões de Rede \ Firewall do Windows Defender \ Perfil de Domínio | Perfil Padrão

"Windows Defender Firewall: não permitir exceções" – Habilitado

Da Política MDM:

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

./Vendor/MSFT/Firewall/MdmStore/DomainProfile/Protegido

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

É possível ver se isso está configurado para não permitir nenhuma regra de Firewall de entrada executando o seguinte (consulte as ressalvas acima em Perfis de Firewall). Este é apenas um snippet do primeiro perfil de Firewall que é retornado no 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. Um usuário passa pelos aplicativos de configuração de Segurança do Windows e verifica o controle "Bloqueia todas as conexões de entrada, incluindo aquelas na lista de aplicativos permitidos".

O Windows dá suporte a uma aceitação do usuário para a mesma configuração que pode ser aplicada por uma Empresa referenciada no nº 2 acima. Os usuários podem abrir a página de configurações de "Segurança do Windows", selecionar a opção "Firewall & proteção de rede", selecionar o Perfil de Firewall que desejam configurar (Domínio, Privado ou Público) e, em "Conexões de entrada", verifique o controle rotulado "Bloqueia todas as conexões de entrada, incluindo aquelas na lista de aplicativos permitidos".

Se isso for definido para o perfil Público (este é o perfil padrão para o WSL vNIC), a regra de Firewall criada pelo HNS para permitir que os pacotes UDP tenham acesso compartilhado será bloqueada.

Essa opção deve ser desmarcada para que a configuração do proxy DNS NAT funcione no WSL, ou o WSL pode ser configurado para usar o Túnel DNS.

4. A regra de Firewall do HNS para permitir que os pacotes DNS para acesso compartilhado possa se tornar inválida, fazendo referência a um identificador de interface WSL anterior. Essa é uma falha no HNS que foi corrigida com a versão mais recente do Windows 11. Em versões anteriores, se isso ocorrer, ele não é facilmente detectável, mas tem uma solução simples:

Parar WSL

wsl.exe –shutdown
Exclua a regra antiga do Firewall HNS. Esse comando do PowerShell deve funcionar na maioria dos casos:

Get-NetFirewallRule -Name "HNS*" | Get-NetFirewallPortFilter | where Protocol -eq UDP | where LocalPort -eq 53 | Remove-NetFirewallRule
Remova todos os pontos de extremidade HNS. Observação: se o HNS for usado para gerenciar outros contêineres, como MDAG ou Área Restrita do Windows, eles também deverão ser interrompidos.

hnsdiag.exe delete all
Reinicie ou reinicialize o serviço HNS

Restart-Service hns
Quando o WSL for reiniciado, o HNS criará novas regras de Firewall, direcionando corretamente a interface WSL.

Solução de problemas de acesso à rede no Windows

Se você não tiver acesso à rede, pode ser devido a uma configuração incorreta. Confira se o driver FSE está em execução: 'sc queryex FSE'. Se isso não mostrar o FSE em execução, verifique se o valor do registro PortTrackerEnabledMode existe sob esta chave do registro: reg query HKLM\System\CurrentControlSet\Services\Tcpip\Parameters. Se o FSE não estiver em execução ou instalado e PortTrackerEnabledMode existir, exclua esse valor de registro e reinicie

Maneira manual de excluir adaptadores fantasmas

Adaptadores fantasma ou dispositivos Plug and Play (PnP) fantasma referem-se a componentes de hardware que aparecem no sistema, mas não estão fisicamente conectados. Esses dispositivos "fantasmas" podem causar confusão e desordem nas configurações do sistema. Se você vir adaptadores fantasmas ao executar o WSL em uma VM (Máquina Virtual), siga estas etapas manuais para localizar e excluir esses dispositivos PnP fantasmas. A Microsoft está trabalhando em uma solução automatizada que não exigirá intervenção manual. Mais informações serão fornecidas em breve.

Abrir o Gerenciador de Dispositivos
Exibir > Mostrar dispositivos ocultos

Captura de tela do Gerenciador de Dispositivos mostra o menu dispositivos ocultos

Abrir adaptadores de rede

Captura de tela da lista de adaptadores de rede

Clique com o botão direito do mouse no adaptador de rede Ghosted e selecione Desinstalar Dispositivo

Captura de tela do clique com o botão direito do mouse em um PnP fantasma na lista de redes e seleção da opção de desinstalação do dispositivo

Iniciar o WSL ou instalar uma distribuição retorna um código de erro

Siga as instruções para Coletar logs do WSL no repositório do WSL no GitHub para coletar logs detalhados e registrar um problema no nosso GitHub.

Atualização do WSL

Há dois componentes do Subsistema do Windows para Linux que podem exigir atualização.

Para atualizar o subsistema do Windows para Linux em si, use o comando wsl --update no PowerShell ou CMD.
Para atualizar os binários específicos do usuário de distribuição do Linux, use o comando: apt-get update | apt-get upgrade na distribuição do Linux que você está buscando atualizar.

Erros de atualização do Apt-get

Alguns pacotes usam recursos que ainda não implementamos. udev, por exemplo, ainda não tem suporte e causa vários erros de apt-get upgrade.

Para corrigir problemas relacionados ao udev, siga as seguintes etapas:

Escreva o seguinte para /usr/sbin/policy-rc.d e salve suas alterações.
```
#!/bin/sh
exit 101
```
Adicionar permissões de execução a /usr/sbin/policy-rc.d:
```
chmod +x /usr/sbin/policy-rc.d
```

Execute os seguintes comandos:

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

"Erro: 0x80040306" na instalação

Isso tem a ver com o fato de não darmos suporte ao console herdado. Para desativar o console herdado:

Abrir cmd.exe
Clique com o botão direito do mouse na barra de título -> Propriedades -> Desmarque Usar console herdado
Clique em OK

"Erro: 0x80040154" após a atualização do Windows

O recurso Subsistema do Windows para Linux pode estar desabilitado durante uma atualização do Windows. Se isso acontecer, o recurso do Windows deverá ser habilitado novamente. As instruções para habilitar o Subsistema do Windows para Linux podem ser encontradas no guia de instalação manual .

Alterando o idioma de exibição

A instalação do WSL tentará alterar automaticamente a localidade do Ubuntu para corresponder à localidade da instalação do Windows. Se você não quiser esse comportamento, poderá executar esse comando para alterar a localidade do Ubuntu após a conclusão da instalação. Você precisará relançar bash.exe para que essa alteração entre em vigor.

O exemplo abaixo muda a configuração regional para en-US:

sudo update-locale LANG=en_US.UTF8

Problemas de instalação após a restauração do sistema Windows

Exclua a pasta %windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux.
Observação: não faça isso se o recurso opcional estiver totalmente instalado e funcionando.
Habilitar o recurso opcional do WSL (se ainda não estiver)
Reinicializar
lxrun /uninstall /full
Instalar o Bash

Sem acesso à Internet no WSL

Alguns usuários relataram problemas com aplicativos de firewall específicos bloqueando o acesso à Internet no WSL. Os firewalls relatados são:

Kaspersky
AVG
Avast
Symantec Endpoint Protection

Em alguns casos, desativar o firewall permite o acesso. Em alguns casos, simplesmente ter o firewall instalado procura bloquear o acesso.

Se você estiver usando o Microsoft Defender Firewall, desmarcar "Bloqueia todas as conexões de entrada, incluindo aquelas na lista de aplicativos permitidos". Permite o acesso.

Erro de permissão negada ao usar ping

Para Atualização de Aniversário do Windows, versão 1607, são necessários privilégios de administrador no Windows para executar ping no WSL. Para executar ping, execute o Bash no Ubuntu no Windows como administrador ou execute bash.exe em um prompt do CMD/PowerShell com privilégios de administrador.

Para versões posteriores do Windows, Build 14926+, os privilégios de administrador não são mais necessários.

O Bash está suspenso

Se, ao trabalhar com o bash, você perceber que ele está travado (ou em deadlock) e não responde às entradas, ajude-nos a diagnosticar o problema coletando e relatando um despejo de memória. Observe que essas etapas travarão o sistema. Não faça isso se você não estiver confortável ou salve seu trabalho antes de fazer isso.

Para coletar um despejo de memória

Altere o tipo de despejo de memória para "despejo de memória completo". Ao alterar o tipo de despejo, anote o tipo atual.
Use as etapas para configurar a falha usando o controle de teclado.
Reproduza o travamento ou o deadlock.
Cause uma falha no sistema usando a sequência de teclas de (2).
O sistema falhará e coletará o despejo de memória.
Depois que o sistema for reinicializado, relate o memory.dmp para secure@microsoft.com. O local padrão do arquivo de despejo é %SystemRoot%\memory.dmp ou C:\Windows\memory.dmp se C: é a unidade do sistema. No email, observe que o despejo é para a equipe do WSL ou Bash no Windows.
Restaure o tipo de despejo de memória para a configuração original.

Verifique o número da build

Para localizar a arquitetura do computador e o número de build do Windows, abra
Configurações>Sistema>Sobre

Procure os campos Build do SO e Tipo de Sistema.
captura de tela Captura de tela dos campos Build e Tipo de Sistema

Para localizar o número de build do Windows Server, execute o seguinte no PowerShell:

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

Confirmar se o WSL está habilitado

Você pode confirmar se o Subsistema do Windows para Linux está habilitado executando o seguinte em uma janela do PowerShell com privilégios elevados:

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

OpenSSH-Server problemas de conexão

Falha ao tentar conectar o servidor SSH com o seguinte erro: "Conexão fechada pela porta 22 127.0.0.1".

Verifique se o servidor OpenSSH está em execução:
```
sudo service ssh status
```
e você seguiu esse tutorial: https://ubuntu.com/server/docs/service-openssh
Interrompa o serviço sshd e inicie o sshd no modo de depuração:
```
sudo service ssh stop
sudo /usr/sbin/sshd -d
```

Verifique os logs de inicialização e verifique se o HostKeys está disponível e você não vê mensagens de log, como:

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

Se você vir essas mensagens e as chaves estiverem ausentes em /etc/ssh/, será necessário regenerar as chaves ou apenas limpar e instalar o openssh-server:

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

"O assembly referenciado não pôde ser encontrado." ao habilitar o recurso opcional do WSL

Esse erro está relacionado a estar em um estado de instalação incorreto. Conclua as seguintes etapas para tentar corrigir este problema:

Se você estiver executando o comando habilitar recurso WSL do PowerShell, tente usar a GUI abrindo o menu iniciar, procurando por "Ativar ou desativar recursos do Windows" e, na lista, selecione "Subsistema do Windows para Linux" que instalará o componente opcional.
Atualize sua versão do Windows acessando Configurações, Atualizações e clicando em "Verificar se há atualizações"
Se ambos falharem e você precisar acessar o WSL, considere atualizar no local reinstalando o Windows usando o dispositivo de instalação e selecionando "Manter todos os arquivos" para garantir que seus aplicativos e arquivos sejam preservados. Você pode encontrar instruções sobre como fazer isso na página Reinstalar o Windows 10.

Se você estiver vendo este erro:

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

Para corrigir isso, acrescente o seguinte ao arquivo /etc/wsl.conf:

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

Observe que adicionar esse comando incluirá metadados e modificará as permissões de arquivo nos arquivos do Windows vistos do WSL. Consulte as permissões do sistema de arquivos para obter mais informações.

Falha ao usar o WSL remotamente usando o OpenSSH no Windows

Se você estiver usando o openssh-server no Windows e tentando acessar o WSL remotamente, muitos verão este erro:

The file cannot be accessed by the system.

É um problema conhecido ao usar a versão do WSL da Store. Você pode contornar isso hoje usando o WSL 1 ou usando a versão no Windows do WSL. Consulte https://aka.ms/wslstoreinfo para obter mais informações.

A execução de comandos do Windows falha dentro de uma distribuição

Algumas distribuições disponíveis na Microsoft Store ainda não são totalmente compatíveis para executar comandos do Windows prontos para uso. Se você receber um erro -bash: powershell.exe: command not found executando powershell.exe /c start . ou qualquer outro comando do Windows, poderá resolvê-lo seguindo estas etapas:

Na sua distribuição do WSL, execute o comando echo $PATH.
Se ele não incluir: /mnt/c/Windows/system32 algo está redefinindo a variável PATH padrão.
Verifique as configurações de perfil com cat /etc/profile.
Se ele contiver a atribuição da variável PATH, edite o arquivo para comentar o bloco de atribuição PATH com um caractere #.
Verifique se o wsl.conf está presente cat /etc/wsl.conf e certifique-se de que ele não contenha appendWindowsPath=false, caso contrário, faça um comentário.
Reinicie a distribuição digitando wsl -t seguidos pelo nome de distribuição ou execute wsl --shutdown no cmd ou no PowerShell.

Não é possível inicializar depois de instalar o WSL 2

Estamos cientes de um problema que afeta os usuários em que eles não podem inicializar depois de instalar o WSL 2. Embora diagnosticemos totalmente esse problema, os usuários relataram que alterando o tamanho do buffer ou instalando os drivers certos podem ajudar a resolver isso. Veja este problema do GitHub para ver as atualizações mais recentes sobre esse problema.

Erros do WSL 2 quando o ICS está desabilitado

O ICS (Compartilhamento de Conexão com a Internet) é um componente obrigatório do WSL 2. O serviço ICS é usado pelo HNS (Serviço de Rede de Host) para criar a rede virtual subjacente na qual o WSL 2 depende para NAT, DNS, DHCP e compartilhamento de conexão de host.

Desabilitar o serviço ICS (SharedAccess) ou desabilitar o ICS por meio da política de grupo impedirá que a rede HNS do WSL seja criada. Isso resultará em falhas ao criar uma nova imagem do WSL versão 2 e o seguinte erro ao tentar converter uma imagem da versão 1 na versão 2.

There are no more endpoints available from the endpoint mapper.

Os sistemas que exigem o WSL 2 devem deixar o serviço ICS (SharedAccess) em seu estado de inicialização padrão, Manual (Início do Gatilho), e qualquer política que desabilite o ICS deve ser substituída ou removida. Embora a desabilitação do serviço ICS interrompa o WSL 2 e não recomendamos desabilitar o ICS, partes do ICS podem ser desabilitadas usando essas instruções

Usando versões mais antigas do Windows e do WSL

Há várias diferenças a serem observadas se você estiver executando uma versão mais antiga do Windows e do WSL, como a Atualização de Criadores do Windows 10 (outubro de 2017, Build 16299) ou a Atualização de Aniversário (Agosto de 2016, Build 14393). Recomendamos que você atualize para a versão mais recente do Windows, mas se isso não for possível, descrevemos algumas das diferenças abaixo.

Diferenças de comando de interoperabilidade:

bash.exe foi substituído por wsl.exe. Os comandos do Linux podem ser executados no Prompt de Comando do Windows ou no PowerShell, mas para versões iniciais do Windows, talvez seja necessário usar o comando bash. Por exemplo: C:\temp> bash -c "ls -la". Os comandos WSL passados para bash -c são encaminhados para o processo WSL sem modificação. Os caminhos de arquivo devem ser especificados no formato WSL e é preciso ter cuidado com os caracteres de escape relevantes. Por exemplo: C:\temp> bash -c "ls -la /proc/cpuinfo" ou C:\temp> bash -c "ls -la \"/mnt/c/Program Files\"".
Para ver quais comandos estão disponíveis para uma distribuição específica, execute [distro.exe] /?. Por exemplo, com o Ubuntu: C:\> ubuntu.exe /?.
O caminho do Windows está incluído no WSL $PATH.
Ao chamar uma ferramenta do Windows de uma distribuição WSL em uma versão anterior do Windows 10, você precisará especificar o caminho do diretório. Por exemplo, para chamar o aplicativo do Bloco de Notas do Windows da linha de comando do WSL, insira: /mnt/c/Windows/System32/notepad.exe
Para alterar o usuário padrão para root use este comando no PowerShell: C:\> lxrun /setdefaultuser root e execute Bash.exe para fazer logon: C:\> bash.exe. Redefina sua senha usando o comando de senha de distribuições: $ passwd username e feche a linha de comando do Linux: $ exit. No prompt de comando do Windows ou no Powershell, redefina o usuário padrão de volta para sua conta de usuário normal do Linux: C:\> lxrun.exe /setdefaultuser username.

Desinstalar a versão herdada do WSL

Se você instalou originalmente o WSL em uma versão do Windows 10 antes da atualização do Creators (outubro de 2017, Build 16299), recomendamos que você migre todos os arquivos, dados, etc. necessários da distribuição mais antiga do Linux instalada para uma distribuição mais recente instalada por meio da Microsoft Store. Para remover a distribuição herdada do computador, execute o seguinte de uma linha de comando ou instância do PowerShell: wsl --unregister Legacy. Você também tem a opção de remover manualmente a distribuição herdada mais antiga excluindo a pasta %localappdata%\lxss\ (e todo o seu sub-conteúdo) usando o Explorador de Arquivos do Windows ou com o PowerShell: rm -Recurse $env:localappdata/lxss/.