Solucionar problemas del subsistema de Windows para Linux

  • Artículo

A continuación se abordan algunos escenarios comunes de solución de problemas asociados con WSL, pero considere la posibilidad de buscar también los problemas notificados en el repositorio de productos de WSL en GitHub.

Presentación de un problema, un informe de errores o una solicitud de característica

Los problemas del repositorio de productos de WSL le permiten:

  • Buscar problemas existentes para ver si hay algún asociado que experimenta el mismo problema. Tenga en cuenta que, en la barra de búsqueda, puede quitar "is:open" para incluir los problemas que ya se han resuelto en la búsqueda. Considere la posibilidad de comentar o indicar que le gusta algún problema abierto para el que le gustaría expresar interés de seguir como una prioridad.
  • Presentación de un nuevo problema. Si ha experimentado un problema con WSL y parece que no existe, puede seleccionar el botón verde Nuevo problema y, a continuación, elegir WSL - Informe de errores. Deberá incluir un título para el problema, el número de compilación de Windows (ejecute cmd.exe /c ver para ver el número de compilación actual), tanto si ejecuta WSL 1 o 2, el número de versión actual del kernel de Linux (ejecute wsl.exe --status o cat /proc/version), el número de versión de la distribución (ejecute lsb_release -r), cualquier otra versión de software implicada, los pasos de reproducción, el comportamiento esperado, el comportamiento real y los registros de diagnóstico si están disponibles y son adecuados. Para más información, consulte Contribución a WSL.
  • Para presentar una solicitud de característica, seleccione el botón verde Nuevo problema y, a continuación, seleccione Solicitud de característica. Tendrá que atender algunas preguntas de descripción de la solicitud.

También puede:

Problemas de instalación

  • Error 0x80070003 en la instalación

    • El Subsistema de Windows para Linux solo se ejecuta en la unidad del sistema (normalmente se trata de la unidad C:). Asegúrate de que las distribuciones estén almacenadas en la unidad del sistema:
    • En Windows 10, abra Configuración ->Sistema ->Almacenamiento ->Más opciones de almacenamiento: Cambiar la ubicación de almacenamiento del contenido nuevoImagen de la configuración del sistema para instalar aplicaciones en la unidad C: (Windows 10)
    • En Windows 11, abra Configuración ->Sistema ->Almacenamiento ->Configuración avanzada de almacenamiento ->Ubicación de almacenamiento del contenido nuevoImagen de la configuración del sistema para instalar aplicaciones en la unidad C: (Windows 11)

  • Error 0x8007019e de WslRegisterDistribution

    • El componente opcional del Subsistema de Windows para Linux no está habilitado:
    • Abra el Panel de control ->Programas y características ->Activar o desactivar la característica de Windows -> Seleccione Subsistema de Windows para Linux o use el cmdlet de PowerShell mencionado al comienzo de este artículo.

  • Error en la instalación 0x80070003 o 0x80370102

    • Asegúrate de que la virtualización está habilitada dentro del BIOS del equipo. Las instrucciones sobre cómo hacerlo variarán de un equipo a otro y lo más probable es que esta característica esté en opciones relacionadas con la CPU.
    • WSL2 requiere que la CPU admita la característica de traducción de direcciones de segundo nivel (SLAT), que se introdujo en procesadores Intel Nehalem (primera generación Intel Core) y AMD Opteron. Las CPU anteriores (como Intel Core 2 Duo) no podrán ejecutar WSL2, incluso si la plataforma de máquina virtual está instalada correctamente.

  • Error al intentar actualizar: Invalid command line option: wsl --set-version Ubuntu 2

    • Asegúrese de que el Subsistema de Windows para Linux esté habilitado y de que usa la compilación de Windows 18362 o posterior. Para habilitar WSL, ejecute este comando en un símbolo del sistema de PowerShell con privilegios de administrador: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux.

  • La operación solicitada no se pudo completar debido a una limitación del sistema de disco virtual. Los archivos de disco duro virtual deben estar sin comprimir y sin cifrar y no deben ser dispersos.

    • Anule la selección de la casilla "Compress contents" ("Comprimir contenido") (y también la de "Cifrar los contenidos" si está activada). Para ello, abra la carpeta de perfil de la distribución de Linux. Debe encontrarse en una carpeta del sistema de archivos de Windows, como %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited....
    • En este perfil de distribución de Linux, debe haber una carpeta denominada LocalState. Haga clic con el botón derecho en ella para mostrar un menú de opciones. Seleccione Propiedades > Opciones avanzadas y, a continuación, asegúrese de que las casillas "Comprimir contenido para ahorrar espacio en disco" y "Cifrar contenido para proteger datos" no estén seleccionadas (activadas). Si se le pregunta si quiere aplicar esto solo a la carpeta actual o a todas las subcarpetas y archivos, seleccione "solo esta carpeta", ya que solo quiere borrar la marca de compresión. A continuación, el comando wsl --set-version debería funcionar.

Captura de pantalla de la configuración de la propiedad de distribución de WSL

Nota

En mi caso, la carpeta LocalState de la distribución de Ubuntu 18.04 se encontraba en C:\Users<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc.

Consulte el subproceso n.º 4103 de la documentación sobre WSL en GitHub, en el que se realiza el seguimiento de este problema para obtener información actualizada.

  • El término 'wsl' no se reconoce como nombre de cmdlet, función, archivo de script o programa ejecutable.

  • Error: el Subsistema de Windows para Linux no tiene ninguna distribución instalada.

    • Si recibe este error después de haber instalado las distribuciones de WSL:
    1. Ejecute la distribución al menos una vez antes de invocarla desde la línea de comandos.
    2. Compruebe si puede ejecutar cuentas de usuario independientes. La ejecución de la cuenta de usuario principal con permisos elevados (en modo de administrador) no debería producir este error, pero debe asegurarse de que no ejecuta accidentalmente la cuenta de administrador integrada que viene con Windows. Se trata de una cuenta de usuario independiente y no mostrará ninguna distribución de WSL instalada por diseño. Para obtener más información, consulte Habilitar y deshabilitar la cuenta integrada de administrador.
    3. El archivo ejecutable de WSL solo se instala en el directorio del sistema nativo. Cuando se ejecuta un proceso de 32 bits en un Windows de 64 bits (o en ARM64, cualquier combinación no nativa), el proceso no nativo hospedado realmente ve una carpeta System32 diferente. (El que ve un proceso de 32 bits en Windows x64 se almacena en disco en \Windows\SysWOW64). Para acceder al sistema "nativo" System32 desde un proceso hospedado, busque en la carpeta virtual: \Windows\sysnative. En realidad, no estará presente en el disco, pero el solucionador de rutas de acceso del sistema de archivos la encontrará.

  • Error: Esta actualización solo se aplica a las máquinas con el Subsistema de Windows para Linux.

    • Para instalar el paquete MSI de actualización del kernel de Linux, WSL es necesario y debe habilitarse primero. Si se produce un error, verá el mensaje: This update only applies to machines with the Windows Subsystem for Linux.
    • Hay tres posibles motivos para ver este mensaje:

    1. Todavía tiene una versión antigua de Windows que no es compatible con WSL 2. Consulte el paso 2 para conocer los requisitos de la versión y los vínculos de la actualización.

    2. WSL no está habilitado. Tendrá que volver al paso 1 y asegurarse de que la característica WSL opcional está habilitada en la máquina.

    3. Después de habilitar WSL, es necesario un reinicio para que surta efecto. Reinicie la máquina e inténtelo de nuevo.

  • Error: WSL 2 requiere una actualización en su componente de kernel. Para obtener más información, visite https://aka.ms/wsl2kernel.

    • Si falta el paquete del kernel de Linux en la carpeta %SystemRoot%\system32\lxss\tools, se mostrará este error. Para resolverlo, instale el paquete MSI de actualización del kernel de Linux en del paso 4 de estas instrucciones de instalación. Es posible que deba desinstalar el paquete MSI desde "Agregar o quitar programas" e instalarlo de nuevo.

Problemas comunes

Tengo la versión 1903 de Windows 10 y sigo sin ver las opciones de WSL 2

Probablemente, se debe a que la máquina aún no ha adquirido la adaptación para WSL 2. La forma más sencilla de resolverlo es dirigirse a Configuración de Windows y hacer clic en "Buscar actualizaciones" para instalar las actualizaciones más recientes en el sistema. Consulte las instrucciones completas sobre cómo adquirir la adaptación.

Si pulsa "Buscar actualizaciones" y sigue sin recibir la actualización, puede instalar KB KB4566116 manualmente.

Error: 0x1bc cuando wsl --set-default-version 2

Puede ocurrir cuando el valor de "Mostrar idioma" o "Configuración regional del sistema" no es Inglés.

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

El error real de 0x1bc es:

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

Para obtener más información, consulte el problema 5749.

No se puede acceder a los archivos WSL desde Windows

Un servidor de archivos de protocolo 9P proporciona el servicio en el lado de Linux para permitir que Windows tenga acceso al sistema de archivos de Linux. Si no puede acceder a WSL con \\wsl$ en Windows, podría deberse a que 9P no se inició correctamente.

Para comprobarlo, puede consultar los registros de inicio mediante: dmesg |grep 9p, lo que le mostrará los errores. Una salida correcta se parece a la siguiente:

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

Consulte este subproceso de GitHub para más explicaciones sobre este problema.

No se puede iniciar la distribución WSL 2 y solo se ve "WSL 2" en la salida

Si el idioma para mostrar no es el inglés, es posible que vea una versión truncada de un texto de error.

C:\Users\me>wsl
WSL 2

Para resolver este problema, visite https://aka.ms/wsl2kernel e instale el kernel manualmente siguiendo las instrucciones de esa página de documentación.

command not found al ejecutar el .exe de Windows en Linux

Los usuarios pueden ejecutar archivos ejecutables de Windows como notepad.exe directamente desde Linux. A veces, puede que se encuentre con el mensaje "comando no encontrado", como en el siguiente ejemplo:

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

Si no hay ninguna ruta de acceso Win32 en el parámetro $PATH, interop no encontrará el archivo .exe. Para comprobarlo, puede ejecutar echo $PATH en Linux. Se espera que aparezca una ruta de acceso Win32 (por ejemplo, /mnt/c/Windows) en la salida. Si no se muestra ninguna ruta de acceso de Windows, lo más probable es que el shell de Linux haya sobrescrito el parámetro PATH.

Este es un ejemplo en el que la ruta /etc/profile en Debian contribuyó al 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

La manera correcta de hacerlo en Debian consiste en quitar las líneas anteriores. También puede anexar el parámetro $PATH durante la asignación, como se indica a continuación. No obstante, esto genera otros problemas con WSL y 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

Si quiere obtener más información, consulte las incidencias 5296 y 5779.

"Error: 0x80370102 The virtual machine could not be started because a required feature is not installed" (Error: 0x80370102 No se pudo iniciar la máquina virtual porque una característica necesaria no está instalada).

Habilite la característica de Windows de plataforma de máquina virtual y asegúrese de que la virtualización esté habilitada en el BIOS.

  1. Consulte Requisitos de sistema de Hyper-V.

  2. Si la máquina es una máquina virtual, habilite virtualización anidada manualmente. Inicie PowerShell con el administrador y ejecute el comando siguiente, reemplazando <VMName> por el nombre de la máquina virtual en el sistema host (puede encontrar el nombre en el Administrador de Hyper-V):

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

  3. Siga las instrucciones del fabricante del equipo sobre cómo habilitar la virtualización. En general, esto puede implicar el uso del BIOS del sistema para asegurarse de que estas características se habilitan en la CPU. Las instrucciones para este proceso pueden variar de un equipo a otro. Consulte este artículo de Bleeping Computer para ver un ejemplo.

  4. Reinicie el equipo después de habilitar el componente opcional Virtual Machine Platform.

  5. Asegúrese de que el inicio del hipervisor está habilitado en la configuración de arranque. Puede validar esto ejecutando lo siguiente (PowerShell con privilegios elevados):

     bcdedit /enum | findstr -i hypervisorlaunchtype

    Si ve hypervisorlaunchtype Off, el hipervisor está deshabilitado. Para habilitar este elemento, ejecute una instancia de PowerShell con privilegios elevados:

     bcdedit /set hypervisorlaunchtype Auto

  6. Además, si tiene instalados hipervisores de terceros (por ejemplo, VMware o VirtualBox), asegúrese de que tengan las versiones más recientes que pueden admitir (VMware 15.5.5+ y VirtualBox 6+) o de que estén desactivados.

  7. Si recibe este error en una máquina virtual de Azure, compruebe que el inicio seguro está deshabilitado. La virtualización anidada no se admite en máquinas virtuales de Azure.

Obtenga más información sobre cómo configurar la virtualización anidada al ejecutar Hyper-V en una máquina virtual.

El subsistema WSL no tiene ninguna conexión de red en mi máquina de trabajo o en un entorno empresarial

Es posible que, en los entornos empresariales, la configuración de Firewall de Windows Defender esté establecida para bloquear el tráfico de red no autorizado. Si la combinación de reglas locales se establece en "No", las redes de WSL no funcionarán de forma predeterminada. Para permitir las conexiones, el administrador deberá agregar una regla de firewall.

Para confirmar la configuración de la combinación de reglas locales, siga estos pasos:

Captura de pantalla de la configuración de Firewall de Windows

  1. Abra "Firewall de Windows Defender con seguridad avanzada" (que no es lo mismo que "Firewall de Windows Defender", del Panel de control).
  2. Haga clic con el botón derecho en la pestaña "Firewall de Windows Defender con seguridad avanzada en equipo local".
  3. Seleccione el elemento "Propiedades".
  4. Seleccione la pestaña "Perfil público" en la nueva ventana que se abrirá.
  5. Seleccione el elemento "Personalizar", que se ubica en la sección "Configuración".
  6. Compruebe la ventana "Personalizar configuración para el perfil público" que se abrirá para asegurarse de que el parámetro "Combinación de reglas" está establecido en "No". Esto bloqueará el acceso al subsistema WSL.

Puede encontrar instrucciones sobre cómo cambiar esta configuración de Firewall en Configuración del firewall de Hyper-V.

WSL no tiene conectividad de red si se conecta a una VPN.

Si después de conectarte a una VPN en Windows, Bash pierde la conectividad de red, prueba esta solución desde dentro de Bash. Esta solución alternativa te permitirá invalidar manualmente la resolución de DNS a través de /etc/resolv.conf.

  1. Toma nota del servidor DNS de la VPN con ipconfig.exe /all
  2. Haz una copia del resolv.conf existente sudo cp /etc/resolv.conf /etc/resolv.conf.new
  3. Desvincula el elemento resolv.com actual sudo unlink /etc/resolv.conf
  4. sudo mv /etc/resolv.conf.new /etc/resolv.conf
  5. Edite /etc/wsl.conf y agregue este contenido al archivo. (Puede encontrar más información sobre esta configuración en Configuración avanzada).
[network]
generateResolvConf=false
  1. Abre /etc/resolv.conf y
    a. Elimine la primera línea del archivo que tiene un comentario que describe la generación automática
    b. Agrega la entrada de DNS de (1) anterior como primera entrada de la lista de servidores DNS.
    c. Cierra el archivo.

Una vez que hayas desconectado la VPN, tendrás que revertir los cambios a /etc/resolv.conf. Para ello, haz lo siguiente:

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

Problemas de Cisco Anyconnect VPN con WSL en modo NAT

Cisco AnyConnect VPN modifica las rutas de forma que impide que NAT funcione. Hay una solución alternativa específica de WSL 2: Consulte la Guía del administrador de Cisco AnyConnect Secure Mobility Client, versión 4.10: Solución de problemas de AnyConnect.

Problemas de conectividad de WSL con VPN cuando el modo de red reflejado está activado

El modo de red reflejado es actualmente una configuración experimental en la configuración de WSL. La arquitectura de red NAT tradicional de WSL se puede actualizar a un modo de red completamente nuevo denominado "Modo de red reflejado". Cuando el experimental networkingMode se establece en mirrored, las interfaces de red que tiene en Windows se reflejan en Linux para mejorar la compatibilidad. Obtenga más información en el blog de la línea de comandos: Actualización de septiembre de 2023 de WSL.

Se ha comprobado y confirmado que algunas VPN son incompatibles con WSL, entre ellas:

  • "Bitdefender" versión 26.0.2.1
  • "OpenVPN" versión 2.6.501
  • "Mcafee Safe Connect" versión 2.16.1.124

Consideraciones al usar autoProxy para la creación de reflejos de HttpProxy en WSL

La creación de reflejo del proxy HTTP/S se puede configurar mediante la configuración autoProxy de la sección experimental del archivo de configuración de WSL. Al aplicar esta configuración, tenga en cuenta estas consideraciones:

  • Proxy PAC: WSL configurará la configuración en Linux estableciendo la variable de entorno "WSL_PAC_URL". Linux no admite servidores proxy PAC de forma predeterminada.
  • Interacciones con WSLENV: las variables de entorno definidas por el usuario tienen prioridad sobre las especificadas por esta característica.

Cuando se habilita, se aplica lo siguiente a la configuración de proxy en las distribuciones de Linux:

  • La variable de entorno de Linux, HTTP_PROXY, se establece en uno o varios servidores proxy HTTP que se encuentran instalados en la configuración del proxy HTTP de Windows.
  • La variable de entorno de Linux, HTTPS_PROXY, se establece en uno o varios servidores proxy HTTPS que se encuentran instalados en la configuración del proxy HTTP de Windows.
  • La variable de entorno de Linux, NO_PROXY, se establece para omitir los servidores proxy HTTP/S que se encuentran en los destinos de configuración de Windows.
  • Cada variable de entorno, excepto WSL_PAC_URL, se establece en minúsculas y mayúsculas. Por ejemplo, HTTP_PROXY y http_proxy.

Obtenga más información en el blog de la línea de comandos: Actualización de septiembre de 2023 de WSL.

Consideraciones sobre redes con tunelización DNS

Cuando WSL no se puede conectar a Internet, puede deberse a que la llamada DNS al host de Windows está bloqueada. Esto se debe a que la configuración de red existente bloquea el paquete de red para DNS enviado por la máquina virtual WSL al host de Windows. La tunelización DNS soluciona este problema utilizando una característica de virtualización para comunicarse con Windows directamente, lo que permite resolver el nombre DNS sin enviar un paquete de red. Esta característica debería mejorar la compatibilidad de la red y permitirle obtener una mejor conectividad a Internet aunque tenga una VPN, una configuración de firewall específica u otras configuraciones de red.

La tunelización DNS se puede configurar mediante la configuración dnsTunneling de la sección experimental del archivo de configuración de WSL. Al aplicar esta configuración, tenga en cuenta estas consideraciones:

  • Docker nativo puede tener problemas de conectividad en WSL cuando está habilitada la tunelización DNS, si la red tiene una directiva para bloquear el tráfico DNS a: 8.8.8.8
  • Si usa una VPN con WSL, active la tunelización DNS. Muchas VPN usan directivas NRPT, que solo se aplican a las consultas de DNS de WSL cuando está habilitada la tunelización DNS.
  • El archivo /etc/resolv.conf de la distribución de Linux tiene una limitación máxima de 3 servidores DNS, mientras que Windows puede usar más de 3 servidores DNS. El uso de la tunelización DNS elimina esta limitación: Linux puede usar ahora todos los servidores DNS de Windows.
  • WSL usará sufijos DNS de Windows en el orden siguiente (similar al orden usado por el cliente DNS de Windows):
    1. Sufijos DNS globales
    2. Sufijos DNS complementarios
    3. Sufijos DNS por interfaz
    4. Si el cifrado DNS (DoH, DoT) está habilitado en Windows, el cifrado se aplicará a las consultas de DNS de WSL. Si los usuarios quieren habilitar DoH, DoT dentro de Linux, deben deshabilitar la tunelización DNS.
  • Las consultas de DNS desde contenedores Docker (Docker Desktop o Docker nativo ejecutándose en WSL) omitirán la tunelización DNS. No se puede aprovechar la tunelización DNS para aplicar la configuración y las directivas DNS del host al tráfico DNS de Docker.
  • Docker Desktop tiene su propia manera (diferente de la tunelización DNS) de aplicar la configuración y las directivas DNS del host a las consultas de DNS desde contenedores de Docker.

Obtenga más información en el blog de la línea de comandos: Actualización de septiembre de 2023 de WSL.

Problemas con la dirección del tráfico entrante recibido por el host de Windows a la máquina virtual WSL

Cuando se usa el modo de red reflejado (el conjunto experimental networkingMode en mirrored), el tráfico entrante recibido por el host de Windows nunca se dirige a la máquina virtual Linux. Este tráfico es el siguiente:

  • Puerto UDP 68 (DHCP)
  • Puerto TCP 135 (resolución de punto de conexión DCE)
  • Puerto UDP 5353 (mDNS)
  • Puerto TCP 1900 (UPnP)
  • Puerto TCP 2869 (SSDP)
  • Puerto TCP 5004 (RTP)
  • Puerto TCP 3702 (WSD)
  • Puerto TCP 5357 (WSD)
  • Puerto TCP 5358 (WSD)

WSL configurará automáticamente ciertas opciones de red de Linux al usar el modo de red reflejado. No se admiten las configuraciones de usuario de estas opciones mientras se usa el modo de red reflejado. Esta es la lista de opciones que WSL configurará:

Nombre de la opción de configuración 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/ Deshabilitado (0)
https://sysctl-explorer.net/net/ipv6/accept_ra/ Deshabilitado (0)
https://sysctl-explorer.net/net/ipv6/autoconf/ Deshabilitado (0)
https://sysctl-explorer.net/net/ipv6/use_tempaddr/ Deshabilitado (0)
addr_gen_mode Deshabilitado (0)
disable_ipv6 Deshabilitado (0)
https://sysctl-explorer.net/net/ipv4/arp_filter/ Habilitado (1)

Problemas del contenedor de Docker en WSL2 con el modo de red reflejado habilitado cuando se ejecuta en el espacio de nombres de red predeterminado

Hay un problema conocido en el que los contenedores de Docker Desktop con puertos publicados (docker run –publish/-p) no se crearán. El equipo de WSL está trabajando con el equipo de Docker Desktop para solucionar este problema. Para solucionar el problema, use el espacio de nombres de red del host en el contenedor Docker. Establezca el tipo de red a través de la opción "--network host" que se usa en el comando "docker run". Una solución alternativa consiste en enumerar el número de puerto publicado en el valor de ignoredPorts de la sección experimental del archivo de configuración de WSL.

Problemas del contenedor de Docker cuando se está ejecutando su Administrador de red

Hay un problema conocido con los contenedores de Docker que tienen el servicio Administrador de red en ejecución. Los síntomas incluyen errores al intentar realizar conexiones de bucle invertido al host. Se recomienda detener el servicio de Administrador de red para que las redes WSL se configuren correctamente.

sudo systemctl disable network-manager.service

Sufijos DNS en WSL

Según las configuraciones del archivo .wslconfig, WSL tendrá el siguiente comportamiento wrt DNS sufijos:

Cuando networkingMode está establecido en NAT:

Caso 1) De forma predeterminada, no hay ningún sufijo DNS configurado en Linux

Caso 2) Si la tunelización DNS está habilitada (dnsTunneling se establece en true en .wslconfig) Todos los sufijos DNS de Windows están configurados en Linux, en el valor "search" de /etc/resolv.conf

Los sufijos se configuran en /etc/resolv.conf en el orden siguiente, similar al orden en que el cliente DNS de Windows intenta sufijos al resolver un nombre: sufijos DNS globales primero, luego sufijos DNS complementarios y, a continuación, sufijos DNS por interfaz.

Cuando se produce un cambio en los sufijos DNS de Windows, ese cambio se reflejará automáticamente en Linux

Caso 3) Si la tunelización DNS está deshabilitada y el proxy DNS de SharedAccess está deshabilitado (dnsTunneling se establece en false y dnsProxy se establece en false en .wslconfig) Se configura un único sufijo DNS en Linux, en el valor "dominio" de /etc/resolv.conf

Cuando se produce un cambio en los sufijos DNS de Windows, ese cambio no se refleja en Linux

El sufijo DNS único configurado en Linux se elige entre los sufijos DNS por interfaz (se omiten los sufijos DNS globales y complementarios)

Si Windows tiene varias interfaces, se usa una heurística para elegir el sufijo DNS único que se configurará en Linux. Por ejemplo, si hay una interfaz VPN en Windows, el sufijo se elige de esa interfaz. Si no hay ninguna interfaz VPN, se elige el sufijo de la interfaz que es más probable que proporcione conectividad a Internet.

Cuando networkingMode está establecido en Mirrored:

Todos los sufijos DNS de Windows están configurados en Linux, en la configuración "search" de /etc/resolv.conf

Los sufijos se configuran en /etc/resolv.conf en el mismo orden que en el caso 2) desde el modo NAT.

Cuando se produce un cambio en los sufijos DNS de Windows, ese cambio se reflejará automáticamente en Linux

Nota: Los sufijos DNS complementarios se pueden configurar en Windows mediante SetInterfaceDnsSettings - Aplicaciones Win32 | Microsoft Learn, con la marca DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST establecida en el parámetro Settings

Solución de problemas de DNS en WSL

La configuración de DNS predeterminada cuando WSL inicia un contenedor en modo NAT es que el dispositivo NAT del host de Windows actúe como el "servidor DNS" para el contenedor WSL. Cuando las consultas DNS se envían desde el contenedor WSL a ese dispositivo NAT en el host de Windows, el paquete DNS se reenvía desde el dispositivo NAT al servicio de acceso compartido en el host; la respuesta se envía en la dirección inversa al contenedor WSL. Este proceso de reenvío de paquetes para el acceso compartido requiere una regla de firewall para permitir ese paquete DNS de entrada, que el servicio HNS crea cuando WSL solicita inicialmente a HNS que cree la red virtual NAT para su contenedor WSL.

Debido a esta NAT: diseño de acceso compartido, hay algunas configuraciones conocidas que pueden interrumpir la resolución de nombres de WSL.

1. Una empresa puede insertar una directiva que no permita reglas de firewall definidas localmente, solo lo que permite reglas definidas por directivas empresariales.

Cuando una empresa establece esto, se omite la regla de firewall creada por HNS, ya que es una regla definida localmente. Para que esta configuración funcione, Enterprise debe crear una regla de firewall para permitir el puerto UDP 53 al servicio de acceso compartido o WSL se puede establecer para usar túnel DNS. Puede ver si está configurado para no permitir reglas de firewall definidas localmente mediante la ejecución de lo siguiente. Tenga en cuenta que esto mostrará la configuración de los 3 perfiles: Dominio, Privado y Público. Si se establece en cualquier perfil, los paquetes se bloquearán si la vNIC de WSL se asigna a ese perfil (el valor predeterminado es Público). Este es solo un fragmento de código del primer perfil de firewall que se devuelve en 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. Y Enterprise puede insertar la directiva de grupo y la configuración de directivas MDM que bloquean todas las reglas de entrada.

Esta configuración invalida cualquier regla de firewall de entrada permitida. Por lo tanto, esta configuración bloqueará la regla de firewall UDP creada por HNS y, por tanto, impedirá que WSL resuelva los nombres. Para que esta configuración funcione, WSL debe establecerse para usar la tunelización DNS. Esta configuración siempre bloqueará el proxy DNS NAT.

Desde la directiva de grupo:

Configuración del equipo \ Plantillas administrativas \ Red \ Conexiones de red \ Firewall de Windows Defender \ Perfil de dominio | Perfil estándar

"Firewall de Windows Defender: No permitir excepciones" - Habilitado

Desde la directiva MDM:

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

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

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

Puede ver si está configurado para no permitir ninguna regla de firewall de entrada ejecutando lo siguiente (vea las advertencias anteriores en perfiles de firewall). Este es solo un fragmento de código del primer perfil de firewall que se devuelve en 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. Un usuario pasa por las aplicaciones de configuración de seguridad de Windows y comprueba el control de "Bloquea todas las conexiones entrantes, incluidas las de la lista de aplicaciones permitidas."

Windows admite una participación de usuario para la misma configuración que una empresa a la que se hace referencia en el #2 anterior. Los usuarios pueden abrir la página de configuración de “Seguridad” de Windows“, seleccionar la opción “Firewall y protección de red", seleccionar el perfil de firewall que quieren configurar (Dominio, Privado o Público) y en " Conexiones entrantes" comprobar el control que tiene la etiqueta "Bloquea todas las conexiones entrantes, incluidas las de la lista de aplicaciones permitidas."

Si se establece para el perfil público (este es el perfil predeterminado para la vNIC de WSL), se bloqueará la regla de firewall creada por HNS para permitir que los paquetes UDP accedan compartidos.

Debe desactivarse para que la configuración del proxy DNS NAT funcione desde WSL o WSL se puede establecer para usar la tunelización DNS.

4. La regla de firewall de HNS para permitir que los paquetes DNS tengan acceso compartido pueden dejar de ser válidos, haciendo referencia a un identificador de interfaz WSL anterior. Este es un error en HNS que se ha corregido con la versión más reciente de Windows 11. En versiones anteriores, si esto ocurre, no se puede detectar fácilmente, pero tiene una solución sencilla:

  • Detener WSL

    wsl.exe –shutdown

  • Elimine la antigua regla de firewall de HNS. Este comando de PowerShell debería funcionar en la mayoría de los casos:

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

  • Elimine todos los puntos de conexión de HNS. Nota: si se usa HNS para administrar otros contenedores, como MDAG o Windows Sandbox, también se deben detener.

    hnsdiag.exe delete all

  • Reinicio o reinicio del servicio HNS

    Restart-Service hns

  • Cuando se reinicia WSL, HNS creará nuevas reglas de firewall, que tienen como destino correctamente la interfaz WSL.

Solución de problemas de acceso a la red en Windows

Si no tiene acceso a la red, puede deberse a una configuración incorrecta. Compruebe si el controlador FSE se está ejecutando: "sc queryex FSE". Si eso no muestra la ejecución de FSE, compruebe si el valor del registro PortTrackerEnabledMode se cierra en esta clave del registro: reg query HKLM\System\CurrentControlSet\Services\Tcpip\Parameters. Si FSE no se está ejecutando o instalado y PortTrackerEnabledMode existe, elimine ese valor del registro y reinicie

Forma manual de eliminar adaptadores fantasma

Los adaptadores fantasma o los dispositivos fantasma Plug and Play (PnP), hacen referencia a los componentes de hardware que aparecen en el sistema, pero no están conectados físicamente. Estos dispositivos "fantasma" pueden causar confusión y desorden en la configuración del sistema. Si ve adaptadores fantasma al ejecutar WSL en una máquina virtual (VM), siga estos pasos manuales para buscar y eliminar estos dispositivos PnP fantasma. Microsoft está trabajando en una solución automatizada que no requerirá intervención manual. Próximamente estará disponible más información.

  1. Abra el Administrador de dispositivos
  2. Ver > mostrar dispositivos ocultos

Captura de pantalla del menú Mostrar dispositivos ocultos del Administrador de dispositivos

  1. Abra los adaptadores de red

Captura de pantalla de la lista adaptadores de red

  1. Haga clic con el botón derecho sobre el adaptador de red fantasma y seleccione Desinstalar dispositivo

Captura de pantalla de hacer clic con el botón derecho en un pnp fantasma de la lista de red y seleccionar Desinstalar dispositivo

Iniciar WSL o instalar una distribución devuelve un código de error

Siga las instrucciones para recopilar registros de WSL en el repositorio de WSL en GitHub para recopilar registros detallados y archivar un problema en nuestro GitHub.

Actualización de WSL

Hay dos componentes del Subsistema de Windows para Linux que pueden requerir actualización.

  1. Para actualizar el Subsistema de Windows para Linux, use el comando wsl --update en PowerShell o CMD.

  2. Para actualizar los archivos binarios de usuario de distribución de Linux específicos, use el comando apt-get update | apt-get upgrade en la distribución de Linux que quiere actualizar.

Errores de actualización de apt-get

Algunos paquetes usan características que aún no se han implementado. udev, por ejemplo, todavía no se admite y produce varios errores de tipo apt-get upgrade.

Para corregir los problemas relacionados con udev, sigue estos pasos:

  1. Escribe lo siguiente en /usr/sbin/policy-rc.d y guarda los cambios.

    #!/bin/sh
exit 101

  2. Agrega los permisos de ejecución en /usr/sbin/policy-rc.d:

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

  3. Ejecute los siguientes comandos:

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

"Error: 0x80040306" en la instalación

Esto se relaciona con el hecho de que no se admite la consola heredada. Para desactivar la consola heredada:

  1. Abre cmd.exe.
  2. Haga clic con el botón derecho en barra de título -> Propiedades -> y desactive Usar consola heredada.
  3. Haga clic en Aceptar

"Error: 0x80040154" después de una actualización de Windows

La característica Subsistema de Windows para Linux puede deshabilitarse durante una actualización de Windows. Si esto ocurre, debes volver a habilitar la característica de Windows. Las instrucciones para habilitar el Subsistema de Windows para Linux se pueden encontrar en la guía de instalación manual.

Cambiar el idioma de visualización

La instalación de WSL intentará cambiar automáticamente la configuración regional de Ubuntu para que coincida con la configuración regional de la instalación de Windows. Si no quieres que esto pase, puedes ejecutar este comando para cambiar la configuración regional de Ubuntu una vez finalizada la instalación. Ten en cuenta que tendrás que reiniciar bash.exe para que este cambio surta efecto.

En el ejemplo siguiente se cambia la configuración regional a en-US:

sudo update-locale LANG=en_US.UTF8

Problemas de instalación después de una restauración del sistema de Windows

  1. Elimina la carpeta %windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux.
    Nota: No lo hagas si tu característica opcional está completamente instalada y en funcionamiento.
  2. Habilitar la característica opcional WSL (si aún no lo está)
  3. Reiniciar
  4. lxrun /uninstall /full
  5. Instala bash.

Sin acceso a Internet en WSL

Algunos usuarios han informado de problemas con aplicaciones de firewall específicas que bloquean el acceso a Internet en WSL. Los firewalls que dan error son:

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

En algunos casos, si desactivas el firewall podrás acceder. En otros casos, simplemente tener instalado el firewall parece bloquear el acceso a Internet.

Si usa el Firewall de Microsoft Defender, la desactivación de "Bloquear todas las conexiones entrantes, incluidas las de la lista de aplicaciones permitidas" permite el acceso.

Error de permiso denegado al usar ping

En cuanto a la Actualización de aniversario de Windows (versión 1607), es necesario tener privilegios de administrador en Windows para ejecutar ping en WSL. Para ejecutar ping, ejecuta Bash en Ubuntu en Windows como administrador o ejecuta bash.exe desde un símbolo del sistema de CMD/PowerShell con privilegios de administrador.

Para versiones posteriores de Windows (compilación 14926+) ya no es necesario tener privilegios de administrador.

Bash se bloquea

Si mientras trabajas con Bash, ves que Bash se bloquea (o interbloquea) y no responde a las entradas, ayúdanos a diagnosticar el problema mediante la recopilación y la generación de informes de un volcado de memoria. Ten en cuenta que con estos pasos se bloqueará tu sistema. No lo hagas si no te sientes cómodo al hacerlo o guarda el trabajo antes de hacerlo.

Para recopilar un volcado de memoria

  1. Cambia el tipo de volcado de memoria a "volcado de memoria completa". Al cambiar el tipo de volcado, toma nota del tipo actual.

  2. Sigue los pasos para configurar el bloqueo mediante el control de teclado.

  3. Reproduce el bloqueo o interbloqueo.

  4. Bloquea el sistema con la secuencia de claves de (2).

  5. El sistema se bloqueará y recopilará el volcado de memoria.

  6. Una vez que se reinicie el sistema, informa memory.dmp a secure@microsoft.com. La ubicación predeterminada del archivo de volcado es %SystemRoot%\memory.dmp o C:\Windows\memory.dmp si C: es la unidad del sistema. En el correo electrónico, indica que el volcado de memoria es para el equipo de WSL o de Bash en Windows.

  7. Restaura el tipo de volcado de memoria a la configuración original.

Comprobar el número de compilación

Para encontrar la arquitectura de tu PC y el número de compilación de Windows, abre:
Configuración>Sistema>Acerca de

Busca los campos Compilación del SO y Tipo de sistema.
Captura de pantalla de los campos Compilación del SO y Tipo de sistema

Para encontrar el número de compilación de Windows Server, ejecuta lo siguiente en PowerShell:

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

Confirmar que WSL está habilitado

Para confirmar que el Subsistema de Windows para Linux está habilitado, puede ejecutar lo siguiente en una ventana PowerShell con privilegios elevados:

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

Problemas de conexión del servidor de OpenSSH

Al intentar conectarte al servidor SSH se produce el error siguiente: "Connection closed by 127.0.0.1 port 22" (Conexión cerrada por 127.0.0.1 puerto 22).

  1. Asegúrate de que el servidor OpenSSH esté en ejecución:

    sudo service ssh status

    y que has seguido este tutorial: https://ubuntu.com/server/docs/service-openssh

  2. Detén el servicio sshd e inicia sshd en modo de depuración:

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

  3. Comprueba los registros de inicio y asegúrate de que HostKeys estén disponibles y de no ver mensajes de registro 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

Si ves estos mensajes y faltan las claves en /etc/ssh/, tendrás que volver a generar las claves o simplemente purgar e instalar el servidor OpenSSH:

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

"No se encontró el ensamblado al que se hace referencia." al habilitar la característica opcional WSL.

Este error está relacionado con un estado de instalación incorrecta. Complete los pasos siguientes para intentar corregir este problema:

  • Si estás ejecutando el comando para habilitar la característica WSL desde PowerShell, intenta usar la GUI en su lugar desde el menú Inicio: busca "activar o desactivar las características de Windows" y, a continuación, en la lista, selecciona "Subsistema de Windows para Linux", lo que instalará el componente opcional.

  • Actualiza la versión de Windows. Para ello, ve a Configuración, Actualizaciones y haz clic en "Buscar actualizaciones".

  • Si se produce un error en ambos casos y necesita acceder a WSL, considere la posibilidad de realizar una actualización local. Para ello, vuelva a instalar Windows 10 mediante el uso de medios de instalación y seleccione "Conservar todo" para asegurarse de que las aplicaciones y los archivos se van a conservar. Puedes encontrar instrucciones sobre cómo hacerlo en la página Reinstalar Windows 10.

Si ves este error:

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

Para corregirlo, anexa lo siguiente al archivo /etc/wsl.conf:

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

Ten en cuenta que, al agregar este comando, se incluirán metadatos y se modificarán los permisos de archivo en los archivos de Windows que se muestran en WSL. Para obtener más información, consulta los Permisos del sistema de archivos.

No se puede usar WSL de forma remota mediante OpenSSH en Windows

Si está utilizando openssh-server en Windows e intenta acceder a WSL de forma remota, es posible que vea este error:

The file cannot be accessed by the system.

Se trata de un problema conocido cuando se usa la versión de Store de WSL. Puede solucionarlo hoy con el uso de WSL1 o la versión de WSL integrada de Windows. Consulte https://aka.ms/wslstoreinfo para obtener más información.

La ejecución de comandos de Windows devuelve un error dentro de una distribución

Algunas distribuciones disponibles en Microsoft Store aún no son totalmente compatibles con la ejecución de comandos de Windows de forma predefinida. Si recibe un error -bash: powershell.exe: command not found al ejecutar powershell.exe /c start . o cualquier otro comando de Windows, siga estos pasos para resolverlo:

  1. En la distribución de WSL, ejecute echo $PATH.
    Si no incluye /mnt/c/Windows/system32, hay algo que redefine la variable PATH estándar.
  2. Consulte la configuración del perfil con cat /etc/profile.
    Si contiene la asignación de la variable PATH, edite el archivo para comentar el bloque de asignación de PATH con un carácter # .
  3. Compruebe si wsl.conf está presente cat /etc/wsl.conf y asegúrese de que no contenga appendWindowsPath=false. En caso contrario, coméntelo.
  4. Para reiniciar la distribución, escriba wsl -t seguido del nombre de la distribución o ejecute wsl --shutdown en CMD o PowerShell.

No se puede realizar el arranque después de instalar WSL 2

Somos conscientes de un problema que afecta a los usuarios en el que no pueden realizar el arranque después de instalar WSL 2. Mientras realizamos el diagnóstico completo del problema, los usuarios han comunicado que este puede solucionarse si se cambia el tamaño del búfer o se instalan los controladores adecuados. Consulte este problema de GitHub para ver sus actualizaciones más recientes.

Errores de WSL 2 cuando el componente ICS está deshabilitado

La conexión compartida a Internet (ICS) es un componente necesario de WSL 2. El servicio de red de host (HNS) usa el servicio ICS para crear la red virtual subyacente en la que se basa WSL 2 para la conexión compartida de host, NAT, DNS y DHCP.

Deshabilitar el servicio ICS (SharedAccess) o bien ICS mediante la directiva de grupo impedirá que se cree la red HNS de WSL. Esto producirá errores al crear una nueva imagen de la versión 2 de WSL y el siguiente error al intentar convertir una imagen de la versión 1 a la versión 2.

There are no more endpoints available from the endpoint mapper.

Los sistemas que requieren WSL 2 deben dejar el servicio ICS (SharedAccess) en el estado de inicio predeterminado, Manual (desencadenar inicio), y cualquier directiva que deshabilite ICS debe sobrescribirse o quitarse. Aunque deshabilitar el servicio ICS interrumpirá WSL 2 y no es una acción recomendada, se pueden deshabilitar secciones de ICS siguiendo estas instrucciones.

Uso de versiones anteriores de Windows y WSL

Hay varias diferencias a tener en cuenta si ejecuta una versión anterior de Windows y WSL, como Windows 10 Creators Update (octubre de 2017, compilación 16299) o Actualización de aniversario (agosto de 2016, compilación 14393). Se recomienda actualizar a la versión Windows más reciente. Por si no es posible, se describen algunas de las diferencias a continuación.

Diferencias entre los comandos de interoperabilidad:

  • bash.exe se ha reemplazado por wsl.exe. Los comandos de Linux se pueden ejecutar desde el símbolo del sistema de Windows o desde PowerShell, pero para las primeras versiones de Windows, puede que tengas que usar el comando bash. Por ejemplo: C:\temp> bash -c "ls -la". Los comandos de WSL pasados a bash -c se reenvían al proceso de WSL sin modificaciones. Las rutas de acceso de archivo deben especificarse en el formato de WSL y se debe tener cuidado al escapar caracteres relevantes. Por ejemplo, C:\temp> bash -c "ls -la /proc/cpuinfo" o C:\temp> bash -c "ls -la \"/mnt/c/Program Files\"".
  • Para ver qué comandos están disponibles para una distribución determinada, ejecuta [distro.exe] /?. Por ejemplo, con Ubuntu: C:\> ubuntu.exe /?.
  • La ruta de acceso de Windows se incluye en $PATH de WSL.
  • Al llamar a una herramienta de Windows desde una distribución de WSL en una versión anterior de Windows 10, deberás especificar la ruta de acceso del directorio. Por ejemplo, para llamar a la aplicación Bloc de notas de Windows desde la línea de comandos de WSL, escriba: /mnt/c/Windows/System32/notepad.exe.
  • Para cambiar el usuario predeterminado a root, use este comando en PowerShell C:\> lxrun /setdefaultuser root y, a continuación, ejecute Bash.exe para iniciar sesión en C:\> bash.exe. Restablezca la contraseña con el comando de contraseña de la distribución ($ passwd username) y, a continuación, cierre la línea de comandos de Linux: $ exit. Desde el símbolo del sistema de Windows o PowerShell, restablezca el usuario predeterminado a su cuenta de usuario de Linux normal: C:\> lxrun.exe /setdefaultuser username.

Desinstalación de la versión heredada de WSL

Si originalmente instaló WSL en una versión de Windows 10 anterior a Creators Update (octubre de 2017, compilación 16299), se recomienda migrar los archivos, los datos, etc. necesarios de la distribución de Linux anterior que instaló a una distribución más reciente instalada a través de Microsoft Store. Para quitar la distribución heredada de la máquina, ejecute lo siguiente desde una línea de comandos o una instancia de PowerShell: wsl --unregister Legacy. También tiene la opción de quitar manualmente la distribución heredada anterior mediante la eliminación de la carpeta %localappdata%\lxss\ (y todo su contenido) mediante el Explorador de archivos de Windows o PowerShell: rm -Recurse $env:localappdata/lxss/.