Solução de problemas do subsistema Windows para Linux

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

Registar um problema, relatar um erro, pedido de funcionalidade

O assuntos do repositório de produtos WSL permitem-lhe:

• 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 "state:open" para incluir problemas que já foram resolvidos na sua pesquisa.

  Por favor, considere comentar ou dar um 'gosto' em quaisquer questões em aberto que gostaria de expressar o seu interesse em avançar como uma prioridade.

• Registre um novo problema. Se você encontrou um problema com a WSL e não parece haver um problema existente, você pode selecionar o botão verde "New issue" e, em seguida, escolher "WSL - Bug Report".

  Você precisa fornecer as seguintes informações:

  • Título do Problema
  • Versão do Windows: Por favor, execute cmd.exe /c ver para obter a compilação do Windows em que você está.
  • Versão WSL: Se você estiver executando o Subsistema Windows para Linux da Microsoft Store, execute wsl.exe -v.
  • Você está usando WSL 1 ou WSL 2: Diga-nos se o problema está no WSL 2 e/ou WSL 1. Você pode dizer correndo wsl.exe -l -v.
  • Versão do kernel: Por favor, diga-nos qual versão do kernel Linux você está usando, ou se você está usando um kernel personalizado. Você pode executar wsl.exe --status se esse comando estiver disponível para você ou executando cat /proc/version em sua distro.
  • Versão da distro: Por favor, diga-nos qual distro você está usando (se aplicável). Você pode obter informações adicionais sobre a versão sempre que possível, por exemplo, no Debian / Ubuntu, run lsb_release -r.
  • Outro Software: Se você estiver relatando um bug envolvendo a interação da WSL com outros aplicativos, informe-nos. Que aplicações? Que versões?
  • Repro Steps: Por favor, liste as etapas para reproduzir seu bug.
  • Comportamento esperado: O que você esperava ver? Inclua exemplos relevantes ou links de documentação.
  • Comportamento real: O que aconteceu em vez disso?
  • Logs de diagnóstico: forneça diagnósticos adicionais, se necessário. Consulte as orientações para obter informações sobre como reunir logs do Hub de Feedback, logs de rede e muito mais.

  Para obter mais informações, consulte contribuindo para o WSL.

• Envie uma solicitação de recurso selecionando o botão verde "New issue" e, em seguida, selecione "Feature request".

  Terá de responder a algumas perguntas descrevendo o seu pedido.

Você também pode:

• Registre um problema de documentação usar o repositório de documentos do WSL. Para contribuir com os documentos WSL, consulte o guia do colaborador do Microsoft Docs .
• Arquivar um problema relacionado ao Terminal do Windows utilizando o repositório do produto Terminal do Windows se o problema estiver mais relacionado ao Terminal do Windows, ao Console do Windows ou à interface da linha de comando.

Problemas de instalação

• instalação falhou com erro 0x80070003

  • O Subsistema Windows para Linux só é executado na unidade do sistema (geralmente esta é a sua unidade C:). Certifique-se de que as distribuições estão armazenadas na unidade do sistema:
  • No Windows 10, abra Configurações ->Sistema ->Armazenamento ->Mais configurações de armazenamento: Alterar onde o novo conteúdo é salvo
  • No Windows 11, abra Configurações ->System ->Storage ->Configurações avançadas de armazenamento ->Onde o novo conteúdo é salvo

• WslRegisterDistribution falhou com erro 0x8007019e

  • O componente opcional do Subsistema Windows para Linux não está habilitado:
  • Abra o Painel de Controle ->Programas e Recursos ->Ativar ou desativar o Recurso do Windows -> Verifique o Subsistema do Windows para Linux ou usando o cmdlet do PowerShell mencionado na etapa 1.

• Instalação falhou com erro 0x80070003 ou erro 0x80370102

  • Certifique-se de que a virtualização está ativada dentro do BIOS do seu computador. As instruções sobre como fazer isso variam de computador para computador e, muito provavelmente, estarão em opções relacionadas à CPU.
  • O WSL2 requer que sua CPU suporte o recurso Second Level Address Translation (SLAT), 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, opção de linha de comando inválida: wsl --set-version Ubuntu 2

  • Certifique-se de que tem o Subsistema Windows para Linux ativado e de que está a utilizar a compilação do Windows 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 ficheiros do disco rígido virtual têm de ser descomprimidos e não encriptados e não devem ser esparsos.

  • Desmarque "Compactar conteúdo" (bem como "Criptografar conteúdo" se estiver marcado) abrindo a pasta de perfil para sua distribuição Linux. Ele deve estar localizado em uma pasta no seu sistema de arquivos do Windows, algo como: %LocalAppData%\Packages\CanonicalGroupLimited...
  • Neste perfil de distribuição Linux, deve haver uma pasta LocalState. Clique com o botão direito do rato nesta pasta para apresentar um menu de opções. Selecione Propriedades>avançadas e, em seguida, verifique se as caixas de seleção "Compactar conteúdo para economizar espaço em disco" e "Criptografar conteúdo para proteger dados" estão desmarcadas (não marcadas). Se você for perguntado se deve aplicar isso apenas à pasta atual ou a todas as subpastas e arquivos, selecione "apenas esta pasta" porque você está limpando apenas o sinalizador de compactação. Depois disso, o comando wsl --set-version deve funcionar.

  

  Observação

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

  Consulte a thread do GitHub do WSL Docs #4103 onde esse problema está sendo acompanhado 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 Windows Subsystem for 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 partir do PowerShell Coreou do Prompt de Comando.

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

  • Se receber este erro depois de já ter instalado distribuições WSL:
  1. Execute a distribuição pelo menos uma vez antes de invocá-la a partir da linha de comando.
  2. Verifique se você pode estar executando contas de usuário separadas. A execução da sua conta de utilizador principal com permissões elevadas (no modo de administração) não deve resultar neste erro, mas deve certificar-se de que não está a executar acidentalmente a conta de Administrador incorporada que vem com o Windows. Esta é 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 integrada.
  3. O executável WSL só é instalado no diretório nativo do sistema. Quando você está executando um processo de 32 bits no Windows de 64 bits (ou no 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 %SystemRoot%\SysWOW64.) Você pode acessar o sistema "nativo"32 a partir de um processo hospedado procurando na pasta virtual: \Windows\sysnative. Na verdade, ele não estará presente no disco, note-se, mas o sistema de resolução de caminhos o encontrará.

• Erro: Esta atualização só se aplica a máquinas com o Subsistema Windows para Linux.

  • Para instalar o pacote MSI de atualização do kernel Linux, o WSL é necessário e deve ser ativado primeiro. Se falhar, você verá a mensagem: Esta atualização só se aplica a máquinas com o Subsistema Windows para Linux.
  • Há três possíveis motivos pelos quais você vê essa mensagem:

  1. Você ainda está na versão antiga do Windows, que não suporta WSL 2. Consulte Etapa 2 - Verificar os requisitos para executar o WSL 2.

  2. A WSL não está ativada. Você precisará retornar à etapa 1 e garantir que o recurso WSL opcional esteja ativado em sua máquina.

  3. Depois de ativar o WSL, é necessária uma reinicialização para que ele entre em vigor, reinicie a máquina e tente novamente.

• Erro: O WSL 2 requer uma atualização para seu componente kernel. Para obter informações, visite a etapa 4

  • Se o pacote do kernel Linux estiver faltando na %SystemRoot%\system32\lxss\tools pasta, você encontrará esse erro. Resolva-o instalando o pacote MSI de atualização do kernel Linux na etapa 4 destas instruções de instalação. Pode ser 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 WSL 2

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

Se você clicar em "Verificar atualizações" e ainda não receber a atualização, poderá instalar o KB KB4566116 manualmente.

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

Isso pode acontecer quando a configuração 'Idioma de exibição' ou 'Localidade do sistema' não estiver em inglês.

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

O erro real é 0x1bc : o WSL 2 requer uma atualização para seu componente kernel. Para mais informações, por favor visite https://aka.ms/wsl2kernel

Para obter mais informações, consulte a edição #5749

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

Um servidor de arquivos de protocolo 9p fornece o serviço no lado Linux para permitir que o Windows acesse o sistema de arquivos Linux. Se você não pode 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 9p, e isso mostrará todos os erros. 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

Por favor, veja a edição #5307 para mais discussão sobre este assunto.

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

Se o seu idioma de apresentação não for inglês, é possível que esteja a ver uma versão truncada de um texto de erro.

PS C:\> wsl.exe
WSL 2

Para resolver esse problema, consulte a etapa 4 e instale o kernel manualmente seguindo as instruções na 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 clicar em "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 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, então muito provavelmente seu PATH está sendo substituído pelo shell do Linux.

Aqui está um exemplo 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 leva a alguns outros problemas com WSL e 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 a edição #5296 e a edição #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.

1. Verifique os requisitos do sistema Hyper-V

2. Se a sua máquina for uma VM, ative virtualização aninhada manualmente. Inicie o powershell com admin e execute o seguinte comando, substituindo-<VMName> pelo nome da máquina virtual em seu sistema host (você pode encontrar o nome no seu Hyper-V Manager):

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

3. Siga as diretrizes do fabricante do seu PC sobre como habilitar a virtualização. Em geral, isso pode envolver o uso do BIOS do sistema para garantir que esses recursos estejam habilitados na sua CPU. As instruções para este processo podem variar de máquina para máquina, consulte Ativar virtualização no Windows.

4. Reinicie a máquina depois de ativar o componente opcionalPlataforma de Máquina Virtual.

5. Certifique-se de que a inicialização do hipervisor está ativada na configuração de inicialização. Você pode validar isso executando powershell elevado:

   bcdedit /enum | findstr -i hypervisorlaunchtype
   

   Se vir hypervisorlaunchtype Off, então o hipervisor está desativado. Para habilitá-lo, execute no PowerShell com elevação de privilégios.

   bcdedit /set hypervisorlaunchtype Auto
   

6. Além disso, no caso de ter hipervisores de terceiros instalados (como o VMware ou o VirtualBox), certifique-se de que estes estão nas versões mais recentes que suportam o HyperV (VMware 15.5.5+ e VirtualBox 6+) ou que estão desativados.

7. Se estiver a receber este erro numa Máquina Virtual do Azure, verifique se de Início Fidedigno está desativada. Virtualização Aninhada não é suportada em máquinas virtuais do Azure com Trusted Launch.

Saiba mais sobre como Configurar de Virtualização Aninhada ao executar Hyper-V em uma máquina virtual.

A WSL não tem conexão de rede na minha máquina de trabalho ou em um ambiente corporativo

Os ambientes empresariais ou de empresa podem ter configurações do Firewall do Windows Defender configuradas para bloquear o tráfego de rede não autorizado. Se a fusão da regra local estiver definida como "Não", a rede WSL não funcionará por padrão; o administrador precisará adicionar uma regra de firewall para permitir o seu funcionamento.

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

1. Abra o "Firewall do Windows Defender com segurança avançada" (isso é diferente de "Firewall do Windows Defender" no Painel de Controle)
2. Clique com o botão direito do rato no separador "Firewall do Windows Defender com segurança avançada no computador local"
3. Selecione "Propriedades"
4. Selecione a guia "Perfil público" na nova janela que se abre
5. Selecione "Personalizar" na seção "Configurações"
6. Verifique a janela "Personalizar configurações para o perfil público" que se abre para ver se "Mesclagem de regras" está definido como "Não". Isso bloqueará o acesso à WSL.

Pode encontrar instruções sobre como alterar esta definição de Firewall em Configurar Hyper-V firewall .

A WSL não tem conexão de rede ao desabilitar o IPv6

Se o IPv6 estiver desabilitado usando o valor HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters (REG_DWORD) DisabledComponentsdo Registro, a conectividade de rede WSL poderá falhar. Consulte Orientações para configurar o IPv6 no Windows para utilizadores avançados.

Se o IPv6 precisar ser desabilitado no sistema host, recomendamos usar o Powershell para fazer isso removendo diretamente as ligações do protocolo IPv6. Por exemplo: Disable-NetAdapterBinding -Name "<MyAdapter>" -ComponentID ms_tcpip[6].

A WSL não tem conectividade de rede uma vez conectada a uma VPN

Se, ao conectar-se a uma VPN no Windows, o bash perder a conectividade de rede, tente esta solução alternativa no próprio bash. Esta solução alternativa permitirá que o utilizador substitua manualmente a resolução DNS através de /etc/resolv.conf.

1. Anote o servidor DNS da VPN fazendo:

   ipconfig.exe /all
   

2. Faça uma cópia do :resolv.conf

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

3. Desvincule o atual resolv.conf:

   sudo unlink /etc/resolv.conf
   

4. Executar:

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

5. Edite /etc/wsl.conf e adicione esse conteúdo ao arquivo. (Mais informações sobre esta configuração podem ser encontradas em Configurações avançadas)

   [network]
   generateResolvConf=false
   

6. Aberto /etc/resolv.conf e

   1. Exclua a primeira linha do arquivo que tem um comentário descrevendo a geração automática.
   2. Adicione a entrada DNS de (1) acima como a primeira entrada na lista de servidores DNS.
   3. Feche o arquivo.

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

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

Problemas do Global Secure Access Client com a WSL

O Global Secure Access Client (/entra/global-secure-access/how-to-install-windows-client) pode afetar a conectividade WSL, pois 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 a WSL, pois o tráfego da WSL é encaminhado abaixo de grande parte dos ganchos do cliente GSA.

Recomendamos desativar o Túnel DNS (dnsTunneling=false) ou desativar o Modo Espelhado (networkingMode=nat).

Problemas do Cisco Anyconnect VPN com WSL no modo NAT

O Cisco AnyConnect VPN modifica rotas de uma forma que impede que o NAT funcione. Há uma solução alternativa específica para o WSL 2: Consulte Cisco AnyConnect Secure Mobility Client Administrator Guide, Release 4.10 - Troubleshoot AnyConnect.

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

O modo de rede espelhada é atualmente uma configuração experimental no WSL Configuration. A arquitetura de rede NAT tradicional do WSL pode ser atualizada para um modo de rede totalmente novo chamado "Modo de rede espelhado". 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 da WSL de setembro de 2023.

Algumas VPNs foram testadas e confirmadas como incompatíveis com a 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 ficheiro de configuração WSL. Ao aplicar essa configuração, observe estas considerações:

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

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

• A variável de ambiente 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 Linux, HTTPS_PROXY, é definida como um ou mais proxies HTTPS encontrados instalados na configuração de proxy HTTPS do Windows.
• A variável de ambiente Linux, NO_PROXY, está definida para ignorar quaisquer proxies HTTP/S encontrados nos destinos de configuração do Windows.
• Todas as variáveis de ambiente, exceto WSL_PAC_URL, são configuradas para minúsculas e maiúsculas. Por exemplo: HTTP_PROXY e http_proxy.

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

Saiba mais no blog da linha de comando: atualização da WSL de setembro de 2023.

Considerações de rede com túnel DNS

Quando a WSL não consegue 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 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 de rede e permitir que você obtenha melhor conectividade com a Internet, mesmo se você tiver uma VPN, 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 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 WSL quando o túnel DNS está habilitado.
• O arquivo /etc/resolv.conf em sua distribuição Linux tem uma limitação máxima de 3 servidores DNS, enquanto o Windows pode usar mais de 3 servidores DNS. Usar o túnel DNS remove essa limitação – todos os servidores DNS do Windows agora podem ser usados pelo Linux.
• A WSL usará sufixos DNS do Windows na seguinte ordem (semelhante à ordem usada pelo cliente DNS do Windows):
  1. Sufixos DNS globais
  2. Sufixos DNS suplementares
  3. Sufixos DNS por interface
  4. Se a criptografia DNS (DoH, DoT) estiver habilitada no Windows, a criptografia será aplicada às consultas DNS do WSL. Se os usuários quiserem habilitar DoH, DoT dentro do Linux, eles precisam desativar o túnel DNS.
• As consultas DNS de contêineres do Docker gerenciados pelo Docker Desktop ignorarão o túnel DNS. O Docker Desktop tem a sua própria maneira (diferente do túnel de DNS) de aplicar as definições e políticas de DNS do anfitrião às consultas DNS dos contêineres Docker.
• Para que o túnel DNS seja habilitado com sucesso, a opção generateResolvConf no arquivo wsl.conf não deve ser desabilitada.
• Quando o túnel DNS está habilitado, a generateHosts opção no arquivo wsl.conf é ignorada (o arquivo de hosts DNS do Windows não é copiado no arquivo /etc/hosts do Linux). As políticas no arquivo de hosts do Windows serão aplicadas a consultas DNS do Linux, sem a necessidade de o arquivo ser copiado no Linux.

Saiba mais no blog da linha de comando: atualização da WSL de setembro de 2023.

Problemas com o direcionamento do tráfego de entrada recebido pelo host Windows para a máquina virtual WSL

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

• Porta UDP 68 (DHCP)
• Porta TCP 135 (resolução de ponto final 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)

A WSL configurará automaticamente determinadas configurações de rede Linux ao usar o modo de rede espelhada. Não há suporte para quaisquer configurações de usuário dessas configurações ao usar o modo de rede espelhado. Aqui está a lista de configurações que a WSL irá configurar:

Problemas de contêiner do Docker no WSL2 com o modo de rede espelhada habilitado ao ser executado sob o namespace de rede padrão

Há um problema conhecido no qual os contêineres do Docker Desktop com portas publicadas (docker run –publish/–p) não serão criados. A equipe da 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 através da --network host opção usada no docker run comando. Uma solução alternativa é listar o número da porta publicada na definição ignoredPorts da seção experimental no arquivo de configuração do WSL.

Problemas de contêiner do Docker quando o Network Manager está em execução

Há um problema conhecido com contêineres do Docker que têm o serviço Network Manager em execução. Os sintomas incluem falhas ao tentar fazer conexões de loopback com o host. Recomenda-se parar o serviço Network Manager para que a rede WSL seja configurada corretamente.

sudo systemctl disable network-manager.service

Resolver nomes .local no WSL

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

networkingMode definido como NAT:

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

• Desative o túnel DNS.
• Use o modo de rede espelhada.

networkingMode definido como Mirrored:

Nota: Você precisa estar na WSL build 2.3.17 ou superior para ter a funcionalidade abaixo.

Como o modo espelhado suporta tráfego multicast, o protocolo mDNS (Multicast DNS) pode ser usado para resolver nomes .local. O Linux deve ser configurado para suportar mDNS, pois não o faz por padrão. Uma maneira de configurá-lo é usando estas duas etapas a seguir:

1. Instalar o pacote libnss-mdns

   sudo apt-get install libnss-mdns
   

   *O libnss-mdns pacote é um plugin para a funcionalidade GNU Name Service Switch (NSS) da GNU C Library (glibc) que fornece resolução de nome de host via DNS Multicast (mDNS). Este pacote permite efetivamente que programas Unix/Linux comuns resolvam nomes no domínio ad-hoc mDNS .local.

2. Configure o /etc/nsswitch.conf arquivo para habilitar a mdns_minimal configuração na hosts seção . Exemplo de conteúdo do ficheiro:

   />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 ficheiro .wslconfig, o WSL terá o seguinte comportamento com respeito aos sufixos DNS:

Quando networkingMode está definido como NAT:

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

Caso 2: Se o túnel DNS estiver ativado (dnsTunneling está definido como true em .wslconfig) Todos os sufixos search DNS do Windows são configurados no Linux, na configuração 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 há uma alteração nos sufixos DNS do Windows, essa alteração será refletida automaticamente no Linux

Caso 3: Se o túnel DNS estiver desativado e o proxy DNS SharedAccess estiver desativado (dnsTunnelingdnsProxy e estiver definido como false .wslconfig). Um único sufixo DNS é configurado no Linux, na configuração "domínio" de /etc/resolv.conf

Quando há uma alteração nos sufixos DNS do Windows, essa alteração não é 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 é 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 a partir da interface com maior probabilidade de fornecer conectividade com a Internet.

Quando networkingMode está definido como Mirrored:

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

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

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

Solução de problemas de DNS no WSL

A configuração de 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 consultas DNS são enviadas do contêiner WSL para esse dispositivo NAT no host 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 a WSL pede inicialmente ao HNS para criar 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 pela 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 configurado para usar o túnel DNS.

   Pode-se 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 3 perfis: Domínio, Privado e Público. Se estiver definido em qualquer perfil, os pacotes serão bloqueados se a vNIC WSL receber esse perfil (o padrão é Public). Este é apenas um trecho do primeiro perfil de Firewall retornado no Powershell:

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

   AllowLocalFirewallRules: False significa que as regras de firewall definidas localmente, como a do HNS, não serão aplicadas ou usadas.

2. E o Enterprise pode reduzir as configurações de Diretiva de Grupo e de Diretiva MDM que bloqueiam todas as regras de entrada.

   Essas configurações substituem qualquer regra de firewall Allow-Inbound. Essa configuração bloqueará, portanto, a regra de firewall UDP criada pelo HNS e, portanto, impedirá que a 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 NAT.

   Da Diretiva de Grupo:

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

   "Firewall do Windows Defender: Não permitir exceções" - Ativado

   Da Política de MDM:

   ./Fornecedor/MSFT/Firewall/MdmStore/PrivateProfile/Blindado

   ./Fornecedor/MSFT/Firewall/MdmStore/DomainProfile/Blindado

   ./Fornecedor/MSFT/Firewall/MdmStore/PublicProfile/Protegido

   Pode-se ver se isso está configurado para não permitir nenhuma regra de Firewall de entrada executando o seguinte (veja as advertências acima em Perfis de Firewall). Este é apenas um trecho do primeiro perfil de Firewall retornado no Powershell:

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

   AllowInboundRules: False significa que nenhuma regra de Firewall de entrada será aplicada.

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 suporta uma opção de aceitação do usuário para a mesma configuração que pode ser aplicada por uma empresa referenciada em #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", verificar o controle rotulado "Bloqueia todas as conexões de entrada, incluindo aquelas na lista de aplicativos permitidos".

   Se isso for definido para o perfil Public (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.

   Isso deve ser desmarcado para que a configuração de proxy DNS NAT funcione a partir de WSL, ou WSL pode ser definida 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 dentro do HNS que foi corrigida com a versão mais recente do Windows 11. Em versões anteriores, se isso ocorrer, não é facilmente detetável, mas tem uma solução simples:

   • Parar WSL

     wsl.exe –shutdown
     

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

     hnsdiag.exe delete all
     

   • Reinicializar ou reiniciar o serviço de rede 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. Por favor, veja se o driver FSE está em execução:

Get-Service FSE

Se isso não mostrar o FSE em execução, verifique se o valor do PortTrackerEnabledMode Registro sai sob esta chave do Registro:

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

Se o FSE não estiver em execução ou instalado e PortTrackerEnabledMode existir, exclua esse valor do Registro e reinicie

Maneira manual de excluir adaptadores fantasmas

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

1. Abra o Gestor de Dispositivos

2. Ver > Mostrar dispositivos ocultos

   

3. Abrir adaptadores de rede

   

4. Clique com o botão direito do mouse sobre o adaptador de rede Ghosted e selecione desinstalar dispositivo

   

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

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

Atualizar o WSL

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

1. Para atualizar o Subsistema Windows para Linux em si, use o seguinte comando.

   wsl.exe --update
   

2. Para atualizar os binários específicos do usuário da distribuição Linux, use o seguinte comando na distribuição Linux que você deseja atualizar.

   apt-get update | apt-get upgrade
   

Erros de atualização do apt-get

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

Para corrigir problemas relacionados com udev, siga os seguintes passos:

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

   #!/bin/sh
   exit 101
   

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

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

3. 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 que não suportamos consoles legados. Para desativar o console herdado:

1. Abrir cmd.exe
2. Clique com o botão direito do rato na barra de título -> Propriedades -> Desmarque Usar terminal herdado
3. Clique em OK

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

O recurso Subsistema do Windows para Linux pode ser desativado durante uma atualização do Windows. Se isso acontecer, o recurso do Windows deve ser reativado. Instruções para ativar o Subsistema Windows para Linux podem ser encontradas no Guia de Instalação Manual .

Alterar o idioma de apresentação

A instalação do WSL tentará alterar automaticamente a localidade do Ubuntu para corresponder à localidade da sua instalação do Windows. Se você não quiser esse comportamento, você pode executar este comando para alterar a localidade do Ubuntu após a conclusão da instalação. Terá de reiniciar bash.exe para que esta 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 Windows

1. Exclua a pasta %SystemRoot%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux.

   Advertência

   Não faça isso se o recurso opcional estiver totalmente instalado e funcionando.

2. Ativar o recurso opcional WSL (se ainda não houver)

3. Reinicialização

4. lxrun /desinstalar /full

5. Instalar bash

Sem acesso à internet na 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. Proteção de ponto final da Symantec

Em alguns casos, desligar o firewall permite o acesso. Em alguns casos, simplesmente ter o firewall instalado parece 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 a Atualização de Aniversário do Windows, versão 1607, os privilégios de administrador no Windows são necessários para serem executados ping no WSL. Para executar pingo , execute o Bash no Ubuntu no Windows como administrador ou execute bash.exe a partir de um prompt do 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.

Bash está congelado

Se, ao trabalhar com bash, você achar que o bash está suspenso (ou bloqueado) e não responde às entradas, ajude-nos a diagnosticar o problema coletando e relatando um despejo de memória. Note que estes passos irão causar uma quebra no seu sistema. Não faça isso se você não estiver confortável com isso ou salve seu trabalho antes de fazer isso.

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 o tipo atual.

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

3. Reproduza o bloqueio ou impasse.

4. Faça o sistema falhar usando a sequência de teclas de (2).

5. O sistema irá entrar em falha e recolher o despejo de memória.

6. Quando o sistema for reinicializado, informe 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 e-mail, observe que o dump é para a equipe WSL ou Bash no Windows.

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

Verifique o seu número de compilação

Para encontrar a arquitetura do seu PC e o número de compilação do Windows, abra Configurações>do sistema>Sobre

Procure os campos Compilação do SO e Tipo de sistema .

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

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

Confirmar se o WSL está ativado

Você pode confirmar se o Subsistema Windows para Linux está habilitado executando o seguinte em uma janela elevada do PowerShell:

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

OpenSSH-Server problemas de conexão

A tentativa de conectar seu servidor SSH falhou com o seguinte erro: "Conexão fechada pela porta 22 127.0.0.1".

1. Certifique-se de que o seu OpenSSH Server está em execução:

   sudo service ssh status
   

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

2. Pare 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 HostKeys estão disponíveis e que 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
   

Caso veja essas mensagens e as chaves estiverem faltando em /etc/ssh/, você terá que regenerar as chaves ou simplesmente eliminar&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 ativar o recurso opcional WSL

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

• Se você estiver executando o comando enable WSL feature do PowerShell, tente usar a GUI abrindo o menu Iniciar, procurando por 'Ativar ou desativar recursos do Windows' e, em seguida, na lista, selecione 'Subsistema do Windows para Linux', que instalará o componente opcional.

• Atualize a sua versão do Windows acedendo a Definições, Atualizações e clicando em 'Procurar Atualizações'

• Se ambos falharem e você precisar acessar o WSL, considere atualizar no local reinstalando o Windows usando a mídia de instalação e selecionando 'Manter tudo' para garantir que seus aplicativos e arquivos sejam preservados. Pode encontrar instruções sobre como fazê-lo na página Reinstalar o Windows 10.

Corrigir erros de permissão (relacionados a SSH)

Se estiver a ver 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 este comando incluirá metadados e modificará as permissões de arquivo nos arquivos do Windows vistos do WSL. Consulte as permissões do sistema de ficheiros para obter mais informações.

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: O arquivo não pode ser acessado pelo sistema.

É um problema conhecido, ao usar a versão Store do WSL. Você pode contornar isso hoje usando o WSL 1 ou usando a versão no Windows do WSL. Consulte WSL na Microsoft Store 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" em execução powershell.exe /c start . ou qualquer outro comando do Windows, você pode resolvê-lo seguindo estas etapas:

1. Na sua distribuição WSL, execute echo $PATH. Se não incluir: /mnt/c/Windows/system32 algo está redefinindo a variável PATH padrão.
2. Verifique as configurações de perfil com cat /etc/profile. Se ele contiver atribuição da variável PATH, edite o arquivo para comentar o bloco de atribuição PATH com um caractere #.
3. Verifique se wsl.conf está presente cat /etc/wsl.conf e certifique-se de que não contém appendWindowsPath=false, caso contrário, adicione um comentário para o omitir.
4. Reinicie a distribuição digitando wsl -t <Distro> seguido do nome da distribuição ou execute wsl --shutdown qualquer um no PowerShell.

Não é possível inicializar após a instalação do WSL 2

Estamos cientes de um problema que afeta os usuários onde eles não conseguem inicializar após a instalação do WSL 2. Embora diagnostiquemos totalmente esses problemas, os usuários relataram que alterar o tamanho do buffer ou instalar os drivers corretos pode ajudar a resolver isso. Por favor, veja este problema do GitHub para ver as atualizações mais recentes sobre este problema.

Erros WSL 2 quando o ICS está desativado

O Compartilhamento de Conexão com a Internet (ICS) é um componente necessário do WSL 2. O serviço ICS é usado pelo Serviço de Rede Host (HNS) 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 diretiva de grupo impedirá que a rede WSL HNS seja criada. Isso resultará em falhas ao criar uma nova imagem WSL versão 2 e o seguinte erro ao tentar converter uma imagem versão 1 para a versão 2: Não há mais pontos de extremidade disponíveis no mapeador de pontos de extremidade.

Os sistemas que requerem o WSL 2 devem deixar o serviço ICS (SharedAccess) no seu estado de início predefinido, Manual (Trigger Start), e qualquer política que desative o ICS deve ser substituída ou removida. Embora a desativação do serviço ICS interrompa o WSL 2 e não recomendemos a desativação do ICS, partes do ICS podem ser desativadas usando estas instruções

Usando versões mais antigas do Windows e 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 para Criadores do Windows 10 (outubro de 2017, Build 16299) ou a Atualização de Aniversário (Aug 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 comandos de interoperabilidade:

• bash.exe foi substituído por wsl.exe. Os comandos do Linux podem ser executados a partir do PowerShell, mas para versões anteriores do Windows, talvez seja necessário usar o bash comando. 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 deve-se tomar cuidado para escapar de caracteres 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 Bloco de Notas do Windows a partir da linha de comando 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 e execute Bash.exe para fazer logon: C:\> bash.exe. Redefina sua senha usando o comando distributions password: $ passwd username e feche a linha de comando do Linux: $ exit. No prompt de comando do Windows ou Powershell, redefina seu 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 migre todos os arquivos, dados, etc. necessários da distribuição Linux mais antiga instalada para uma distribuição mais recente instalada por meio da Microsoft Store. Para remover a distribuição herdada da sua máquina, execute o seguinte a partir 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 todos os seus subconteúdos) usando o Explorador de Arquivos do Windows ou com o PowerShell: Remove-Item -Recurse $env:localappdata/lxss/.

Código de erro 0x8000FFFF falha inesperada

Este código de erro normalmente significa que houve uma falha inesperada, ou "catastrófica", durante as operações do sistema ao tentar instalar ou usar uma distrubução Linux (como o Ubuntu) com WSL. Há muitas razões que podem levar a este fracasso. Comece verificando o seguinte:

• Trata-se de um problema de permissões? Verifique se você está conectado como o usuário esperado em sua linha de comando e tem os privilégios de administrador necessários ao instalar uma distrubution Linux com WSL. (Clique com o botão direito do rato no ícone da barra de tarefas do Terminal ou da Linha de Comandos para selecionar "Executar como Administrador".)
• Você atualizou a WSL para a versão mais recente? Use o comando: wsl --update para atualizar para a versão mais recente. Você também pode querer atualizar para a versão mais recente do Windows.
• Certifique-se de que você está usando o wsl --install comando corretamente e especificando a distrubution Linux que você pretende instalar.
• Tente desligar e reiniciar o WSL, usando o comando: wsl --shutdown.
• Se estiver a utilizar o Windows Server, certifique-se de que a sua versão está atualizada e siga o Guia de Instalação do Windows Server.
• Se você suspeitar que isso pode estar relacionado a arquivos de sistema ausentes ou corrompidos, a partir de um prompt de comando elevado (Executar como administrador), você pode verificar e reparar arquivos do sistema e/ou reparar a imagem do sistema operacional Windows. Para procurar e reparar ficheiros de sistema do Windows danificados ou em falta, utilize o comando: SFC /SCANNOW. Para reparar a própria imagem do Windows, use o comando: DISM /Online /Cleanup-Image /RestoreHealth.
• Consulte a edição 9420 relacionada ao repositório de produtos WSL.