Treinamento
Roteiro de aprendizagem
Configurar a rede para clientes Windows - Training
Configurar a rede para clientes Windows MD-100
Não há mais suporte para esse navegador.
Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.
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.
Os problemas do repositório de produtos do WSL permitem que você:
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.Também é possível:
Falha na instalação com o erro 0x80070003
C:
). Verifique se as distribuições estão armazenadas na unidade do sistema:WslRegisterDistribution falhou com o erro 0x8007019e
Ocorreu falha na instalação com o erro 0x80070003 ou 0x80370102
Erro ao tentar fazer upgrade: Invalid command line option: wsl --set-version Ubuntu 2
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.
%USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...
wsl --set-version
deve funcionar.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.
wsl.exe
no PowerShell Core ou no prompt de comando.Erro: o Subsistema do Windows para Linux não tem distribuições instaladas.
\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.
This update only applies to machines with the Windows Subsystem for Linux
.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.
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.
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.
É 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.
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
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.
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.
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.
Habilite o recurso Plataforma de Máquina Virtual do Windows e verifique se a virtualização está habilitada na BIOS.
Verifique os requisitos do sistema do Hyper-V
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
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.
Reinicie o computador depois de habilitar o componente opcional Virtual Machine Platform
.
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
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.
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.
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:
Você pode encontrar instruções sobre como alterar essa configuração de Firewall em Configurar o firewall do Hyper-V.
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
.
ipconfig.exe /all
sudo cp /etc/resolv.conf /etc/resolv.conf.new
do resolv.conf existentesudo unlink /etc/resolv.conf
do resolv.conf atualsudo mv /etc/resolv.conf.new /etc/resolv.conf
/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
/etc/resolv.conf
e Depois de desconectar a VPN, você precisará reverter as alterações para /etc/resolv.conf
. Para isso, faça o seguinte:
cd /etc
sudo mv resolv.conf resolv.conf.new
sudo ln -s ../run/resolvconf/resolv.conf resolv.conf
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.
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:
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:
Quando habilitado, o seguinte se aplica às configurações de proxy em suas distribuições do Linux:
HTTP_PROXY
, é definida como um ou mais proxies HTTP encontrados instalados na configuração de proxy HTTP do Windows.HTTPS_PROXY
, é definida como um ou mais proxies HTTPS encontrados instalados na configuração de proxy HTTP do Windows.NO_PROXY
, está definida para ignorar quaisquer proxies HTTP/S encontrados nos destinos de configuração do Windows.WSL_PAC_URL
, é definida como maiúsculas e minúsculas. Por exemplo: HTTP_PROXY
e http_proxy
.Há um problema conhecido causado pelas configurações do ZScaler, em que o ele habilita e desabilita repetidamente as configurações de proxy do Windows, levando o WSL a mostrar repetidamente a notificação "Uma alteração de proxy HTTP foi detectada no host".
Saiba mais no blog de linha de comando: atualização do WSL de setembro de 2023.
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:
/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.Saiba mais no blog de linha de comando: atualização do WSL de setembro de 2023.
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:
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) |
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.
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
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. Isso é realizado através do protocolo mDNS (Multicast DNS), que depende do tráfego multicast para funcionar.
networkingMode definido como NAT:
Atualmente, não há suporte para esse recurso quando o túnel DNS está ativado. Para habilitar a resolução de nomes .local, recomendamos as seguintes soluções:
networkingMode definido como Espelhado:
Observação: você precisa estar no WSL build 2.3.17 ou superior para ter a funcionalidade abaixo.
Como o modo Espelhado dá suporte ao tráfego multicast, o protocolo mDNS (Multicast DNS) pode ser usado para resolver nomes .local. O Linux deve ser configurado para dar suporte ao mDNS, pois ele não o faz por padrão. Uma maneira de configurá-lo é usar as duas etapas a seguir:
sudo apt-get install libnss-mdns
O pacote "libnss-mdns" é um plugin para a funcionalidade do GNU Name Service Switch (NSS) da GNU C Library (glibc) que fornece resolução de nomes de host via Multicast DNS (mDNS). Esse pacote permite que programas comuns do Unix/Linux resolvam nomes no domínio ad-hoc mDNS .local.
/etc/nsswitch.conf
para habilitar a configuração "mdns_minimal" na seção "hosts". Exemplo de conteúdo do arquivo:cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat systemd
group: compat systemd
shadow: compat
gshadow: files
hosts: files mdns_minimal [NOTFOUND=return] dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
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
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.
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
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.
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.
Há dois componentes do Subsistema do Windows para Linux que podem exigir atualização.
Para atualizar o próprio Subsistema do Windows para Linux, use o comando wsl --update
no PowerShell ou no CMD.
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.
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:
Grave o seguinte no /usr/sbin/policy-rc.d
e salve suas alterações.
#!/bin/sh
exit 101
Adicione permissões de execução a /usr/sbin/policy-rc.d
:
chmod +x /usr/sbin/policy-rc.d
Execute os comandos a seguir:
dpkg-divert --local --rename --add /sbin/initctl
ln -s /bin/true /sbin/initctl
Isso tem a ver com o fato de não damos suporte ao console herdado. Para desligar o console herdado:
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.
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
%windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux
. Alguns usuários relataram problemas com aplicativos de firewall específicos que bloqueiam o acesso à Internet no WSL. Os firewalls relatados são:
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.
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.
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
Altere o tipo de despejo de memória para "despejo de memória completo". Ao alterar o tipo de despejo, anote seu tipo atual.
Use as etapas para configurar a falha usando o controle de teclado.
Reproduza o travamento ou o deadlock.
Cause uma falha no sistema usando a sequência de teclas de (2).
O sistema falhará e coletará o despejo de memória.
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.
Restaure o tipo de despejo de memória para a configuração original.
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.
Para localizar o número de build do Windows Server, execute o seguinte no PowerShell:
systeminfo | Select-String "^OS Name","^OS Version"
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
Falha ao tentar conectar seu servidor SSH com o seguinte erro: "Conexão encerrada pela porta 22, 127.0.0.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
Interrompa o serviço SSHD e inicie o SSHD no modo de depuração:
sudo service ssh stop
sudo /usr/sbin/sshd -d
Verifique os logs de inicialização e 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
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.
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.
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:
echo $PATH
./mnt/c/Windows/system32
, isso significa que algo está redefinindo a variável PATH padrão.cat /etc/profile
.cat /etc/wsl.conf
e se não contém appendWindowsPath=false
. Caso contrário, faça um comentário.wsl -t
, depois o nome da distribuição ou execute wsl --shutdown
no cmd ou no PowerShell.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.
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
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\""
.[distro.exe] /?
. Por exemplo, com o Ubuntu: C:\> ubuntu.exe /?
.$PATH
./mnt/c/Windows/System32/notepad.exe
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
.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/
.
Comentários do Windows Subsystem for Linux
O Windows Subsystem for Linux é um projeto código aberto. Selecione um link para fornecer comentários:
Treinamento
Roteiro de aprendizagem
Configurar a rede para clientes Windows - Training
Configurar a rede para clientes Windows MD-100