Compartir vía

Solución de problemas del subsistema de Windows para Linux

  • Artículo

Hemos tratado algunos escenarios comunes de solución de problemas asociados a WSL a continuación, pero considere la posibilidad de buscar los problemas presentados en el repositorio de productos de WSL en GitHub también.

Presentar un problema, informe de errores, solicitud de funciones

Los problemas del repositorio de productos de WSL le permiten:

  • Buscar problemas existentes para ver si alguno está asociado con el problema que tenga. Tenga en cuenta que en la barra de búsqueda, puede quitar "is:open" para incluir problemas que ya se han resuelto en su búsqueda. Considere la posibilidad de comentar o dar un me gusta a cualquier cuestión abierta en la que le gustaría expresar su interés para avanzar como prioridad.
  • Presentar una nueva incidencia. Si ha encontrado un problema con WSL y no parece que haya un problema existente, puede seleccionar el botón verde Nuevo problema y, a continuación, elegir WSL - Informe de errores. Tendrá que incluir un título para el problema, el número de compilación de Windows (ejecutar cmd.exe /c ver para ver la compilación actual #), tanto si está ejecutando WSL 1 como 2, la versión actual del kernel de Linux (ejecute wsl.exe --status o cat /proc/version), la 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 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 abordar algunas preguntas que describen la solicitud.

También puede:

  • Presentar un problema de documentación mediante el repositorio de documentos de WSL. Para contribuir a los documentos de WSL, consulte la guía de colaborador de Microsoft Docs .
  • Presentar un problema de Terminal Windows mediante el repositorio de productos de Terminal Windows si el problema está más relacionado con Terminal Windows, la consola de Windows o la interfaz de usuario de la línea de comandos.

Problemas de instalación

  • Error de instalación 0x80070003

    • El Subsistema de Windows para Linux solo se ejecuta en la unidad del sistema (normalmente se trata de la unidad C:). Asegúrese de que las distribuciones se almacenan en la unidad del sistema:
    • En Windows 10, abra Configuración ->Sistema ->Almacenamiento ->Más Configuración de Almacenamiento: Cambiar dónde se guarda nuevo contenidoFoto de la configuración del sistema para instalar aplicaciones en la unidad C: (Windows 10)
    • En Windows 11, abra Configuración ->System ->Storage ->Configuración avanzada de almacenamiento ->Donde se guarda nuevo contenidoImagen de la configuración del sistema para instalar aplicaciones en la unidad C: unidad (Windows 11)

  • WslRegisterDistribution falló con el error 0x8007019e

    • El componente opcional 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úrese 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 probablemente se encontrarán en opciones relacionadas con la CPU.
    • WSL2 requiere que la CPU admita la característica traducción de direcciones de segundo nivel (SLAT), que se introdujo en procesadores Intel Nehalem (Intel Core 1st Generation) 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 tiene habilitado el Subsistema de Windows para Linux y que usa la versión 18362 o posterior de la compilación de Windows. 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.

  • No se pudo completar la operación solicitada 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 estar dispersos.

    • Anule la selección de "Comprimir contenido" (así como "Cifrar contenido" si está activada) abriendo la carpeta de perfil para la distribución de Linux. Debe encontrarse en una carpeta del sistema de archivos de Windows, algo parecido a: %USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...
    • En este perfil de distribución de Linux, debe haber una carpeta LocalState. Haga clic con el botón derecho en esta carpeta para mostrar un menú de opciones. Seleccione Propiedades > Avanzadas y asegúrese de que las casillas "Comprimir contenido para ahorrar espacio en disco" y "Cifrar contenido para proteger los datos" no están seleccionados (no activados). Si se le pregunta si desea aplicar esto solo a la carpeta actual o a todas las subcarpetas y archivos, seleccione "solo esta carpeta" porque solo va a borrar la marca de compresión. Después de esto, el comando wsl --set-version debe funcionar.

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

Nota

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

Consulte el hilo de GitHub de WSL Docs #4103 donde se está siguiendo este problema para obtener información actualizada.

  • El término "wsl" no se reconoce como el nombre de un cmdlet, una función, un archivo de script o un programa operable.

  • Error: Subsistema de Windows para Linux no tiene distribuciones instaladas.

    • Si recibe este error después de que ya haya instalado 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 debe dar lugar a este error, pero debe asegurarse de que no está ejecutando 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 de administrador integrada.
    3. El ejecutable WSL solo se instala en el directorio del sistema nativo. Cuando se ejecuta un proceso de 32 bits en Windows de 64 bits (o en ARM64, cualquier combinación no nativa), el proceso hospedado no nativo ve realmente 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, téngalo en cuenta, pero el resolutor de rutas del sistema de archivos lo 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, se requiere WSL 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 razones posibles para ver este mensaje:

    1. Todavía está en la versión anterior de Windows que no admite WSL 2. Consulte el paso 2 para conocer los requisitos de versión y los vínculos a 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, se requiere un reinicio para que surta efecto, reinicie la máquina e inténtelo de nuevo.

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

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

Problemas comunes

Estoy en Windows 10 versión 1903 y todavía no veo opciones para WSL 2

Probablemente, se debe a que la máquina aún no ha adquirido la adaptación para WSL 2. La manera más sencilla de resolver esto es ir 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 presiona "Buscar actualizaciones" y sigue sin recibir la actualización, puede instalar KB KB4566116 manualmente.

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

Esto puede ocurrir cuando la configuración "Idioma para mostrar" 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 la incidencia 5749

No se puede acceder a los archivos WSL desde Windows

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

Para comprobarlo, puede comprobar los registros de inicio mediante: dmesg |grep 9p, y esto le mostrará los errores. Una salida correcta es similar 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 de WSL 2 y solo ver "WSL 2" en la salida

Si el idioma para mostrar no es 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 Windows .exe 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, ejecute echo $PATH en Linux. Se espera que aparezca una ruta de acceso Win32 (por ejemplo, /mnt/c/Windows) en la salida. Si no puede ver ninguna ruta de Windows, lo más probable es que su shell de Linux esté sobrescribiendo su PATH.

Este es un ejemplo de que /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 en Debian es 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

Para obtener más información, vea problema 5296 y problema 5779.

"Error: 0x80370102 No se pudo iniciar la máquina virtual porque no se instaló una característica necesaria".

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

  1. Compruebe los requisitos del sistema ,Hyper-V y

  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 están habilitadas en la CPU. Las instrucciones para este proceso pueden variar de una máquina a otra, consulte este artículo de Bleeping Computer para obtener un ejemplo.

  4. Reinicie la máquina 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. Para validarlo, ejecute (PowerShell con privilegios elevados):

     bcdedit /enum | findstr -i hypervisorlaunchtype

    Si ve hypervisorlaunchtype Off, el hipervisor está deshabilitado. Para habilitarla, ejecute en un powershell con privilegios elevados:

     bcdedit /set hypervisorlaunchtype Auto

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

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

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

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:

La configuración del Firewall de Windows captura de pantalla

  1. Abra "Firewall de Windows Defender con seguridad avanzada" (esto es diferente de "Firewall de Windows Defender" en el Panel de control)
  2. Haga clic con el botón derecho en la pestaña "Firewall de Windows Defender con seguridad avanzada en el equipo local".
  3. Seleccione "Propiedades"
  4. Seleccione la pestaña "Perfil público" en la nueva ventana que se abre.
  5. Seleccione "Personalizar" en la sección "Configuración".
  6. Compruebe en la ventana "Personalizar la configuración del perfil público" que se abre para ver si "Combinación de reglas" está establecida en "No". Esto bloqueará el acceso a WSL.

Puede encontrar instrucciones sobre cómo cambiar esta configuración del firewall en configurar el firewall Hyper-V.

WSL no tiene conectividad de red una vez conectada a una VPN

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

  1. Toma nota del servidor DNS de la VPN con ipconfig.exe /all
  2. Hacer una copia del resolv.conf sudo cp /etc/resolv.conf /etc/resolv.conf.new existente
  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. Agregue la entrada DNS de (1) anterior como la primera entrada de la lista de servidores DNS.
    c. Cierre el archivo.

Una vez que haya desconectado la VPN, tendrá que revertir los cambios a /etc/resolv.conf. Para ello, haga 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 VPN de Cisco Anyconnect con WSL en modo NAT

La VPN de Cisco AnyConnect modifica las rutas de una manera 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.

Algunas VPN se han probado y confirmado que son incompatibles con WSL, entre las que se incluyen:

  • "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:

  • PAC Proxy: WSL configurará el ajuste 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 configura con uno o más 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.

Hay un problema conocido causado por las configuraciones de ZScaler, donde ZScaler habilita y deshabilita repetidamente las configuraciones de proxy de Windows, lo que provoca que WSL muestre repetidamente la notificación "Se ha detectado un cambio de proxy Http en el host".

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 esto utilizando una característica de virtualización para comunicarse directamente con Windows, permitiendo resolver el nombre DNS sin enviar un paquete de red. Esta característica debe mejorar la compatibilidad de red y permitirle obtener una mejor conectividad a Internet incluso si tiene una VPN, una configuración de firewall específica u otras configuraciones de red.

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

  • Si usa una VPN con WSL, active la tunelización DNS. Muchas VPN usan directivas NRPT, que solo se aplican a las consultas 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 DNS de WSL. Si los usuarios quieren habilitar DoH, DoT dentro de Linux, deben deshabilitar la tunelización DNS.
  • Las consultas DNS de contenedores de Docker administrados por Docker Desktop omitirán la tunelización DNS. Docker Desktop tiene su propia manera (diferente de la tunelización de DNS) de aplicar la configuración y las directivas dns del host a las consultas DNS desde contenedores de Docker.
  • Para que la tunelización DNS esté habilitada correctamente, la opción generateResolvConf en el archivo wsl.conf no debe deshabilitarse.
  • Cuando la tunelización DNS está habilitada, se omite la opción generateHosts en el archivo wsl.conf (el archivo de hosts DNS de Windows no se copia en el archivo /etc/hosts de Linux). Las directivas del archivo de hosts de Windows se aplicarán a las consultas DNS desde Linux, sin necesidad de copiar el archivo en Linux.

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

Al usar el modo de red reflejado (el networkingMode experimental establecido en mirrored), algún tráfico entrante recibido por el host de Windows nunca se dirigirá 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 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 configuración Value
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)
deshabilitar_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 de 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 Network Manager en ejecución. Los síntomas incluyen fallos al intentar establecer conexiones de retorno al host. Se recomienda detener el servicio Network Manager para que las redes WSL se configuren correctamente.

sudo systemctl disable network-manager.service

Resolución de nombres .locales en WSL

Para resolver nombres de host en direcciones IP dentro de una red local sin necesidad de un servidor DNS convencional, a menudo se usan nombres .local. Esto se logra a través del protocolo mDNS (DNS de multidifusión), que se basa en el tráfico de multidifusión para funcionar.

networkingMode establecido en NAT:

Actualmente, esta característica no se admite cuando está habilitada la tunelización DNS. Para habilitar la resolución de nombres .local, se recomiendan las siguientes soluciones:

  • Deshabilite la tunelización DNS.
  • Utilice el modo de red en espejo.

networkingMode establecido en Reflejado:

Nota: Debe estar en WSL build 2.3.17 o posterior para tener la funcionalidad siguiente.

Dado que el Modo reflejado admite el tráfico de multidifusión, el protocolo mDNS (DNS de multidifusión) se puede usar para resolver nombres .local. Linux debe configurarse para admitir mDNS, ya que no lo hace de forma predeterminada. Una manera de configurarla es usar los dos pasos siguientes:

  1. Instale el paquete "libnss-mdns"
sudo apt-get install libnss-mdns

*El paquete "libnss-mdns" es un complemento para la funcionalidad del conmutador de servicio de nombres GNU (NSS) de la biblioteca GNU C (glibc) que proporciona resolución de nombres de host a través de DNS de multidifusión (mDNS). Este paquete permite eficazmente que los programas de Unix/Linux comunes resuelvan nombres en el dominio ad-hoc mDNS .local.

  1. Configure el archivo /etc/nsswitch.conf para habilitar la opción "mdns_minimal" en la sección "hosts". Contenido de ejemplo del archivo:
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

Sufijos DNS en WSL

Según las configuraciones del archivo .wslconfig, WSL tendrá el siguiente comportamiento con respecto a los sufijos DNS:

Cuando el modo de red 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 HSS 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 implementar una política que no permita reglas de firewall definidas localmente, permitiendo solo reglas definidas por la política empresarial.

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, la empresa debe crear una regla de cortafuegos para permitir el puerto UDP 53 al servicio de acceso compartido, o se puede configurar WSL para usar tunelización de 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 Allow-Inbound. 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 túnelizació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 (consulte 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 el consentimiento del usuario para la misma configuración que puede ser aplicada por una empresa mencionada en el #2 anterior. Los usuarios pueden abrir la página de configuración "Seguridad de Windows", selecciona la opción "Firewall & protección de red", selecciona el perfil de firewall que quieren configurar (dominio, privado o público) y, en "Conexiones entrantes", comprueba el control "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.

Para que la configuración del proxy DNS NAT funcione desde WSL, debe desmarcarse esta opción. WSL o se pueden configurar para usar la tunelización DNS.

4. La regla de firewall de HNS para permitir que los paquetes DNS tengan acceso compartido pueden ser no 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 debe funcionar en la mayoría de los casos:

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

  • Quite 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. Verifique si el controlador FSE está en funcionamiento: "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

Adaptadores fantasma, o dispositivos fantasma Plug and Play (PnP), se refieren a componentes de hardware que aparecen en el sistema pero que 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. Abrir el Administrador de dispositivos
  2. Ver > Mostrar dispositivos ocultos

Captura de pantalla del Administrador de dispositivos que muestra el menú de dispositivos ocultos

  1. Abrir adaptadores de red

Captura de pantalla de la lista de 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 la 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 desea actualizar.

Errores de actualización de Apt-get

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

Para corregir problemas relacionados con udev, siga estos pasos:

  1. Escriba lo siguiente en /usr/sbin/policy-rc.d y guarde los cambios.

    #!/bin/sh
exit 101

  2. Agregue permisos de ejecución a /usr/sbin/policy-rc.d:

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

  3. Ejecute los comandos siguientes:

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

"Error: 0x80040306" en la instalación

Esto está relacionado con el hecho de que no ofrecemos soporte para 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 la actualización de Windows

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

Cambiar el idioma de presentació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 desea este comportamiento, puede ejecutar este comando para cambiar la configuración regional de Ubuntu una vez completada la instalación. Tendrá que volver a iniciar 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 la restauración del sistema de Windows

  1. Elimine la carpeta %windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux.
    Nota: No haga esto si la característica opcional está totalmente instalada y funcionando.
  2. Habilitación de la característica opcional WSL (si aún no es así)
  3. Reiniciar
  4. lxrun /uninstall /full
  5. Instalación de Bash

Sin acceso a Internet en WSL

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

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

En algunos casos, desactivar el firewall permite el acceso. En algunos casos, simplemente tener instalado el firewall busca bloquear el acceso.

Si usa firewall de Microsoft Defender, desactive "Bloquea 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, de compilación 14926+, ya no se necesitan privilegios de administrador.

Bash está colgado

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. Tenga en cuenta que estos pasos harán que se bloquee su sistema. No hagas esto si no te sientes cómodo con eso y guarda tu 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. Haga colapsar el sistema usando la secuencia de teclas de (2).

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

  6. Una vez reiniciado el sistema, notifique el memory.dmp para secure@microsoft.com. La ubicación predeterminada del archivo de volcado de memoria 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 buscar la arquitectura del equipo y el número de compilación de Windows, abra
Configuración>Sistema>Acerca de

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

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

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

Confirmación de que WSL está habilitado

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

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

Problemas de conexión del servidor de OpenSSH

Error al intentar conectar el servidor SSH con el siguiente error: "Conexión cerrada por 127.0.0.1 puerto 22".

  1. Asegúrese de que el servidor OpenSSH se está ejecutando:

    sudo service ssh status

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

  2. Detenga el servicio sshd e inicie sshd en modo de depuración:

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

  3. Compruebe los registros de inicio y asegúrese de que HostKeys están disponibles y no ve 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 estar en un estado de instalación incorrecto. Complete los pasos siguientes para intentar solucionar este problema:

  • Si ejecuta el comando habilitar la característica WSL desde PowerShell, intente usar la GUI en su lugar abriendo el menú inicio, buscando "Activar o desactivar las características de Windows" y, a continuación, en la lista, seleccione "Subsistema de Windows para Linux", que instalará el componente opcional.

  • Actualice la versión de Windows; para ello, vaya a Configuración, Actualizaciones y haga clic en "Buscar actualizaciones".

  • Si se produce un error en ambos y necesita acceder a WSL, considere la posibilidad de actualizar en su lugar mediante la reinstalación de Windows mediante medios de instalación y la selección de "Mantener todo" para asegurarse de que se conservan las aplicaciones y los archivos. 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, anexe lo siguiente al archivo /etc/wsl.conf:

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

Tenga en cuenta que agregar este comando incluirá metadatos y modificará los permisos de archivo en los archivos de Windows vistos desde WSL. Consulte los permisos del sistema de archivos para obtener más información.

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

Si usa openssh-server en Windows e intenta acceder a WSL de forma remota, muchos ven 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 mediante WSL 1 o mediante la versión en Windows de WSL. Consulta https://aka.ms/wslstoreinfo para obtener más información.

Se produce un error en la ejecución de comandos de Windows dentro de una distribución

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

  1. En su distribución de WSL, ejecute echo $PATH.
    Si no incluye: /mnt/c/Windows/system32 algo está redefiniendo la variable PATH estándar.
  2. Compruebe 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. Reinicie la distribución escribiendo wsl -t seguido de nombre de distribución o ejecute wsl --shutdown en cmd o PowerShell.

No se puede arrancar después de instalar WSL 2

Somos conscientes de un problema que afecta a los usuarios en los que no pueden arrancar 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 esta incidencia de GitHub para ver las actualizaciones más recientes sobre este tema.

Errores de WSL 2 cuando ICS está deshabilitado

El uso compartido de conexiones a Internet (ICS) es un componente necesario de WSL 2. El servicio ICS lo usa el servicio de red host (HNS) para crear la red virtual subyacente en la que se basa WSL 2 para el uso compartido de conexiones NAT, DNS, DHCP y host.

Deshabilitar el servicio ICS (SharedAccess) o deshabilitar ICS a través de la directiva de grupo impedirá que se cree la red de HNS de WSL. Esto provocará errores al crear una nueva imagen de WSL versión 2 y el siguiente error al intentar convertir una imagen de 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 su estado de inicio predeterminado, Manual (activado por condición), y cualquier directiva que deshabilite ICS debe sobrescribirse o eliminarse. Al deshabilitar el servicio ICS se interrumpirá WSL 2. No se recomienda deshabilitar ICS, pero las partes de ICS se pueden deshabilitar mediante estas instrucciones.

Uso de versiones anteriores de Windows y WSL

Hay varias diferencias que hay que 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 de 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 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, ejecute [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á especificar la ruta de acceso del directorio. Por ejemplo, para llamar a la aplicación del 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: C:\> bash.exe. Restablezca la contraseña mediante el comando de contraseña de distribuciones: $ passwd username y 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.

Desinstalar la versión heredada de WSL

Si originalmente instaló WSL en una versión de Windows 10 antes de Creators Update (octubre de 2017, compilación 16299), se recomienda migrar los archivos, datos, etc. necesarios desde la distribución anterior de Linux instalada, 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 instancia de Línea de comandos o PowerShell: wsl --unregister Legacy. También tiene la opción de quitar manualmente la antigua distribución heredada eliminando la carpeta %localappdata%\lxss\ (y todos sus subcontenidos) usando el Explorador de archivos de Windows o con PowerShell: rm -Recurse $env:localappdata/lxss/.