WSL2 n’arrive pas à accéder aux fichiers Windows ? Montages et permissions essentiels

Le modèle mental : ce que WSL2 fait réellement

WSL2 n’est pas « Linux qui tourne sur Windows » dans le sens chaleureux que les gens sous‑entendent. C’est un noyau Linux réel tournant dans une VM légère (basée sur Hyper‑V), Windows fournissant la plomberie d’intégration. C’est cette plomberie que vous combattez quand des fichiers Windows « disparaissent » ou que les permissions semblent hantées.

À l’intérieur de WSL2 vous avez typiquement deux classes de stockage :

• Le système de fichiers Linux (ext4 dans un VHDX) pour votre distribution, vivant sous /. C’est rapide et se comporte comme Linux l’attend.
• Les fichiers Windows exposés à Linux via des montages DrvFS, généralement sous /mnt/c, /mnt/d, etc. C’est une couche de compatibilité qui mappe les sémantiques NTFS en quelque chose que Linux peut utiliser.

Ce mapping est la source de la plupart des confusions. Les permissions Linux sont des bits de mode simples + propriété. Les permissions Windows sont des ACL, des règles héritées, des entrées de refus, et des « ça dépend » intégrés dans l’OS. DrvFS tente de représenter les objets Windows comme des fichiers Linux. Parfois ça marche. Parfois il ment poliment.

Opérationnellement, vous devez choisir votre champ de bataille :

• Si vous compilez, indexez, ou effectuez beaucoup d’opérations sur des petits fichiers : mettez le dépôt dans le système de fichiers Linux (~/src) et accédez‑y depuis Windows via \\wsl$.
• Si vous devez conserver des fichiers sur NTFS : traitez /mnt/c comme un système de fichiers réseau avec des particularités. Ajustez les options de montage. Évitez de compter sur chmod/chown sauf si vous activez metadata.

Une citation pour garder votre cerveau SRE en alerte : L’espoir n’est pas une stratégie. — Général Gordon R. Sullivan. Dans les systèmes de fichiers, « espérer que ça se montera comme la dernière fois » est la façon dont vous vous retrouvez à déboguer à 2 h du matin.

Petite blague #1 : DrvFS est comme un traducteur dans un bar bruyant — la plupart du temps fidèle, parfois invente le sens, toujours convaincu d’aider.

Faits et historique intéressants (parce que les détails comptent)

• WSL1 et WSL2 sont des bêtes différentes. WSL1 traduisait les appels système Linux vers les internals de Windows ; WSL2 exécute un noyau Linux réel dans une VM.
• DrvFS précède WSL2. Le concept de montage des lecteurs Windows existait dans WSL1, mais l’implémentation sous‑jacente et les caractéristiques de performance ont changé avec la frontière VM.
• La sensibilité à la casse n’est pas universelle sur Windows. NTFS peut préserver la casse et être optionnellement sensible à la casse par répertoire ; historiquement, les API Win32 traitaient les chemins comme insensibles à la casse par défaut.
• Les permissions NTFS sont basées sur des ACL. Les bits de mode Linux sont une simplification qui ne représente pas proprement les règles de refus, l’héritage ou les multiples principaux.
• Le stockage WSL2 vit dans un VHDX. Le système racine de votre distribution est dans un disque virtuel ; le déplacer entre machines ou le sauvegarder est possible mais demande de la prudence.
• L’indexation Windows et l’antivirus comptent. Toucher beaucoup de fichiers sur NTFS depuis WSL2 peut déclencher des scans côté Windows, ce qui ressemble à un « Linux lent » pendant que Windows fait le travail.
• Des idées 9P et Plan 9 réapparaissent dans l’écosystème. Certains mécanismes de partage de fichiers inter‑OS empruntent des concepts proches des protocoles de système de fichiers distants ; les opérations inter‑frontières ne sont jamais gratuites.
• Le mapping des permissions est configurable. Les options de montage DrvFS comme metadata, uid, gid, umask et fmask modifient ce que Linux croit voir.

Playbook de diagnostic rapide : trouver le goulot en quelques minutes

Quand « WSL2 ne peut pas accéder aux fichiers Windows » survient, votre travail est de séparer : problème de montage, problème de permissions, problème de chemin/interop, ou problème de performance/timeout. Voici le chemin le plus rapide que j’ai trouvé et qui ne dérive pas dans la superstition.

Première étape : le lecteur est‑il monté comme vous le pensez ?

• Vérifiez mount et cherchez type drvfs sur /mnt/c (ou votre racine de montage configurée).
• Si le montage est manquant ou incorrect, corrigez l’automount ou /etc/fstab avant de toucher aux permissions.

Deuxième étape : l’échec concerne‑t‑il les permissions Linux ou les ACL Windows ?

• Testez la création/écriture en tant que votre utilisateur Linux dans un dossier connu sur C: (comme votre profil utilisateur Windows).
• Si vous pouvez lire mais pas écrire, il s’agit presque toujours d’une ACL NTFS ou d’un outil de politique d’entreprise (EDR, controlled folder access), pas de « chmod ».

Troisième étape : est‑ce un échec de performance déguisé en « impossible d’accéder » ?

• Si les outils expirent, se bloquent ou se comportent de manière instable sur /mnt/c, reproduisez la même opération sous ~ (ext4 Linux). Si c’est rapide là‑bas, vous voyez la surcharge de la frontière Windows.
• En cas de doute : déplacez la charge vers le système de fichiers Linux et exposez‑la ensuite à Windows via \\wsl$.

Quatrième étape : vérifiez les « pièges » inter‑plateformes

• Conflits de sensibilité à la casse, caractères de nom de fichier invalides, comportement des liens symboliques, et outils gérant les fins de ligne peuvent faire paraître un « accès » cassé.
• Confirmez que vous n’écrivez pas des fichiers avec des noms que Windows ne peut pas représenter, puis que vous attendez qu’ils se comportent sous NTFS.

Montages importants : DrvFS, VolFs, et où résident réellement vos données

La plupart des gens apprennent un seul chemin : /mnt/c. Puis ils supposent que c’est « juste un dossier ». Ce n’est pas le cas. C’est un système de fichiers monté de type drvfs, et ses options de montage décident de tout, depuis les permissions visibles jusqu’à l’impact de chmod.

Points de montage DrvFS : /mnt/c est un choix de politique

Par défaut, WSL monte automatiquement les disques fixes sous /mnt/<lettreDeLecteur>. Ce comportement peut être modifié dans /etc/wsl.conf. Ce changement peut aussi casser des scripts, des étapes CI, ou la mémoire musculaire des développeurs — traitez‑le donc comme une modification d’API.

Système de fichiers Linux dans WSL2 : votre vraie zone de performance

À l’intérieur de la VM WSL2, le système racine de votre distribution est ext4 (typiquement) et se comporte comme une machine Linux normale. Si votre charge est « orientée Linux » (churn de node_modules, builds Rust, venv Python, opérations git), la garder sur ext4 fait la différence entre « ça marche » et « mon portable est un radiateur ».

Où les montages tournent mal

Modes d’échec de montage courants que j’ai vus dans des flottes de développeurs :

• Automount désactivé : pas de /mnt/c, ou seuls certains disques apparaissent.
• Changements de lettre de lecteur : médias amovibles, états de déverrouillage BitLocker, ou politiques de gestion de disque en entreprise changent les lettres.
• Erreurs dans fstab : une entrée mal formée peut empêcher les montages attendus et vous laisser déboguer des « permissions » alors que le système de fichiers n’est même pas présent.
• Chemins réseau : mapper des lecteurs réseau Windows n’est pas la même chose qu’un NTFS local. Vous pourriez nécessiter une approche différente (et des attentes adaptées).

Options de montage qui changent réellement le comportement

Les options de montage sont l’endroit où vous décidez si les permissions Linux sont « réelles » (metadata) ou « projetées » (basées sur des masques). Voici la vérité opérationnelle :

• Sans metadata : chmod/chown ne persisteront généralement pas car il n’y a nulle part où stocker la propriété POSIX sur des fichiers NTFS présentés par DrvFS.
• Avec metadata : WSL stocke des métadonnées supplémentaires (pensez « attributs étendus ») pour préserver les bits de mode Linux et les mappages de propriété. Cela rend les outils Linux plus heureux, mais peut surprendre les outils Windows et d’autres machines.
• uid/gid/umask/fmask/dmask : utiles quand vous voulez une propriété et des modes cohérents pour tout sur ce montage, surtout sans metadata.

Il n’existe pas d’ensemble d’options universellement « correct ». Il n’y a que « correct pour ce que vous exécutez » et « correct pour ce que votre équipe attend ». Choisissez‑en un et standardisez‑le.

Permissions importantes : ACL NTFS vs bits de mode Linux

Quand Linux dit « permission denied », il vous informe que l’appel système a échoué. Cela ne signifie pas que les bits de mode Linux sont incorrects. Cela peut être :

• Une ACL Windows refuse l’action (explicitement ou via une politique héritée).
• Le « controlled folder access » de Windows bloque les écritures dans des répertoires protégés.
• Des hooks EDR/antivirus bloquent ou retardent l’accès jusqu’à un timeout.
• Le fichier est verrouillé par un processus Windows avec des modes de partage incompatibles avec ce que Linux attend.

Comprendre le mapping : qui possède quoi ?

Par défaut, DrvFS présente souvent les fichiers Windows comme appartenant à votre utilisateur Linux (ou parfois à des valeurs root‑like selon la configuration) avec des bits de mode permissifs apparents. Ces bits ne sont pas l’autorité ; les ACL NTFS le sont.

Si vous activez metadata, la propriété et les bits de mode Linux peuvent devenir plus significatifs au sein de WSL. Mais les applications Windows appliquent toujours les ACL NTFS et peuvent ignorer ou écraser les métadonnées de type POSIX.

Ce que « chmod ne fonctionne pas » signifie vraiment

Sur DrvFS sans metadata, chmod revient à crier sur un tableau : on se sent productif, rien ne change. La bonne correction est soit :

• Activer metadata afin que chmod ait un endroit où persister.
• Cesser de compter sur chmod/chown et gérer l’accès via les ACL Windows (Explorateur, icacls, stratégie de groupe).
• Déplacer la charge de travail vers le système de fichiers Linux où les permissions POSIX sont natives.

Liens symboliques : le piège silencieux des permissions

Les liens symboliques de Linux vers des chemins Windows et vice‑versa peuvent échouer de façons qui ressemblent à des permissions. La création de symlinks Windows peut requérir le mode Développeur ou des droits administrateur selon la politique. Aussi : un symlink qui résout vers un chemin Windows hérite du comportement des ACL Windows. Votre processus Linux n’obtient pas d’exemption magique.

Petite blague #2 : j’ai vu « réparer les permissions » être exécuté tellement de fois qu’il mérite une carte de fidélité — achetez neuf chmods, obtenez le dixième gratuit, toujours cassé.

Tâches pratiques : commandes, sorties et quoi décider ensuite

Voici des tâches réelles que j’exécuterais sur un portable de flotte ou une station de développement pendant que quelqu’un dit « WSL2 ne peut pas accéder aux fichiers ». Chaque tâche inclut : la commande, une sortie d’exemple, ce que ça signifie, et la décision à prendre.

Task 1: Confirm you’re in WSL2 (not WSL1)

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

Ce que ça signifie : Une chaîne de noyau contenant microsoft et WSL2 indique que vous exécutez le noyau WSL2.

Décision : Si c’est WSL1, les sémantiques d’accès aux fichiers et les performances diffèrent ; ajustez les attentes et envisagez de migrer la distribution vers WSL2.

Task 2: See what’s mounted and whether C: is DrvFS

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

Ce que ça signifie : /mnt/c est monté ; les options montrent comment les permissions et la gestion de la casse se comportent.

Décision : Si le montage est manquant, corrigez l’automount. Si les options ne sont pas ce dont vous avez besoin (pas de metadata, mauvais uid), corrigez /etc/wsl.conf ou remontez.

Task 3: Check that the path exists and isn’t a broken symlink

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

Ce que ça signifie : Les entrées de répertoire existent et sont accessibles du point de vue Linux.

Décision : Si ls lui‑même renvoie une erreur, il s’agit d’un montage/interop, pas d’un problème de permissions applicatives.

Task 4: Reproduce the failure with a minimal write test

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

Ce que ça signifie : Linux a tenté l’écriture ; Windows/DrvFS l’a refusée.

Décision : Suspectez une ACL NTFS, controlled folder access, ou des contrôles d’endpoint d’entreprise. Testez l’écriture dans un répertoire moins protégé (comme /mnt/c/Users/cr0x), puis corrigez les permissions/politiques côté Windows ou déplacez la charge de travail.

Task 5: Test write in the user profile root (often less protected)

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

Ce que ça signifie : Les écritures fonctionnent dans cet emplacement. L’échec antérieur est spécifique à l’emplacement/politique.

Décision : Placez les charges WSL‑écritures dans un emplacement accessible en écriture ou ajustez les paramètres de sécurité Windows pour le dossier bloqué (avec votre équipe sécurité, pas en bricolant localement).

Task 6: Identify the mount options that control permission projection

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

Ce que ça signifie : Pas d’option metadata ; la propriété est projetée via le mapping uid/gid.

Décision : Si vous avez besoin des sémantiques chmod/chown pour des outils de build, activez metadata (et acceptez les compromis) ou déplacez le dépôt vers ext4.

Task 7: Check current WSL automount config

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

Ce que ça signifie : L’automount est activé ; les montages DrvFS incluront metadata et des masques spécifiques.

Décision : Si enabled est false ou que des options manquent, corrigez ce fichier, puis redémarrez WSL pour appliquer.

Task 8: Apply config changes by restarting WSL (from inside Linux)

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

Ce que ça signifie : Termine toutes les instances WSL ; le prochain lancement relira la config et remontera les lecteurs.

Décision : Faites cela après avoir modifié /etc/wsl.conf ou lorsque les montages semblent obsolètes.

Task 9: Verify metadata behavior via chmod on 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

Ce que ça signifie : Si chmod persiste et que le bit d’exécution apparaît, metadata fonctionne (ou les bits d’exécution sont projetés par des masques).

Décision : Si le bit d’exécution refuse de rester, vous n’utilisez pas metadata (ou fmask le bloque). Corrigez les options de montage ou cessez de placer des exécutables sur DrvFS.

Task 10: Spot obvious Windows locks by trying a rename

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

Ce que ça signifie : « Device or resource busy » sur DrvFS indique souvent que Windows a un handle ouvert avec des flags de partage incompatibles, ou qu’un AV/EDR le maintient.

Décision : Fermez les applications Windows touchant le fichier (éditeurs, indexeurs). Si persistant, envisagez d’exclure le chemin (avec approbation politique) ou déplacez la charge vers ext4.

Task 11: Compare performance: Windows mount vs Linux filesystem

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

Ce que ça signifie : C’est beaucoup de surcharge pour des opérations sur petits fichiers sur DrvFS.

Décision : Si votre build fait des patterns similaires (node, git, pip), cessez d’utiliser /mnt/c pour le dépôt.

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

Ce que ça signifie : ext4 dans WSL2 est beaucoup plus rapide pour les charges lourdes en métadonnées.

Décision : Gardez les dépôts et artefacts de build dans le système de fichiers Linux ; utilisez l’accès Windows via \\wsl$ si nécessaire.

Task 12: Confirm distro disk usage (VHDX pressure can cause weirdness)

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

Ce que ça signifie : Votre système de fichiers Linux a peu d’espace libre. Un espace bas peut transformer des opérations normales en échecs.

Décision : Nettoyez les artefacts de build, couches docker, ou caches. Si vous atteignez 100%, corrigez cela avant d’accuser les montages.

Task 13: Diagnose ownership expectations (who am I, really?)

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

Ce que ça signifie : Confirme l’uid/gid, utile quand les options de montage forcent un mapping de propriété.

Décision : Si le montage affiche un uid/gid différent du vôtre, corrigez les options de montage ou vous aurez l’éternelle question « pourquoi tout est possédé par 1001 ? ».

Task 14: Confirm case sensitivity behavior on the mount

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

Ce que ça signifie : DrvFS traite les chemins de manière insensible à la casse pour les recherches.

Décision : Si vous avez des dépôts avec des fichiers ne différant que par la casse, ne les gardez pas sur /mnt/c. Mettez‑les sur ext4 pour éviter le chaos entre outils.

Task 15: Verify access from Windows to WSL files (reverse direction)

cr0x@server:~$ explorer.exe .

Ce que ça signifie : Ouvre l’Explorateur Windows au répertoire Linux courant via l’intégration WSL.

Décision : Si Windows ne peut pas parcourir ou renvoie une erreur, vous pouvez avoir un problème d’intégration WSL ou des restrictions de politique ; cela affecte les flux de travail qui attendent que les outils Windows accèdent aux fichiers WSL.

Task 16: Check fstab entries that might override automount

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

Ce que ça signifie : Vous montez explicitement C:. Cela remplace les valeurs par défaut et peut entrer en conflit avec les réglages d’automount.

Décision : Si c’est bizarre, simplifiez : utilisez soit automount avec wsl.conf, soit gérez les montages dans fstab — ne faites pas les deux sauf si vous aimez les surprises.

Trois mini-récits d’entreprise venus du terrain

Mini‑récit 1 : L’incident causé par une mauvaise hypothèse

Une équipe produit a standardisé la pratique « garder le monorepo sur C:\ pour que les outils Windows fonctionnent, et WSL utilise simplement /mnt/c ». Ça semblait raisonnable. Ça a même fonctionné pendant le pilote, quand le dépôt était petit et les machines développeurs fraîches.

Puis ils l’ont déployé à quelques dizaines d’ingénieurs. Les temps de build ont explosé, les tests ont commencé à expirer, et quelques builds ont commencé à échouer avec des erreurs sporadiques « file not found ». La première vague de débogage s’est concentrée sur le système de build. Logique. Personne n’aime admettre que le système de fichiers est le coupable parce que ça ressemble à blâmer le sol pour une chute.

Le mode d’échec réel : le build a généré des dizaines de milliers de petits fichiers sous /mnt/c, ce qui a déclenché la numérisation et l’indexation côté Windows. Sous charge, les opérations sur fichiers sont devenues suffisamment lentes pour que les outils atteignent leurs timeouts internes et se comportent de façon nondéterministe. Certains devs « l’ont réparé » en désactivant des outils de sécurité, ce qui a créé un autre type d’incident en attente.

La correction a été ennuyeuse et efficace : déplacer les dépôts actifs dans ext4 WSL (~/src), et y accéder depuis les éditeurs Windows via \\wsl$ quand nécessaire. Ils ont gardé un petit checkout côté Windows uniquement pour les workflows nécessitant réellement des chemins natifs Windows. L’incident n’était pas un bug de build. C’était un bug d’hypothèse.

Mini‑récit 2 : L’optimisation qui s’est retournée contre eux

Un développeur orienté infra a essayé de « corriger les permissions une bonne fois pour toutes » en activant metadata sur DrvFS à l’échelle de la flotte et en définissant des umasks permissifs. L’objectif : faire se comporter les outils Linux comme sous Linux, surtout pour les exécutables et hooks git.

Le déploiement s’est bien passé — jusqu’à ce qu’un agent de sauvegarde Windows et quelques plugins d’IDE commencent à réagir mal. Certains outils ont interprété les métadonnées supplémentaires d’une manière qui a changé des attributs ou déclenché des rescans. Sur quelques machines, des arbres de dossiers massifs se sont mis à bouger : mises à jour de timestamps, basculements d’attributs, et notifications répétées de « fichiers modifiés ».

Le résultat n’a pas été une perte de données, mais une perte de workflow : git status semblait toujours sale, certains outils Windows ralentissaient, et les gens ont perdu confiance dans leur copie de travail. L’optimisation « a fonctionné » pour les sémantiques Linux mais a ignoré l’écosystème Windows qui touchait aussi ces fichiers.

La correction a été d’arrêter de chercher une configuration universelle. Ils ont limité les montages metadata à des répertoires de projet spécifiques où les sémantiques Linux étaient requises, et ont conservé le comportement DrvFS par défaut ailleurs. Mieux : ils ont déplacé la plupart des dépôts vers ext4 et traité /mnt/c comme une frontière, pas un foyer.

Mini‑récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe d’entreprise soucieuse de la sécurité avait une règle : pas de changements ad‑hoc aux paramètres de sécurité Windows pour « faire fonctionner les outils dev ». À la place, ils maintenaient un dossier développeur standard sous le profil utilisateur avec des ACL connues et documentaient où les charges WSL pouvaient écrire.

Au début ça a agacé. Les ingénieurs n’aiment rien moins que devoir suivre une politique de dossier quand ils « essaient juste d’exécuter des tests ». Mais ensuite une mise à jour Windows a introduit un comportement plus strict pour les dossiers protégés, et un tas de machines ont commencé à renvoyer Permission denied quand WSL tentait d’écrire sur le Bureau ou dans Documents.

Les équipes sans politique ont dû se démener : des gens ont fait des exceptions locales, certains ont désactivé la protection, et la sécurité a dû ramener des réglages incohérents. L’équipe avec la politique ennuyeuse ? Elle n’a presque rien remarqué. Leurs workflows écrivaient déjà dans le répertoire de travail approuvé, et leurs dépôts vivaient dans ext4 WSL.

La leçon pratique : vous ne pouvez pas déjouer une politique d’endpoint avec chmod. Vous pouvez seulement concevoir autour.

Erreurs communes : symptôme → cause racine → correction

1) « /mnt/c est manquant »

Symptôme : ls /mnt/c renvoie « No such file or directory ».

Cause racine : Automount désactivé dans /etc/wsl.conf, WSL non redémarré, ou une entrée /etc/fstab cassée empêchant le montage.

Correction : Activez l’automount ou corrigez /etc/fstab ; exécutez wsl.exe --shutdown et relancez.

2) « Permission denied sur Desktop/Documents »

Symptôme : Les écritures échouent dans des dossiers utilisateur qui « devraient être à vous ».

Cause racine : Controlled folder access de Windows, contrôles d’endpoint d’entreprise, ou ACL renforcées sur des dossiers protégés.

Correction : Utilisez un répertoire approuvé et accessible en écriture sous votre profil (ou un workspace approuvé par l’équipe). Si la politique le permet, demandez une exception via la sécurité — pas par des hacks locaux aléatoires.

3) « chmod +x ne tient pas sur /mnt/c »

Symptôme : Le fichier reste non exécutable après chmod ; hooks git échouent ; scripts ne s’exécutent pas.

Cause racine : DrvFS sans metadata, ou fmask masque les bits d’exécution.

Correction : Activez metadata pour ce montage, ou gardez les exécutables dans le système de fichiers Linux. Ajustez fmask/umask si vous projetez des permissions.

4) « Tout est possédé par root »

Symptôme : ls -l montre root root ou des uid/gid inattendus sur /mnt/c.

Cause racine : Options de montage qui mappent la propriété incorrectement (uid/gid manquants), ou montage personnalisé dans /etc/fstab.

Correction : Définissez uid=1000,gid=1000 (ou vos IDs réels) dans les options d’automount ; redémarrez WSL.

5) « Git status est lent / les builds ralentissent »

Symptôme : Les opérations sur petits fichiers sont glacielles sous /mnt/c, correctes sous ~.

Cause racine : Surcharge inter‑frontière + scan/indexation Windows + incompatibilité NTFS pour des charges orientées Linux.

Correction : Déplacez le dépôt vers ext4 dans WSL2. Accédez‑y depuis Windows via \\wsl$. Gardez les artefacts de build hors de /mnt/c.

6) « Input/output error sur /mnt/c »

Symptôme : Erreurs d’E/S aléatoires en lisant des fichiers Windows.

Cause racine : Erreurs du système de fichiers Windows sous‑jacent, déconnexions de disques (media externe), ou lecteurs réseau instables présentés comme lettres.

Correction : Validez la santé du disque sur Windows, évitez les disques externes/réseau pour des chemins dev critiques, et remontez après reconnexion.

7) « Les renommages ne modifiant que la casse ne fonctionnent pas »

Symptôme : Renommer Readme.md en README.md se comporte étrangement ; outils en désaccord.

Cause racine : Paramètres de sensibilité à la casse différents ; DrvFS peut être case=off.

Correction : Gardez ces dépôts sur ext4, ou appliquez des conventions de nommage qui ne reposent pas sur des différences uniquement de casse.

8) « La création de symlink échoue »

Symptôme : La création de symlinks renvoie une erreur, ou les liens se comportent différemment selon le côté.

Cause racine : Restrictions de politique Windows sur la création de symlinks ; sémantiques différentes entre Windows et Linux.

Correction : Préférez les symlinks côté Linux dans ext4 ; évitez les symlinks inter‑frontières quand c’est possible ; activez les fonctionnalités développeur Windows nécessaires si autorisé.

Listes de vérification / plan pas à pas

Checklist A: « WSL2 ne voit pas /mnt/c » (incident niveau montage)

1. Exécutez mount | grep drvfs et confirmez si C: est monté ou non.
2. Inspectez /etc/wsl.conf pour [automount] et enabled=true.
3. Inspectez /etc/fstab pour des entrées DrvFS cassées. Commentez temporairement les lignes suspectes.
4. Redémarrez WSL avec wsl.exe --shutdown.
5. Re‑vérifiez avec findmnt /mnt/c. Si cela échoue toujours, traitez‑le comme un problème d’intégration Windows/WSL, pas des permissions Linux.

Checklist B: « Permission denied » (échec d’écriture)

1. Reproduisez avec touch dans le répertoire exact.
2. Essayez d’écrire dans un chemin moins protégé (comme /mnt/c/Users/<you>/wsl_scratch).
3. Si ça marche ailleurs, arrêtez‑vous. Ce n’est pas un problème de chmod.
4. Décidez : déplacer la charge vers ext4, ou corriger l’ACL/politique Windows pour ce dossier.
5. Si géré par l’entreprise : ouvrez un ticket avec le chemin exact et des commandes de repro minimales, pas « WSL est cassé ».

Checklist C: « chmod/chown ne fonctionne pas » (outils Linux mécontents)

1. Vérifiez les options de montage avec findmnt -no OPTIONS /mnt/c.
2. Si metadata manque, décidez si vous avez vraiment besoin des permissions POSIX sur NTFS.
3. Si oui : activez metadata via /etc/wsl.conf ou un montage explicite dans fstab.
4. Redémarrez WSL.
5. Re‑testez avec chmod +x et confirmez via ls -l.
6. Si toujours incohérent : déplacez exécutables et sorties de build vers ext4. C’est la réponse adulte.

Checklist D: « Tout est lent » (triage performance)

1. Benchmarquez une charge sur petits fichiers sur /mnt/c vs ~ (comme les exemples en boucle ci‑dessus).
2. Si /mnt/c est beaucoup plus lent, cessez d’essayer de vous en sortir avec des flags aléatoires.
3. Déplacez le dépôt vers ext4. Utilisez les outils Windows via \\wsl$ ou explorer.exe .
4. Gardez seulement les actifs « doivent être sur NTFS » sur /mnt/c (gros fichiers média, dossiers partagés avec outils Windows uniquement).
5. Re‑exécutez le benchmark pour prouver la correction ; documentez‑la pour la prochaine personne.

FAQ

1) Pourquoi WSL2 affiche parfois des permissions étranges sur /mnt/c ?

Parce que DrvFS mappe les ACL NTFS dans une vue de type POSIX. Sans metadata, les bits de mode sont surtout une projection contrôlée par les options de montage, pas une vérité autoritaire.

2) Dois‑je stocker mon dépôt git sur /mnt/c ou dans le système de fichiers Linux ?

Mettez les dépôts actifs dans le système de fichiers Linux (ext4) sauf si vous avez une forte contrainte native Windows. Les builds, gestionnaires de paquets et git sont généralement plus rapides et fiables là‑bas.

3) Si chmod ne fonctionne pas sur /mnt/c, est‑ce que WSL est cassé ?

Non. C’est un comportement attendu sans metadata. Activez metadata (en acceptant les compromis) ou ne comptez pas sur chmod sur les montages DrvFS.

4) Pourquoi puis‑je lire un fichier Windows mais pas l’écrire depuis WSL2 ?

La lecture est souvent permise largement, tandis que l’écriture peut être bloquée par des ACL NTFS, des dossiers protégés, controlled folder access, ou des outils de sécurité d’endpoint.

5) Quelle est la manière la plus propre d’appliquer des changements de montage via wsl.conf ?

Éditez /etc/wsl.conf, puis redémarrez WSL avec wsl.exe --shutdown. Une simple sortie de la distribution ne réapplique pas toujours l’automount de façon fiable.

6) Activer metadata est‑ce toujours une bonne idée ?

Non. Cela améliore les sémantiques Linux sur NTFS, mais peut surprendre les outils Windows et créer des incohérences si plusieurs environnements touchent le même arbre. Utilisez‑le délibérément, idéalement uniquement là où c’est nécessaire.

7) Pourquoi certaines opérations sur /mnt/c se bloquent ou expirent ?

Les opérations inter‑frontière peuvent être ralenties par la numérisation côté Windows, l’indexation, le verrouillage de fichiers, ou simplement la surcharge de traduction des opérations. Si c’est rapide sur ext4 et lent sur DrvFS, c’est votre réponse.

8) Puis‑je accéder de manière fiable aux fichiers WSL depuis Windows ?

Généralement oui via \\wsl$ et l’intégration explorer.exe. Pour des charges d’écritures lourdes depuis des applications Windows vers le système de fichiers Linux, testez vos outils spécifiques — certains fonctionnent encore mieux sur NTFS.

9) Pourquoi un renommage ne changeant que la casse se comporte‑t‑il étrangement ?

Windows est souvent insensible à la casse par défaut ; Linux est sensible à la casse. Si votre montage est case=off, les différences uniquement de casse peuvent perturber les outils. Gardez ces dépôts sur ext4.

10) Que faire si la sécurité d’entreprise bloque WSL pour écrire dans certains dossiers ?

Ne jouez pas à la taupe. Utilisez un répertoire workspace approuvé, gardez les dépôts sur ext4, et demandez des changements de politique par la voie appropriée avec un repro minimal et une justification métier.

Conclusion : étapes suivantes qui ne gaspillent pas votre semaine

Si WSL2 n’arrive pas à accéder aux fichiers Windows, arrêtez de deviner et suivez la chaîne de responsabilité :

1. Confirmez le montage existe et est DrvFS avec les options que vous pensez avoir.
2. Reproduisez avec un écrit minimal pour séparer les problèmes de montage des problèmes de politique/ACL Windows.
3. Décidez où vit la charge : système de fichiers Linux pour les charges « Linux‑y » ; NTFS uniquement quand les outils Windows en ont vraiment besoin.
4. Standardisez la configuration (wsl.conf + procédure de redémarrage) pour que les corrections ne disparaissent pas après des mises à jour ou des redémarrages.

La « correction » la plus fiable est souvent architecturale : mettez vos arbres de développement à évolution rapide sur ext4, traitez /mnt/c comme une frontière d’intégration, et réservez l’ajustement des permissions aux cas qui le nécessitent réellement. Cette approche est peu glamour. Elle fonctionne aussi.