¿WSL2 no puede acceder a archivos de Windows? Montajes y permisos que importan

El modelo mental: qué hace realmente WSL2

WSL2 no es “Linux ejecutándose en Windows” en el sentido cálido y difuso que mucha gente implica. Es un kernel Linux real ejecutándose en una VM ligera (basada en Hyper-V), con Windows proveyendo tuberías de integración. Esas tuberías son contra las que peleas cuando los archivos de Windows “desaparecen” o los permisos parecen encantados.

Dentro de WSL2 normalmente tienes dos clases de almacenamiento:

• El sistema de archivos de Linux (ext4 dentro de un VHDX) para tu distro, que vive bajo /. Es rápido y se comporta como espera Linux.
• Archivos de Windows expuestos a Linux a través de montajes DrvFS, usualmente bajo /mnt/c, /mnt/d, etc. Es una capa de compatibilidad que mapea la semántica de NTFS a algo que Linux puede usar.

Ese mapeo es la fuente de la mayoría de las confusiones. Los permisos en Linux son bits de modo + propiedad. Los permisos en Windows son ACLs, reglas heredadas, entradas de denegación y “depende” integrado en el OS. DrvFS intenta representar objetos de Windows como archivos de Linux. A veces lo logra. A veces miente con cortesía.

Operativamente, deberías elegir tu campo de batalla:

• Si compilas, indexas o haces muchas operaciones con archivos pequeños: coloca el repositorio en el sistema de archivos de Linux (~/src) y accede desde Windows vía \\wsl$.
• Si debes conservar archivos en NTFS: trata /mnt/c como un sistema de archivos de red con peculiaridades. Ajusta las opciones de montaje. Evita depender de chmod/chown a menos que actives metadata.

Una cita para mantener tu cerebro SRE alerta: La esperanza no es una estrategia. — General Gordon R. Sullivan. En sistemas de archivos, “esperar que monte como la vez pasada” es como terminar depurando a las 2 a.m.

Broma corta #1: DrvFS es como un traductor en un bar ruidoso—mayormente preciso, ocasionalmente inventando significado, siempre convencido de que ayuda.

Datos e historia interesantes (porque los detalles importan)

• WSL1 y WSL2 son bestias diferentes. WSL1 traducía llamadas del sistema de Linux a internals de Windows NT; WSL2 ejecuta un kernel Linux real en una VM.
• DrvFS es anterior a WSL2. El concepto de montar unidades de Windows existía en WSL1, pero la implementación subyacente y las características de rendimiento cambiaron con la frontera de la VM.
• La sensibilidad a mayúsculas no es universal en Windows. NTFS puede preservar mayúsculas y opcionalmente ser sensible por directorio; históricamente, las APIs Win32 trataban rutas como insensibles por defecto.
• Los permisos de NTFS son basados en ACL. Los bits de modo de Linux son una simplificación que no representan reglas de denegación, herencia o múltiples sujetos de forma clara.
• El almacenamiento de WSL2 vive en un VHDX. El sistema raíz de tu distro está dentro de un archivo de disco virtual; moverlo entre máquinas o respaldarlo es posible pero requiere cuidado.
• El indexado de archivos y el antivirus de Windows importan. Tocar muchos archivos en NTFS desde WSL2 puede activar escaneo del lado de Windows, lo cual parece “Linux lento” mientras Windows hace el trabajo.
• Ideas de 9P y Plan 9 aparecen en el ecosistema. Algunos mecanismos de compartición de archivos cruzados se basan en conceptos similares a protocolos de sistemas de archivos remotos; las operaciones entre fronteras no son gratuitas.
• El mapeo de permisos es configurable. Opciones de montaje de DrvFS como metadata, uid, gid, umask y fmask cambian lo que Linux cree ver.

Guía de diagnóstico rápido: encuentra el cuello de botella en minutos

Cuando aparece “WSL2 no puede acceder a archivos de Windows”, tu trabajo es separar: problema de montaje, problema de permisos, problema de ruta/interop o problemas de rendimiento/tiempos de espera. Aquí está la ruta más rápida que he encontrado y que no degenera en superstición.

Primero: ¿la unidad está montada como crees?

• Revisa mount y busca type drvfs en /mnt/c (o tu raíz de montaje configurada).
• Si el montaje falta o es incorrecto, arregla el automontaje o /etc/fstab antes de tocar permisos.

Segundo: ¿la falla es por permisos de Linux o ACLs de Windows?

• Prueba crear/escribir como tu usuario Linux en una carpeta conocida en C: (como el perfil de usuario de Windows).
• Si puedes leer pero no escribir, casi siempre es una ACL de NTFS o una herramienta de políticas corporativas (EDR, controlled folder access), no “chmod”.

Tercero: ¿es una falla de rendimiento disfrazada de “no se puede acceder”?

• Si las herramientas agotan el tiempo, cuelgan o se comportan de forma inestable en /mnt/c, reproduce la misma operación en ~ (ext4 de Linux). Si es rápida allí, estás viendo la sobrecarga de la frontera con Windows.
• Cuando dudes: mueve la carga al sistema de archivos de Linux y exponla a Windows vía \\wsl$.

Cuarto: revisa las “trampas” entre plataformas

• Conflictos de sensibilidad a mayúsculas, caracteres de nombre inválidos, comportamiento de symlinks y herramientas de endings pueden hacer que el “acceso” parezca roto.
• Confirma que no estés escribiendo archivos con nombres que Windows no pueda representar y luego esperando que se comporten bajo NTFS.

Montajes que importan: DrvFS, VolFs y dónde viven realmente tus datos

La mayoría aprende un camino: /mnt/c. Luego asumen que es “solo una carpeta”. No lo es. Es un sistema de archivos montado de tipo drvfs, y sus opciones de montaje deciden todo, desde los permisos visibles hasta si chmod hace algo.

Puntos de montaje DrvFS: /mnt/c es una decisión de política

Por defecto, WSL auto-monta unidades fijas bajo /mnt/<letra_de_unidad>. Ese comportamiento puede cambiarse en /etc/wsl.conf. Ese cambio también puede romper scripts, pasos de CI o la memoria muscular del desarrollador—trátalo como un cambio de API.

Sistema de archivos Linux dentro de WSL2: tu zona real de rendimiento

Dentro de la VM de WSL2, el sistema de archivos raíz de tu distro es ext4 (típicamente) y se comporta como una máquina Linux normal. Si tu carga es “Linuxera” (node_modules que cambian, compilaciones de Rust, entornos virtuales Python, operaciones git), mantenerla en ext4 es la diferencia entre “funciona” y “mi portátil es una estufa”.

Dónde fallan los montajes

Modos comunes de fallo de montaje que he visto en flotas de desarrolladores:

• Automount deshabilitado: no hay /mnt/c, o solo algunas unidades aparecen.
• Cambio de letra de unidad: medios extraíbles, estados de desbloqueo de BitLocker o políticas corporativas de gestión de discos cambian letras.
• Errores en fstab: una entrada malformada puede impedir montajes esperados y dejarte depurando “permisos” cuando el sistema de archivos ni siquiera está allí.
• Rutas de red: mapear unidades de red de Windows no es lo mismo que NTFS local. Puede que necesites un enfoque distinto (y expectativas distintas).

Opciones de montaje que realmente cambian el comportamiento

Las opciones de montaje son donde decides si los permisos de Linux son “reales” (metadata) o “proyectados” (basados en máscara). Aquí está la verdad operacional:

• Sin metadata: chmod/chown en su mayoría no persistirá porque no hay dónde almacenar la propiedad POSIX en archivos NTFS presentados por DrvFS.
• Con metadata: WSL almacena metadata extra (piensa en “atributos extendidos”) para preservar bits de modo y mapeos de propiedad de Linux. Esto hace más felices a las herramientas Linux, pero puede sorprender a herramientas de Windows y a otras máquinas.
• uid/gid/umask/fmask/dmask: útiles cuando quieres propiedad y modos consistentes para todo en ese montaje, especialmente sin metadata.

No hay un conjunto de opciones “correcto” universal. Solo hay “correcto para lo que ejecutas” y “correcto para lo que tu equipo espera”. Elige uno y estandarízalo.

Permisos que importan: ACLs de NTFS vs bits de modo de Linux

Cuando Linux dice “permission denied”, te está diciendo que la syscall falló. Eso no significa que los bits de modo de Linux estén mal. Podría ser:

• Una ACL de Windows deniega la acción (explícitamente o por política heredada).
• El “controlled folder access” de Windows bloquea escrituras a directorios protegidos.
• Hooks de EDR/antivirus bloquean o retrasan el acceso hasta agotar el tiempo.
• El archivo está bloqueado por un proceso de Windows con modos de compartición que no coinciden con lo que Linux espera.

Entiende el mapeo: ¿quién es el propietario?

Por defecto, DrvFS a menudo presenta archivos de Windows como propiedad de tu usuario Linux (o a veces con valores por defecto tipo root dependiendo de la configuración) con bits de modo que parecen permisivos. Esos bits no son la autoridad; las ACLs de NTFS lo son.

Si activas metadata, la propiedad y los bits de modo de Linux pueden volverse más significativos dentro de WSL. Pero las aplicaciones de Windows aún aplican las ACLs de NTFS y pueden ignorar o sobrescribir la metadata tipo POSIX.

Lo que realmente significa “chmod no funciona”

En DrvFS sin metadata, chmod es como gritarle a una pintura: te sientes productivo, nada cambia. La solución correcta es o:

• Activar metadata para que chmod tenga dónde persistir.
• Dejar de depender de chmod/chown y gestionar el acceso vía ACLs de Windows (Explorador, icacls, políticas de grupo).
• Mover la carga al sistema de archivos de Linux donde los permisos POSIX son nativos.

Symlinks: la trampa silenciosa de permisos

Los symlinks de Linux hacia rutas de Windows y viceversa pueden fallar de maneras que parecen permisos. La creación de symlinks en Windows puede requerir el Modo Desarrollador o privilegios de administrador según la política. Además: un symlink que resuelve a una ruta de Windows hereda el comportamiento de ACLs de Windows. Tu proceso Linux no obtiene una exención mágica.

Broma corta #2: He visto “arreglar permisos” tantas veces que merece una tarjeta de fidelidad—compra nueve chmods, obtén el décimo gratis, y sigue roto.

Tareas prácticas: comandos, salidas y qué decidir después

Estas son tareas reales que ejecutaría en un portátil de flota o en una estación de trabajo de desarrollo mientras alguien dice “WSL2 no puede acceder a archivos”. Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas.

Tarea 1: Confirma que estás en WSL2 (no en WSL1)

cr0x@server:~$ uname -r
5.15.133.1-microsoft-standard-WSL2

Qué significa: Una cadena de kernel que contiene microsoft y WSL2 indica que estás ejecutando el kernel de WSL2.

Decisión: Si es WSL1, la semántica de acceso a archivos y el rendimiento difieren; ajusta expectativas y considera actualizar la distro a WSL2.

Tarea 2: Ve qué está montado y si C: es DrvFS

cr0x@server:~$ mount | grep -E ' /mnt/c |drvfs'
C:\ on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,case=off)

Qué significa: /mnt/c está montado; las opciones muestran cómo se comportan permisos y manejo de mayúsculas.

Decisión: Si falta el montaje, arregla el automontaje. Si las opciones no son las que necesitas (sin metadata, uid incorrecto), corrige /etc/wsl.conf o vuelve a montar.

Tarea 3: Comprueba que la ruta exista y no sea un symlink roto

cr0x@server:~$ ls -ld /mnt/c /mnt/c/Users
drwxrwxrwx 1 cr0x cr0x 4096 Jan 20 09:10 /mnt/c
drwxrwxrwx 1 cr0x cr0x 4096 Jan 20 09:10 /mnt/c/Users

Qué significa: Las entradas de directorio existen y son accesibles desde el punto de vista de Linux.

Decisión: Si ls mismo falla, esto es montaje/interop, no permisos a nivel de aplicación.

Tarea 4: Reproduce la falla con una prueba mínima de escritura

cr0x@server:~$ touch /mnt/c/Users/cr0x/Desktop/wsl_write_test.txt
touch: cannot touch '/mnt/c/Users/cr0x/Desktop/wsl_write_test.txt': Permission denied

Qué significa: Linux intentó la escritura; Windows/DrvFS la rechazó.

Decisión: Sospecha ACL de NTFS, controlled folder access o controles de endpoint corporativos. Prueba escribir en un directorio menos protegido (como /mnt/c/Users/cr0x), luego arregla permisos/políticas del lado de Windows o mueve la carga.

Tarea 5: Prueba escritura en la raíz del perfil de usuario (a menudo menos protegida)

cr0x@server:~$ mkdir -p /mnt/c/Users/cr0x/wsl_scratch
cr0x@server:~$ echo ok > /mnt/c/Users/cr0x/wsl_scratch/test.txt
cr0x@server:~$ cat /mnt/c/Users/cr0x/wsl_scratch/test.txt
ok

Qué significa: Las escrituras funcionan en esta ubicación. La falla anterior es específica de ubicación/política.

Decisión: Coloca cargas de escritura de WSL en un lugar escribible o ajusta la seguridad de Windows para la carpeta bloqueada (con tu equipo de seguridad, no por soluciones locales improvisadas).

Tarea 6: Identifica las opciones de montaje que controlan la proyección de permisos

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /mnt/c
C:\ /mnt/c drvfs rw,noatime,uid=1000,gid=1000,case=off

Qué significa: No aparece la opción metadata; la propiedad se proyecta mediante mapeo uid/gid.

Decisión: Si necesitas semántica chmod/chown para herramientas de build, habilita metadata (y acepta los trade-offs) o mueve el repositorio a ext4.

Tarea 7: Comprueba la configuración de automount de WSL

cr0x@server:~$ cat /etc/wsl.conf
[automount]
enabled = true
root = /mnt/
options = "metadata,uid=1000,gid=1000,umask=022,fmask=111"

Qué significa: El automontaje está activado; los montajes DrvFS incluirán metadata y máscaras específicas.

Decisión: Si enabled es false o faltan opciones, corrige ese archivo y reinicia WSL para aplicar.

Tarea 8: Aplica los cambios de configuración reiniciando WSL (desde Linux)

cr0x@server:~$ wsl.exe --shutdown

Qué significa: Termina todas las instancias de WSL; el próximo inicio vuelve a leer la configuración y monta de nuevo las unidades.

Decisión: Haz esto tras editar /etc/wsl.conf o cuando los montajes parezcan obsoletos.

Tarea 9: Verifica el comportamiento de metadata mediante chmod en DrvFS

cr0x@server:~$ cd /mnt/c/Users/cr0x/wsl_scratch
cr0x@server:~$ echo hi > permtest.sh
cr0x@server:~$ chmod +x permtest.sh
cr0x@server:~$ ls -l permtest.sh
-rwxr-xr-x 1 cr0x cr0x 3 Jan 20 10:02 permtest.sh

Qué significa: Si chmod persiste y el bit de ejecución aparece, metadata está funcionando (o los bits de ejecución se están proyectando por máscaras).

Decisión: Si el bit de ejecución se niega a quedarse, no estás usando metadata (o fmask lo bloquea). Arregla las opciones de montaje o deja de colocar ejecutables en DrvFS.

Tarea 10: Detecta bloqueos obvios de Windows intentando renombrar

cr0x@server:~$ mv /mnt/c/Users/cr0x/wsl_scratch/test.txt /mnt/c/Users/cr0x/wsl_scratch/test.txt.bak
mv: cannot move '/mnt/c/Users/cr0x/wsl_scratch/test.txt' to '/mnt/c/Users/cr0x/wsl_scratch/test.txt.bak': Device or resource busy

Qué significa: “Device or resource busy” en DrvFS a menudo indica que Windows tiene un handle abierto con flags de compartición incompatibles, o que un AV/EDR lo retiene.

Decisión: Cierra aplicaciones de Windows que toquen el archivo (editores, indexadores). Si es persistente, considera excluir la ruta (con aprobación de políticas) o mueve la carga a ext4.

Tarea 11: Compara rendimiento: montaje de Windows vs sistema de archivos Linux

cr0x@server:~$ time bash -lc 'mkdir -p /mnt/c/Users/cr0x/wsl_scratch/io && for i in $(seq 1 5000); do echo $i > /mnt/c/Users/cr0x/wsl_scratch/io/f_$i; done'
real	0m22.381s
user	0m3.112s
sys	0m9.847s

Qué significa: Eso es mucha sobrecarga para operaciones con archivos pequeños en DrvFS.

Decisión: Si tu build hace patrones similares (node, git, pip), deja de usar /mnt/c para el repositorio.

cr0x@server:~$ time bash -lc 'mkdir -p ~/io && for i in $(seq 1 5000); do echo $i > ~/io/f_$i; done'
real	0m2.941s
user	0m1.812s
sys	0m1.006s

Qué significa: ext4 en WSL2 es drásticamente más rápido para cargas con mucha metadata.

Decisión: Mantén repos y artefactos de build en el sistema de archivos de Linux; usa el acceso de Windows vía \\wsl$ si es necesario.

Tarea 12: Confirma uso de disco de la distro (presión de VHDX puede causar rarezas)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb       100G   78G   22G  79% /

Qué significa: Tu sistema de archivos Linux tiene espacio libre limitado. El espacio bajo puede convertir operaciones normales en fallos.

Decisión: Limpia artefactos de build, capas de docker o caches. Si llegas al 100%, arregla eso antes de culpar a los montajes.

Tarea 13: Diagnostica expectativas de propiedad (¿quién soy, realmente?)

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo)

Qué significa: Confirma uid/gid, útil cuando las opciones de montaje fuerzan mapeo de propiedad.

Decisión: Si el montaje muestra uid/gid diferente de tu usuario, corrige las opciones de montaje o te preguntarás “¿por qué todo es propiedad de 1001?” para siempre.

Tarea 14: Confirma el comportamiento de sensibilidad a mayúsculas en el montaje

cr0x@server:~$ findmnt -no OPTIONS /mnt/c | tr ',' '\n' | grep -E '^case='
case=off

Qué significa: DrvFS está tratando rutas de forma insensible a mayúsculas para las búsquedas.

Decisión: Si tienes repos con archivos que solo difieren por mayúsculas, no los mantengas en /mnt/c. Colócalos en ext4 para evitar caos entre herramientas.

Tarea 15: Verifica acceso desde Windows a archivos de WSL (dirección inversa)

cr0x@server:~$ explorer.exe .

Qué significa: Abre el Explorador de Windows en el directorio Linux actual mediante la integración de WSL.

Decisión: Si Windows no puede navegar o da errores, puedes tener problemas de integración WSL o restricciones de políticas; esto afecta flujos que esperan que herramientas de Windows accedan archivos de WSL.

Tarea 16: Revisa entradas fstab que puedan anular el automontaje

cr0x@server:~$ cat /etc/fstab
C:\ /mnt/c drvfs metadata,uid=1000,gid=1000,umask=022,fmask=111 0 0

Qué significa: Estás montando C: explícitamente. Esto anula valores por defecto y puede entrar en conflicto con la configuración de automontaje.

Decisión: Si las cosas están raras, simplifica: usa automount con wsl.conf o gestiona montajes en fstab—no hagas ambas cosas a menos que disfrutes las sorpresas.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: El incidente causado por una suposición equivocada

Un equipo de producto estandarizó en “mantener el monorepo en C:\ para que las herramientas de Windows funcionen, y WSL simplemente use /mnt/c.” Sonaba razonable. Incluso funcionó durante el piloto, cuando el repo era pequeño y las máquinas de los desarrolladores estaban frescas.

Luego lo desplegaron a unas pocas decenas de ingenieros. Los tiempos de build se dispararon, las pruebas empezaron a agotar el tiempo y un puñado de builds comenzaron a fallar con errores esporádicos de “file not found”. La primera ola de depuración se concentró en el sistema de build. Naturalmente. Nadie quiere admitir que el sistema de archivos es el culpable porque se siente a echarle la culpa al suelo por tropezar.

El modo de fallo real: el build generó decenas de miles de archivos pequeños bajo /mnt/c, lo que activó el escaneo e indexado del lado de Windows. Bajo carga, las operaciones de archivos se volvieron lo suficientemente lentas como para que las herramientas alcanzaran tiempos internos de espera y empezaran a comportarse de forma no determinista. Algunos desarrolladores “lo arreglaron” deshabilitando herramientas de seguridad, lo que creó otro tipo de incidente esperando a suceder.

La corrección fue aburrida y efectiva: mover los repos activos a ext4 de WSL (~/src) y accederlos desde editores de Windows vía \\wsl$ cuando era necesario. Mantuvieron una copia pequeña en Windows solo para flujos que realmente requirieran rutas nativas. El incidente no era un bug del build. Era un bug de suposición.

Microhistoria 2: La optimización que salió mal

Un desarrollador obsesionado con la infraestructura intentó “arreglar los permisos de una vez por todas” activando metadata en DrvFS en toda la flota y estableciendo umasks permisivos. La meta: hacer que las herramientas Linux se comportaran más como Linux, especialmente alrededor de ejecutables y hooks de git.

El despliegue fue fluido—hasta que un agente de backup basado en Windows y un par de plugins de IDE comenzaron a reaccionar mal. Algunas herramientas interpretaron la metadata extra de formas que cambiaron atributos de archivo o dispararon reescaneos. En unas pocas máquinas, árboles de carpetas masivos empezaron a girar: actualizaciones de timestamps, cambios de atributos y notificaciones repetidas de “archivos cambiados”.

El resultado no fue pérdida de datos, pero sí pérdida de flujo de trabajo: git status siempre parecía sucio, algunas herramientas de Windows se ralentizaron y la gente dejó de confiar en su copia de trabajo. La optimización “funcionó” para la semántica Linux pero ignoró el ecosistema de Windows que también tocaba esos archivos.

La solución fue dejar de perseguir una configuración universal. Limitaron montajes con metadata a directorios de proyecto específicos donde se requerían semánticas Linux, y mantuvieron el comportamiento DrvFS por defecto en otros lugares. Mejor aún: movieron la mayoría de los repos a ext4 y trataron /mnt/c como una frontera, no como un hogar.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un equipo empresarial preocupado por la seguridad tenía una regla: no hacer cambios improvisados en la configuración de seguridad de Windows para “hacer que las herramientas dev funcionen”. En su lugar, mantenían una carpeta estándar para desarrolladores bajo el perfil de usuario con ACLs conocidas y documentaban dónde se permitía escribir a las cargas de WSL.

Al principio molestaba a la gente. A los ingenieros no les gusta seguir una política de carpetas cuando “solo están intentando ejecutar pruebas”. Pero luego una actualización de Windows introdujo comportamiento más estricto para carpetas protegidas, y muchas máquinas empezaron a lanzar Permission denied cuando WSL intentaba escribir en Desktop o Documents.

Los equipos sin la política tuvieron que improvisar: la gente hizo excepciones locales, algunos deshabilitaron protección y seguridad tuvo que recuperar configuraciones inconsistentes. El equipo con la política aburrida? Apenas lo notó. Sus flujos ya escribían en el directorio aprobado de scratch/workspace, y sus repos vivían en ext4 de WSL.

La lección práctica: no puedes ganarle a la política de endpoint con chmod. Solo puedes diseñar alrededor de ella.

Errores comunes: síntoma → causa raíz → solución

1) “/mnt/c falta”

Síntoma: ls /mnt/c devuelve “No such file or directory.”

Causa raíz: Automontaje deshabilitado en /etc/wsl.conf, WSL no reiniciado o una entrada rota en /etc/fstab impidió el montaje.

Solución: Habilita automount o corrige /etc/fstab; ejecuta wsl.exe --shutdown y relanza.

2) “Permission denied en Desktop/Documents”

Síntoma: Fallan escrituras en carpetas de usuario que “deberían ser tuyas”.

Causa raíz: Controlled folder access de Windows, controles de endpoint corporativos o ACLs endurecidas en carpetas protegidas.

Solución: Usa un directorio conocido escribible bajo tu perfil (o un workspace aprobado por el equipo). Si la política lo permite, solicita una excepción a seguridad—no soluciones locales improvisadas.

3) “chmod +x no persiste en /mnt/c”

Síntoma: El archivo sigue sin ser ejecutable después de chmod; fallan hooks de git; los scripts no se ejecutan.

Causa raíz: DrvFS sin metadata, o fmask enmascarando bits de ejecución.

Solución: Habilita metadata para ese montaje, o mantén ejecutables dentro del sistema de archivos de Linux. Ajusta fmask/umask si estás proyectando permisos.

4) “Todo es propiedad de root”

Síntoma: ls -l muestra root root o uid/gid inesperados en /mnt/c.

Causa raíz: Opciones de montaje mapeando propiedad incorrectamente (faltan uid/gid), o montaje personalizado en /etc/fstab.

Solución: Establece uid=1000,gid=1000 (o tus IDs reales) en opciones de automount; reinicia WSL.

5) “Git status es lento / builds se arrastran”

Síntoma: Operaciones pequeñas son glaciares en /mnt/c, bien en ~.

Causa raíz: Sobrecarga entre fronteras + escaneo/indexado de Windows + desajuste de semánticas NTFS para cargas intensivas en Linux.

Solución: Mueve el repo a ext4 en WSL2. Accede desde Windows vía \\wsl$. Mantén artefactos de build fuera de /mnt/c.

6) “Error de entrada/salida en /mnt/c”

Síntoma: Errores I/O aleatorios al leer archivos de Windows.

Causa raíz: Errores en el sistema de archivos de Windows subyacente, desconexiones de unidades (media externa) o unidades en red inestables presentadas como letras.

Solución: Valida la salud de la unidad en Windows, evita unidades externas/red para rutas dev críticas y vuelve a montar tras reconexiones.

7) “Renombres solo por mayúsculas no funcionan”

Síntoma: Renombrar Readme.md a README.md se comporta de forma extraña; las herramientas no coinciden.

Causa raíz: Configuración de sensibilidad a mayúsculas diferente; DrvFS puede estar con case=off.

Solución: Mantén esos repos en ext4, o aplica convenciones de nombres que no dependan de diferencias solo en mayúsculas.

8) “La creación de symlinks falla”

Síntoma: Crear symlinks da error, o los enlaces se comportan distinto en ambos lados.

Causa raíz: Restricciones de política de Windows sobre creación de symlinks; semánticas distintas entre Windows y Linux.

Solución: Prefiere symlinks del lado Linux dentro de ext4; evita symlinks entre fronteras cuando sea posible; habilita las características de desarrollador de Windows si está permitido.

Listas de verificación / plan paso a paso

Lista A: “WSL2 no ve /mnt/c” (caída a nivel de montaje)

1. Ejecuta mount | grep drvfs y confirma si C: está montado o no.
2. Inspecciona /etc/wsl.conf buscando [automount] y enabled=true.
3. Inspecciona /etc/fstab en busca de entradas DrvFS rotas. Comenta temporalmente líneas sospechosas.
4. Reinicia WSL con wsl.exe --shutdown.
5. Vuelve a comprobar con findmnt /mnt/c. Si aún falla, trátalo como problema de integración Windows/WSL, no como permisos de Linux.

Lista B: “Permission denied” (falla de escritura)

1. Reproduce con touch en el directorio exacto.
2. Intenta escribir en una ruta menos protegida (como /mnt/c/Users/<tú>/wsl_scratch).
3. Si funciona en otro lugar, para. Esto no es un problema de chmod.
4. Decide: mueve la carga a ext4, o arregla la ACL/política de Windows para ese directorio.
5. Si es gestionado por la empresa: abre un ticket con la ruta exacta y comandos mínimos de reproducción, no “WSL está roto”.

Lista C: “chmod/chown no funciona” (herramientas Linux descontentas)

1. Chequea opciones de montaje con findmnt -no OPTIONS /mnt/c.
2. Si falta metadata, decide si realmente necesitas permisos POSIX en NTFS.
3. Si la respuesta es sí: habilita metadata vía /etc/wsl.conf o un montaje explícito en fstab.
4. Reinicia WSL.
5. Vuelve a probar con chmod +x y confirma vía ls -l.
6. Si sigue inconsistente: mueve ejecutables y salidas de build a ext4. Esa es la respuesta madura.

Lista D: “Todo está lento” (tría de rendimiento)

1. Benchmarkea una carga de archivos pequeños en /mnt/c vs ~ (como los ejemplos de bucle arriba).
2. Si /mnt/c es mucho más lento, deja de intentar arreglarlo con flags aleatorios.
3. Mueve el repo a ext4. Usa herramientas de Windows vía \\wsl$ o explorer.exe .
4. Mantén en /mnt/c solo activos que “deben estar en NTFS” (archivos grandes, medios, carpetas compartidas con herramientas Windows).
5. Vuelve a ejecutar el benchmark para demostrar la solución; documéntalo para la próxima persona.

Preguntas frecuentes (FAQ)

1) ¿Por qué WSL2 a veces muestra permisos extraños en /mnt/c?

Porque DrvFS está mapeando ACLs de NTFS a una vista tipo POSIX. Sin metadata, los bits de modo son mayormente una proyección controlada por opciones de montaje, no la verdad autorizada.

2) ¿Debería almacenar mi repo git en /mnt/c o en el sistema de archivos de Linux?

Pon repos activos en el sistema de archivos de Linux (ext4) a menos que tengas un requisito fuerte nativo de Windows. Los builds, gestores de paquetes y git suelen ser más rápidos y fiables ahí.

3) Si chmod no funciona en /mnt/c, ¿está WSL roto?

No. Es comportamiento esperado sin metadata. O habilitas metadata (aceptando trade-offs) o no dependes de chmod en montajes DrvFS.

4) ¿Por qué puedo leer un archivo de Windows pero no escribirlo desde WSL2?

Leer a menudo está permitido de forma amplia, mientras que escribir puede bloquearse por ACLs de NTFS, carpetas protegidas, controlled folder access o herramientas de seguridad de endpoint.

5) ¿Cuál es la forma más limpia de aplicar cambios de montaje en wsl.conf?

Edita /etc/wsl.conf, luego reinicia WSL con wsl.exe --shutdown. Un simple cierre de la distro no vuelve a aplicar de forma fiable el comportamiento de automontaje.

6) ¿Es buena idea habilitar metadata siempre?

No. Mejora las semánticas Linux sobre NTFS, pero puede sorprender a herramientas de Windows y crear inconsistencia si múltiples entornos tocan el mismo árbol. Úsalo deliberadamente, idealmente solo donde se necesite.

7) ¿Por qué algunas operaciones en /mnt/c cuelgan o agotan el tiempo?

Las operaciones entre fronteras pueden verse ralentizadas por escaneo del lado de Windows, indexado, bloqueo de archivos o simplemente la sobrecarga de traducir operaciones. Si es rápido en ext4 y lento en DrvFS, esa es la respuesta.

8) ¿Puedo acceder archivos de WSL desde Windows de forma fiable?

Generalmente sí vía \\wsl$ e integración con explorer.exe. Para cargas de escritura intensiva desde aplicaciones de Windows hacia el sistema de archivos Linux, prueba tus herramientas específicas—algunas siguen comportándose mejor en NTFS.

9) ¿Por qué un renombre que solo cambia mayúsculas se comporta de forma extraña?

Windows suele ser insensible a mayúsculas por defecto; Linux es sensible. Si tu montaje es case=off, las diferencias solo por mayúsculas pueden confundir herramientas. Mantén esos repos en ext4.

10) ¿Qué debo hacer si la seguridad corporativa bloquea a WSL escribir en ciertas carpetas?

No juegues al whack-a-mole. Usa un directorio de workspace aprobado, mantén repos en ext4 y solicita cambios de política por el canal adecuado con un repro mínimo y justificación de negocio.

Conclusión: próximos pasos que no te hacen perder la semana

Si WSL2 no puede acceder a archivos de Windows, deja de adivinar y sigue la cadena de responsabilidad:

1. Confirma el montaje existe y es DrvFS con las opciones que crees tener.
2. Reproduce con una escritura mínima para separar problemas de montaje de políticas/ACLs de Windows.
3. Decide dónde vive la carga: sistema de archivos Linux para cargas Linuxeras; NTFS solo cuando las herramientas Windows realmente lo necesiten.
4. Estandariza la configuración (wsl.conf + procedimiento de reinicio) para que las correcciones no se evaporen tras actualizaciones o reinicios.

La “solución” más fiable suele ser arquitectónica: coloca tus árboles de desarrollo que cambian rápido en ext4, trata /mnt/c como una frontera de integración y reserva el ajuste de permisos para los casos que realmente lo requieran. Ese enfoque no es glamoroso. También funciona.