Solução de problemas do Subsistema Windows para Linux

  • Artigo

Nós abordamos alguns cenários comuns de solução de problemas associados ao WSL abaixo, mas considere também pesquisar os problemas registrados no repositório de produto do WSL no GitHub.

Registrar um problema, relatar bugs, solicitar recurso

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

  • Pesquise 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 polegar para cima para qualquer problema aberto que você gostaria de expressar seu interesse em avançar como prioridade...
  • Registrar um problema novo. Se você encontrou um problema com o WSL e parece que ainda não existe um problema registrado, você pode selecionar o botão Novo problema verde e escolher o WSL – Relatar Bug. Você precisará incluir um título para o problema, o número de build do seu Windows (execute cmd.exe /c ver para ver o número de build atual), se você está executando o WSL 1 ou 2, o número da versão do Kernel do Linux atual (execute wsl.exe --status ou cat /proc/version), o número da versão da sua distribuição (execute lsb_release -r), outras versões de software envolvidas, as etapas de reprodução, o comportamento esperado, o comportamento real e os logs de diagnóstico, se disponíveis e apropriados. Para obter mais informações, confira contribuindo com o WSL.
  • Registre uma solicitação de recurso selecionando o botão verde Novo problema e escolhendo Solicitação de recurso. Você precisará responder algumas perguntas para descrever sua solicitação.

Também é possível:

Problemas de instalação

  • Falha na instalação com o erro 0x80070003

    • O Subsistema Windows para Linux é executado somente na unidade do sistema (normalmente, a unidade C:). Verifique se as distribuições estão armazenadas na unidade do sistema:
    • No Windows 10, abra Configurações ->Sistema ->Armazenamento ->Mais Configurações de Armazenamento: Altere onde o novo conteúdo é salvoImagem das configurações do sistema para instalar aplicativos na unidade C: (Windows 10)
    • No Windows 11, abra Configurações ->Sistema ->Armazenamento ->Configurações avançadas de armazenamento ->Onde o novo conteúdo é salvoImagem das configurações do sistema para instalar aplicativos na unidade C: (Windows 11)

  • WslRegisterDistribution falhou com o erro 0x8007019e

    • O componente opcional do Subsistema Windows para Linux não está habilitado:
    • Abra Painel de Controle ->Programas e Recursos ->Ativar ou Desativar Recursos do Windows -> Selecione Subsistema do Windows para Linux ou use o cmdlet do PowerShell mencionado no início deste artigo.

  • Ocorreu falha na instalação com o erro 0x80070003 ou 0x80370102

    • Verifique se a virtualização está habilitada dentro do BIOS do seu computador. As instruções para fazer isso variam de um computador para o outro e muito provavelmente estarão sob 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 no AMD Opteron. As CPUs mais antigas (como o Intel Core 2 Duo) não poderão executar o WSL2, mesmo se a plataforma da máquina virtual for instalada com êxito.

  • Erro ao tentar fazer upgrade: 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 com a versão do Build 18362 ou superior. 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 do disco rígido virtual precisam ser descompactados e descriptografados e não podem 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. Ela deve estar localizada em uma pasta no sistema de arquivos do Windows, algo como: %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...
    • Nesse perfil de distribuição do Linux, deve haver uma pasta LocalState. Clique com o botão direito do mouse nessa pasta para exibir um menu de opções. Selecione Propriedades > Avançadas 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 da propriedade de distribuição do WSL

Observação

No meu caso, a pasta LocalState da minha distribuição do Ubuntu 18.04 estava localizada em C:\Users<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc

Para obter informações atualizadas, verifique o thread 4103 do GitHub dos documentos do WSL em que esse problema está sendo acompanhado.

  • O termo 'wsl' não é reconhecido como nome de um cmdlet, uma função, um arquivo de script ou um programa operável.

  • Erro: o Subsistema do Windows para Linux não tem distribuições instaladas.

    • Se você receber esse erro depois que já tiver 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. A execução da sua conta de usuário principal com permissões elevadas (no modo admin) não deve resultar nesse erro, mas você deve garantir que não esteja executando acidentalmente a conta de administrador interno que vem com o Windows. Essa é uma conta de usuário separada e não mostrará nenhuma distribuição do WSL instalada por design. Para obter mais informações, confira Habilitar e desabilitar a conta de administrador interno.
    3. O executável do WSL é instalado apenas no diretório nativo do sistema. Quando você estiver executando um processo de 32 bits em Windows de 64 bits (ou em ARM64, qualquer combinação não nativa), o processo não nativo hospedado na verdade verá uma pasta System32 diferente. (Aquele que um processo de 32 bits vê no Windows x64 é armazenado em disco em \Windows\SysWOW64.) Você pode acessar o system32 "nativo" de um processo hospedado examinando a pasta virtual: \Windows\sysnative. Na verdade, ela não estará presente no disco, mas o resolvedor de caminho do sistema de arquivos vai encontrá-la.

  • Erro: esta atualização se aplica somente a computadores com o Subsistema do Windows para Linux.

    • Para instalar o pacote MSI de atualização do kernel do Linux, o WSL é exigido e deve ser habilitado primeiro. Se ele 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 essa mensagem:

    1. Você ainda está usando uma versão antiga do Windows, que não dá suporte ao WSL 2. Confira a etapa nº 2 para obter os requisitos de versão e os links a serem atualizados.

    2. O WSL não está habilitado. Você precisará retornar à etapa nº 1 e verificar se o recurso opcional do WSL está habilitado no seu computador.

    3. Depois que você habilitar o WSL, uma reinicialização será exigida para que ele entre em vigor. Reinicialize o computador e tente novamente.

  • Erro: o WSL 2 exige uma atualização do componente kernel. Para obter mais informações, visite https://aka.ms/wsl2kernel.

    • Se o pacote do kernel do Linux está ausente na pasta %SystemRoot%\system32\lxss\tools, você encontra esse erro. Resolva-o instalando o pacote MSI de atualização do kernel do Linux na etapa nº 4 das instruções de instalação. Talvez você precise desinstalar o MSI em 'Adicionar ou Remover Programas' e instalar ele novamente.

Problemas comuns

Estou usando o Windows 10, versão 1903, e ainda não vejo as opções relacionadas ao WSL 2

É provável que seu computador ainda não tenha feito o backport para o WSL 2. A maneira mais simples de resolver isso é indo até as Configurações do Windows e clicando em "Verificar Atualizações" para instalar as atualizações mais recentes no sistema. Veja as instruções completas sobre como fazer o backport.

Se você clicar em 'Verificar Atualizações' e ainda não receber a atualização, instale a Base de Dados de Conhecimento KB4566116 manualmente.

Erro: 0x1bc quando wsl --set-default-version 2

Isso pode acontecer quando a configuração de '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 em 0x1bc é:

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

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

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

Um servidor de arquivos do protocolo 9P fornece o serviço no lado do Linux para permitir que o Windows acesse o sistema de arquivos do Linux. Se você não conseguir acessar o WSL usando o \\wsl$ no Windows, isso poderá ser devido a uma inicialização incorreta do 9P.

Para conferir isso, é possível verificar os logs de inicialização usando dmesg |grep 9p, o que mostra os erros existentes. Uma saída bem-sucedida tem a seguinte aparência:

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

Confira este thread do GitHub para discussões mais aprofundadas sobre esse problema.

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

Se seu idioma de exibição não for inglês, talvez 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 da documentação.

command not found ao executar o Windows .exe no Linux

Os usuários podem executar os executáveis do Windows, como o notepad.exe, diretamente do Linux. Às vezes, a saída pode ser "command not found", como no seguinte exemplo:

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

Se não houver caminhos Win32 em seu $PATH, a interoperabilidade não encontrará o .exe. Você pode verificá-lo 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 consegue ver nenhum caminho do Windows, é provável que PATH esteja 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

No Debian, a maneira correta é remover as linhas acima. Você também pode acrescentar $PATH durante a atribuição da maneira abaixo, mas isso resulta em alguns 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, confira o problema 5296 e o 5779.

"Error: 0x80370102. Não foi possível iniciar a máquina virtual porque um recurso necessário não está instalado. "

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

  1. Verifique os requisitos do sistema do Hyper-V

  2. Se o 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 no sistema host (você pode encontrar o nome no Gerenciador do Hyper-V):

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

  3. Siga as diretrizes do fabricante do seu PC sobre como habilitar a virtualização. Geralmente, isso envolve o uso da BIOS do sistema para garantir que esses recursos estejam habilitados em sua CPU. As instruções desse processo podem variar de acordo com o computador. Confira este artigo do Bleeping Computer para obter um exemplo.

  4. Reinicie o computador depois de habilitar o componente opcional Virtual Machine Platform.

  5. Verifique se a inicialização do hipervisor está habilitada nas suas configurações de inicialização. Você pode validar isso executando (powershell com privilégios elevados):

     bcdedit /enum | findstr -i hypervisorlaunchtype

    Se você vir hypervisorlaunchtype Off, o hipervisor será desabilitado. Para habilitá-lo, execute em um powershell com privilégios elevados:

     bcdedit /set hypervisorlaunchtype Auto

  6. Além disso, se você tiver hipervisores de terceiros instalados (como VMware ou VirtualBox), verifique se você os tem nas versões mais recentes que são compatíveis com o HyperV (VMware 15.5.5+ e VirtualBox 6+) ou se estão desligados.

  7. Se você estiver recebendo esse erro em uma Máquina Virtual do Azure, verifique para garantir que o Início Confiável esteja desabilitado. Não há suporte para virtualização aninhada em máquinas virtuais do Azure.

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 Windows Defender Firewall definidas para bloquear o tráfego de rede não autorizado. Se a mesclagem de regra local estiver definida como "Não", a rede 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 regra local seguindo estas etapas:

Captura de tela das configurações do Windows Firewall

  1. Abra "Windows Defender Firewall com Segurança Avançada" (é diferente do "Windows Defender" no Painel de Controle)
  2. Clique com o botão direito do mouse na guia "Windows Defender Firewall com Segurança Avançada em Computador Local"
  3. Selecione "Propriedades"
  4. Selecione a guia "Perfil Público" na nova janela que é aberta
  5. Selecione "Personalizar" na seção "Configurações"
  6. Verifique a janela "Personalizar Configurações para o Perfil Público" aberta para ver se "Mesclagem de Regra" está definido como "Não". Isso bloqueará o acesso ao WSL.

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

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

Se, depois de se conectar a uma VPN no Windows, o Bash perder a conectividade de rede, tente essa solução alternativa de dentro do Bash. Essa solução alternativa permitirá que você substitua manualmente a resolução DNS por meio do /etc/resolv.conf.

  1. Anote o servidor DNS da VPN ao fazer ipconfig.exe /all
  2. Faça uma cópia do sudo cp /etc/resolv.conf /etc/resolv.conf.new do resolv.conf existente
  3. Desvincule o sudo unlink /etc/resolv.conf do resolv.conf atual
  4. sudo mv /etc/resolv.conf.new /etc/resolv.conf
  5. Edite /etc/wsl.conf e adicione esse conteúdo ao arquivo. (Mais informações sobre essa configuração podem ser encontradas em Configuração de definições avançadas)
[network]
generateResolvConf=false
  1. Abra /etc/resolv.conf e
    a. Exclua 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 isso, faça o seguinte:

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

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

A VPN do Cisco AnyConnect modifica as rotas de uma maneira que impede que o NAT funcione. Há uma solução alternativa específica para o WSL 2: confira Guia do Administrador do Cliente do 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

Atualmente, o modo de rede espelhada é 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 de 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 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 definirá 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: variáveis de ambiente definidas pelo usuário têm precedência sobre as especificadas por este 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, é definida como 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 como maiúsculas e minúsculas. Por exemplo: HTTP_PROXY e http_proxy.

Saiba mais no blog de 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 dnsTunneling na seção experimental do arquivo de Configuração do WSL. Ao aplicar essa configuração, observe estas considerações:

  • O Docker nativo pode ter problemas de conectividade no WSL quando o túnel DNS está habilitado, se a rede tiver uma política para bloquear o tráfego DNS para: 8.8.8.8.8
  • 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 de 3 servidores DNS no máximo, 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 (Docker Desktop ou Docker nativo em execução no WSL) ignorarão o túnel DNS. O túnel DNS não pode ser aproveitado para aplicar as configurações e políticas de DNS do host ao tráfego DNS do Docker.
  • O Docker Desktop tem sua própria maneira (diferente do túnel DNS) de aplicar configurações e políticas de DNS de host a consultas DNS de contêineres do Docker.

Saiba mais no blog de 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 conjunto experimental networkingMode 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 UDP 5353 (mDNS)
  • 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 sã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

Sufixos DNS no WSL

Dependendo das configurações no arquivo .wslconfig, o WSL terá os seguintes sufixos de DNS do wrt de comportamento:

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 (dnsTunneling estiver definido como true em .wslconfig) Todos os sufixos DNS do Windows serão configurados no Linux, na configuração "search" 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 será definido como false e dnsProxy será definido como false em .wslconfig) Um único sufixo DNS será configurado no Linux, na configuração "domínio" de /etc/resolv.conf

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

O único sufixo DNS configurado no Linux é escolhido a partir dos sufixos DNS por interface (sufixos globais e suplementares são ignorados)

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

Quando networkingMode é definido como Espelhado:

Todos os sufixos DNS do Windows são configurados no Linux, na configuração "search" 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

Nota: 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 contrária 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 solicita inicialmente ao HNS a criação de a rede virtual NAT para seu contêiner WSL.

Devido a este NAT - design de acesso compartilhado, existem algumas configurações conhecidas que podem quebrar 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 por política empresarial.

Quando isso é definido por uma empresa, a regra de firewall criada pelo 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 de todos os 3 perfis: Domínio, Privado e Público. Se 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 reduzir as configurações de Política de Grupo e de política MDM que bloqueiam todas as regras de entrada.

Essas configurações substituem qualquer regra de Permissão de Firewall de Entrada. Essa configuração, portanto, 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 o Túnel DNS. Essa configuração sempre bloqueará o proxy DNS do 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 Standard

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

Da Política de MDM:

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

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

./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 advertências 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 para "Bloqueia todas as conexões de entrada, incluindo aquelas na lista de aplicativos permitidos".

O Windows oferece suporte a uma aceitação de usuário para a mesma configuração que pode ser aplicada por uma empresa mencionada no item 2 acima. Os usuários podem abrir a página de configurações "Segurança do Windows", selecionar a opção "Firewall e Proteção de Rede", selecionar o Perfil de Firewall que desejam configurar (Domínio, Privado ou Público) e, em "Conexões de entrada", marcar o controle rotulado "Bloquear todas as conexões de entrada, incluindo aquelas na lista de aplicativos permitidos".

Se isso for definido para o perfil Público (esse é 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.

Isso deve ser desmarcado para que a configuração do proxy DNS NAT funcione a partir do WSL ou o WSL pode ser definido para usar o túnel DNS.

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

  • Interromper o WSL

    wsl.exe –shutdown

  • Exclua a regra antiga de Firewall do HNS. Este 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. Nota: se o HNS for usado para gerenciar outros contêineres, como MDAG ou Windows Sandbox, eles também deverão ser interrompidos.

    hnsdiag.exe delete all

  • Reinicializar ou reiniciar o serviço HNS

    Restart-Service hns

  • Quando o WSL for reiniciado, o HNS criará novas regras de Firewall, direcionando corretamente a interface do WSL.

Solucionar problemas de acesso à rede no Windows

Se você não tiver acesso à rede, pode ser devido a uma configuração incorreta. Veja 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 é encerrado sob essa chave do Registro: reg query HKLM\System\CurrentControlSet\Services\Tcpip\Parameters. Se o FSE não estiver em execução ou instalado, e o PortTrackerEnabledMode existir, exclua esse valor do Registro e reinicialize

Maneira manual de excluir adaptadores fantasmas

Adaptadores fantasmas, ou dispositivos Plug and Play (PnP) fantasmas, referem-se a componentes de hardware que aparecem em seu 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 máquina virtual (VM), siga estas etapas manuais para encontrar e excluir esses dispositivo PnP Phantom. A Microsoft está trabalhando em uma solução automatizada que não exigirá intervenção manual. Mais informações serão divulgadas em breve.

  1. Abra o Gerenciador de Dispositivos
  2. Exibir > Mostrar dispositivos ocultos

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

  1. Abrir adaptadores de rede

Captura de tela da lista de adaptadores de rede

  1. Clique com o botão direito do mouse sobre o adaptador de rede Fantasma e selecione Desinstalar dispositivo

Captura de tela do clique com o botão direito do mouse em um pnp fantasma da lista de rede e da seleção do dispositivo de desinstalação

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 em nosso GitHub.

Atualização do WSL

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

  1. Para atualizar o próprio Subsistema do Windows para Linux, use o comando wsl --update no PowerShell ou no CMD.

  2. Para atualizar os binários de usuário da distribuição do Linux específicos, use o comando: apt-get update | apt-get upgrade na distribuição do Linux que você quer atualizar.

Erros de atualização do apt-get

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

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

  1. Grave o seguinte no /usr/sbin/policy-rc.d e salve suas alterações.

    #!/bin/sh
exit 101

  2. Adicione permissões de execução a /usr/sbin/policy-rc.d:

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

  3. Execute os comandos a seguir:

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

"Error: 0x80040306" na instalação

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

  1. Abra cmd.exe
  2. Clique com o botão direito do mouse na barra de título -> Propriedades -> desmarque Usar console herdado
  3. Clique em OK

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

O recurso Subsistema Windows para Linux pode ser 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.

Como alterar 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á reiniciar o bash.exe para que essa alteração entre em vigor.

O exemplo abaixo altera a localidade para en-US:

sudo update-locale LANG=en_US.UTF8

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

  1. 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.
  2. Habilitar o recurso opcional do WSL (se ainda não estiver habilitado)
  3. Reinicialização
  4. lxrun /uninstall /full
  5. Instale o Bash

Sem acesso à Internet no WSL

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

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

Em alguns casos, desligar o firewall permite o acesso. Em outros, simplesmente ter o firewall instalado bloqueia o acesso.

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

Erro de permissão negada ao usar ping

Para a Atualização de Aniversário do Windows, versão 1607, são necessários privilégios de administrador no Windows para executar o ping no WSL. Para executar o ping, execute o Bash do 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 e posteriores, os privilégios de administrador não são mais necessários.

Bash suspenso

Se, ao trabalhar com o Bash, você descobrir que ele está suspenso (ou em deadlock) e não está respondendo às entradas, ajude-nos a diagnosticar o problema coletando e relatando um despejo de memória. Observe que essas etapas apresentarão falha no sistema. Não faça isso se não estiver familiarizado ou salve seu trabalho antes.

Para coletar um despejo de memória

  1. Altere o tipo de despejo de memória para "despejo de memória completo". Ao alterar o tipo de despejo, anote seu tipo atual.

  2. Use as etapas para configurar a falha usando o controle de teclado.

  3. Reproduza o travamento ou o deadlock.

  4. Cause uma falha no sistema usando a sequência de teclas de (2).

  5. O sistema falhará e coletará o despejo de memória.

  6. Após a reinicialização do sistema, relate o memory.dmp a secure@microsoft.com. A localização padrão do arquivo de despejo será %SystemRoot%\memory.dmp ou C:\Windows\memory.dmp se a unidade do sistema for C:. No email, observe que o despejo é para o WSL ou Bash na equipe do Windows.

  7. Restaure o tipo de despejo de memória para a configuração original.

Verifique o número de build

Para encontrar a arquitetura do seu PC 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 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"

Confirme 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

Problemas de conexão do servidor OpenSSH

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

  1. Verifique se o servidor OpenSSH está em execução:

    sudo service ssh status

    e que você seguiu este tutorial: https://ubuntu.com/server/docs/service-openssh

  2. Interrompa o serviço SSHD e inicie o SSHD no modo de depuração:

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

  3. Verifique os logs de inicialização e certifique-se de que as HostKeys estejam disponíveis e que você não veja 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 servidor OpenSSH:

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

"Não foi possível encontrar o assembly referenciado." ao habilitar o recurso opcional WSL

Este erro está relacionado a um estado de instalação inadequado. Conclua as etapas a seguir para tentar corrigir esse problema:

  • Se você estiver executando o comando Habilitar recurso WSL do PowerShell, tente usar a GUI em vez de abrir o menu Iniciar, pesquisando "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 ambas falharem e você precisar acessar o WSL, considere atualizar no local reinstalando o Windows com uma mídia de instalação e selecionando "Manter Tudo" para que seus aplicativos e arquivos sejam preservados. É possível encontrar instruções para fazer isso na página Reinstalar o Windows 10.

Se você vir 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

Ao adicionar esse comando, você incluirá metadados e modificará as permissões do arquivo nos arquivos Windows vistos em WSL. Confira as Permissões do sistema de arquivos para saber mais.

Falha ao usar WSL remotamente usando 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 da Store do WSL. Você pode contornar esse problema hoje usando o WSL 1 ou usando a versão no Windows do WSL. Confira https://aka.ms/wslstoreinfo para obter mais informações.

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

Algumas distribuições disponíveis na Microsoft Store ainda não são totalmente compatíveis com a execução de comandos do Windows. Caso receba o erro -bash: powershell.exe: command not found ao executar powershell.exe /c start . ou outro comando do Windows, será possível resolvê-lo seguindo estas etapas:

  1. Na distribuição de WSL, execute echo $PATH.
    Caso ele não inclua /mnt/c/Windows/system32, isso significa que algo está redefinindo a variável PATH padrão.
  2. Verifique as configurações de perfil com cat /etc/profile.
    Caso ele contenha uma atribuição da variável PATH, edite o arquivo para fazer comentários no bloco de atribuição PATH com um caractere # .
  3. Verifique se wsl.conf está presente em cat /etc/wsl.conf e se não contém appendWindowsPath=false. Caso contrário, faça um comentário.
  4. Reinicie a distribuição digitando wsl -t , depois o nome da distribuição ou execute wsl --shutdown no cmd ou no PowerShell.

Não foi possível realizar a inicialização após a instalação do WSL 2

Estamos cientes de um problema que afeta os usuários, no qual eles não conseguem realizar a inicialização após a instalação do WSL 2. Embora possamos diagnosticar totalmente esses problemas, os usuários relataram que alterar o tamanho do buffer ou instalar os drivers corretos pode ajudar a resolver isso. Exiba este problema do GitHub para conferir 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 do ICS é usado pelo HNS (Serviço de Rede Host) para criar a rede virtual subjacente da qual o WSL 2 depende para NAT, DNS, DHCP e compartilhamento da conexão com o host.

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

There are no more endpoints available from the endpoint mapper.

Sistemas que exigem o WSL 2 devem deixar o serviço do ICS (SharedAccess) no estado de início padrão, Manual (Início do Gatilho), e qualquer política que desabilitar o ICS deverá ser substituída ou removida. O ICS quebrará o WSL 2 se for desabilitado e, embora não seja recomendado desabilitá-lo, partes do ICS podem ser desabilitadas usando estas instruções

Uso de versões mais antigas do Windows e do WSL

Há várias diferenças a serem observadas se você está executando uma versão mais antiga do Windows e do WSL, como a Atualização do Windows 10 para Criadores (outubro de 2017, Build 16299) ou 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 anteriores do Windows, você precisa usar o comando bash. Por exemplo: C:\temp> bash -c "ls -la". Os comandos do WSL passados para bash -c são encaminhados para o processo do WSL sem modificação. Os caminhos de arquivo devem ser especificados no formato do WSL e é necessário 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 determinada distribuição, 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 do WSL em uma versão anterior do Windows 10, será necessário especificar o caminho do diretório. Por exemplo, para chamar o aplicativo Bloco de notas do Windows na linha de comando do WSL, digite: /mnt/c/Windows/System32/notepad.exe
  • Para alterar o usuário padrão para root, use este comando no PowerShell: C:\> lxrun /setdefaultuser root; depois, execute Bash.exe para fazer logon: C:\> bash.exe. Redefina sua senha usando o comando de senha da distribuição: $ 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 o WSL originalmente em uma versão do Windows 10 antes da atualização para criadores (outubro de 2017, Build 16299), recomendamos que migre todos os arquivos, dados necessários etc. 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 seu computador, execute o seguinte em uma linha de comando ou uma 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 o seu subconteúdo) usando o Explorador de Arquivos do Windows ou com o PowerShell: rm -Recurse $env:localappdata/lxss/.