WSL2 не може отримати доступ до файлів Windows? Монтування та дозволи, що мають значення

Ментальна модель: що насправді робить WSL2

WSL2 — це не «Linux, що працює на Windows» у тому теплом, умовному сенсі, який зазвичай мають на увазі. Це справжнє ядро Linux, що працює в легкому VM (на базі Hyper-V), а Windows надає інтеграційні труби. Саме ці труби — те, з чим ви сперечаєтеся, коли файли Windows «зникають» або дозволи здаються проклятими.

Всередині WSL2 зазвичай є два класи сховищ:

• Файлова система Linux (ext4 всередині VHDX) для вашої дистрибуції, що знаходиться під /. Це швидко і поводиться так, як очікує Linux.
• Файли Windows, відкриті для Linux через монти DrvFS, зазвичай під /mnt/c, /mnt/d тощо. Це шар сумісності, який відображає семантику NTFS в те, що може використовувати Linux.

Ця трансляція — джерело більшості непорозумінь. Дозволи Linux — це прості бітові прапори плюс власність. Дозволи Windows — це ACL, правила успадкування, deny-записи та «залежить від» вбудоване в ОС. DrvFS намагається представити об’єкти Windows як файли Linux. Іноді вдається. Іноді воно люб’язно брешуть.

Операційно вам слід обрати своє поле бою:

• Якщо ви компілюєте, індексуєте або виконуєте багато операцій з дрібними файлами: тримайте репозиторій у файловій системі Linux (~/src) і доступайтеся до нього з Windows через \\wsl$.
• Якщо ви мусите зберігати файли на NTFS: ставтеся до /mnt/c як до мережевої файлової системи з особливостями. Налаштовуйте опції монтування. Уникайте покладання на chmod/chown, якщо не ввімкнули metadata.

Цитата для SRE-розуму: Надія — не стратегія. — General Gordon R. Sullivan. У файлових системах «сподіваюсь, змонтується, як минулого разу» — це те, як ви опиняєтесь за дебагом о 2 годині ночі.

Короткий жарт №1: DrvFS — як перекладач у гучному барі — здебільшого точний, інколи вигадує значення, завжди переконаний, що допомагає.

Цікаві факти та історія (бо деталі важливі)

• WSL1 і WSL2 — різні звірі. WSL1 транслював системні виклики Linux у внутрішні механізми NT; WSL2 запускає реальне ядро Linux у VM.
• DrvFS передує WSL2. Ідея монтування дисків Windows існувала в WSL1, але реалізація і характеристики продуктивності змінилися через межу VM.
• Чутливість до регістру символів не універсальна в Windows. NTFS може зберігати регістр і опціонально бути чутливим до регістру для окремих директорій; історично Win32 API вважали шляхи нечутливими за замовчуванням.
• Дозволи NTFS базуються на ACL. Бітові режими Linux — це спрощення, що не відображає deny-правила, успадкування чи множинних суб’єктів коректно.
• Сховище WSL2 живе у VHDX. Коренева файлова система вашої дистрибуції знаходиться у віртуальному диску; перенести її між машинами або створити резервну копію можливо, але потребує уваги.
• Індексація Windows та антивірус важливі. Доступ до багатьох файлів на NTFS з WSL2 може запускати сканування на боці Windows, що виглядає як «Linux повільний», поки Windows виконує роботу.
• Ідеї з 9P і Plan 9 з’являються в екосистемі. Деякі механізми обміну файлами між ОС позичають концепції від протоколів віддалених файлових систем; операції через межі завжди мають витрати.
• Відображення дозволів можна налаштувати. Опції монтування DrvFS, як-от metadata, uid, gid, umask та fmask, змінюють те, що Linux бачить.

Швидка діагностика: знайти вузьке місце за кілька хвилин

Коли «WSL2 не може отримати доступ до файлів Windows», ваше завдання — відокремити: проблема монтування, проблема дозволів, проблема шляху/інтероперабельності або продуктивність/таймаути. Ось найшвидший шлях, який я знаходив, що не перетворюється на забобони.

Перш за все: диск змонтований так, як ви думаєте?

• Перевірте mount і шукайте type drvfs на /mnt/c (або вашому корені для монтування).
• Якщо монт відсутній або неправильний, виправте automount або /etc/fstab перед тим, як торкатися дозволів.

По-друге: це помилка Linux-дозволів чи NTFS ACL?

• Спробуйте створити/записати як ваш Linux-користувач у відомій теці на C: (наприклад, ваш профіль користувача Windows).
• Якщо читати можна, а записувати — ні, це майже завжди NTFS ACL або корпоративна політика (EDR, controlled folder access), а не «chmod».

По-третє: чи це проблема продуктивності, замаскована під «неможливо отримати доступ»?

• Якщо інструменти таймаутяться, зависають або поводяться нестабільно на /mnt/c, відтворіть ту саму операцію під ~ (ext4). Якщо там швидко, ви бачите накладні витрати межі Windows.
• У сумнівних випадках: перемістіть навантаження в файлову систему Linux і відкрийте її для Windows через \\wsl$.

По-четверте: перевірте «підводні камені» кросплатформенності

• Конфлікти чутливості до регістру, недопустимі символи у іменах файлів, поведінка симлінків і інструменти для кінцевих рядків можуть робити «доступ» схожим на зламаний.
• Підтвердіть, що ви не записуєте файли з іменами, які Windows не може представити, і не очікуєте їхньої коректної поведінки на NTFS.

Монти, що мають значення: DrvFS, VolFs і де справжньо зберігаються бітки

Більшість людей вивчають один шлях: /mnt/c. Потім вони припускають, що це «просто папка». Ні. Це змонтована файлова система типу drvfs, і її опції монтування вирішують усе — від видимих дозволів до того, чи взагалі chmod щось робить.

Точки монтування DrvFS: /mnt/c — це політичний вибір

За замовчуванням WSL автоматично монтує фіксовані диски під /mnt/<буква_диска>. Цю поведінку можна змінити в /etc/wsl.conf. Така зміна також може зламати скрипти, CI-кроки або м’язову пам’ять розробника — тож ставтеся до цього як до зміни API.

Файлова система Linux всередині WSL2: ваша реальна зона продуктивності

Всередині VM WSL2 коренева файлова система дистрибуції — ext4 (зазвичай) — і поводиться як нормальна Linux-машина. Якщо ваше навантаження «linux‑підобне» (node_modules, Rust build, Python venv, git-операції), тримання його на ext4 — різниця між «працює» і «мій ноутбук — обігрівач».

Де монти йдуть не так

Поширені режими відмов монтування, які я бачив у виробничих флотах розробників:

• Automount вимкнений: немає /mnt/c або з’являються лише деякі диски.
• Зміна букви диска: змінні носії, стани розблокування BitLocker або політики управління дисками в компанії змінюють букви.
• Помилки у fstab: некоректний запис може завадити очікуваним монтам і залишити вас відлагоджувати «дозволи», коли файлова система взагалі не там.
• Мережеві шляхи: монтування мережевих дисків Windows — не те саме, що локальний NTFS. Може знадобитися інший підхід (і інші очікування).

Опції монтування, які справді змінюють поведінку

Опції монтування — це те, де ви вирішуєте, чи є дозволи Linux «справжніми» (metadata) або «спроєктованими» (на основі масок). Операційна істина:

• Без metadata: chmod/chown зазвичай не зберігаються, бо нема місця для POSIX-власності на простих файлах NTFS, як їх представляє DrvFS.
• З metadata: WSL зберігає додаткові метадані (уявіть «розширені атрибути») для збереження Linux mode bits та відображення власності. Це робить Linux-інструменти щасливішими, але може здивувати Windows-інструменти та інші машини.
• uid/gid/umask/fmask/dmask: корисні, коли ви хочете послідовної власності та режимів для всього на цьому монтировании, особливо без metadata.

Немає універсально «правильного» набору опцій. Є лише «правильне для того, що ви запускаєте», і «правильне для очікувань вашої команди». Оберіть один і стандартизуйте його.

Дозволи, що мають значення: NTFS ACL проти Linux mode bits

Коли Linux каже «permission denied», це означає, що системний виклик зазнав невдачі. Це не обов’язково означає, що бітові режими Linux неправильні. Може бути:

• Windows ACL забороняє дію (явно або через успадковану політику).
• Windows «controlled folder access» блокує запис у захищені директорії.
• EDR/антивірус перехоплює або затримує доступ до файлу до таймауту.
• Файл заблокований процесом Windows з режимами спільного доступу, що не відповідають очікуванням Linux.

Зрозумійте відображення: хто кому належить?

За замовчуванням DrvFS часто показує файли Windows як належні вашому Linux-користувачу (або інколи як root-зразкоподібні значення залежно від налаштувань) з виглядом дозволів, що здаються дозволяючими. Ці біти не є владою; владою є NTFS ACL.

Якщо ви ввімкнете metadata, власність і бітові режими Linux можуть стати більш вагомими усередині WSL. Але Windows-застосунки все одно застосовуватимуть NTFS ACL і можуть ігнорувати або затирати POSIX-подібні метадані.

Що насправді означає «chmod не працює»

На DrvFS без metadata, chmod — це як кричати на картину: відчуваєш продуктивність, але нічого не змінюється. Правильне виправлення — або:

• Увімкнути metadata, щоб chmod було куди зберігати зміни.
• Припинити покладатися на chmod/chown і керувати доступом через Windows ACL (Explorer, icacls, групові політики).
• Перемістити навантаження до файлової системи Linux, де POSIX-дозволи рідні.

Симлінки: тихий капкан дозволів

Симлінки з Linux на Windows-шляхи та навпаки можуть давати помилки, які виглядають як проблеми з дозволами. Створення симлінків у Windows може вимагати Режиму Розробника або прав адміністратора залежно від політики. Також: симлінк, що резольвиться у Windows-шлях, успадковує поведінку ACL Windows. Ваш Linux-процес не отримує магічних виключень.

Короткий жарт №2: Я бачив, як «виправити дозволи» запускали стільки разів, що це заслуговує на картку лояльності — купи дев’ять chmod, отримай десятий безкоштовно, і все одно зламається.

Практичні дії: команди, виводи та що вирішити далі

Ось реальні дії, які я б виконав на робочому ноутбуку чи робочій станції розробника, коли хтось каже «WSL2 не може доступитися до файлів». Кожне завдання включає: команду, приклад виводу, що це означає і яке рішення прийняти.

Завдання 1: Підтвердити, що ви в WSL2 (не WSL1)

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

Що це означає: рядок ядра, що містить microsoft і WSL2, вказує, що ви запускаєте ядро WSL2.

Рішення: Якщо це WSL1, семантика доступу до файлів і продуктивність інші; скоригуйте очікування і розгляньте оновлення дистрибуції до WSL2.

Завдання 2: Подивитися, що змонтовано і чи C: — це DrvFS

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

Що це означає: /mnt/c змонтовано; опції показують, як поводяться дозволи і обробка регістру символів.

Рішення: Якщо монт відсутній, виправте automount. Якщо опції не підходять (немає metadata, неправильний uid), виправте /etc/wsl.conf або перемонтуйте.

Завдання 3: Перевірити, що шлях існує і це не битий симлінк

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

Що це означає: Записи директорій існують і доступні з точки зору Linux.

Рішення: Якщо ls сам помилка, це проблема монтування/інтероперабельності, а не рівня додатку.

Завдання 4: Відтворити помилку мінімальним тестом запису

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

Що це означає: Linux спробував запис; Windows/DrvFS відхилив.

Рішення: Підозрюйте NTFS ACL, controlled folder access або корпоративний контроль кінцевої точки. Спробуйте запис у менш захищену теки (наприклад, /mnt/c/Users/cr0x), потім виправляйте дозволи/політи на боці Windows або переносіть навантаження.

Завдання 5: Спробувати запис у корінь профілю користувача (часто менш захищено)

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

Що це означає: Записи в цій теці працюють. Раніша помилка залежить від місця/політики.

Рішення: Розміщуйте WSL-записи в доступній теці або змініть налаштування безпеки Windows для заблокованої теки (через команду безпеки, не через локальні хаки).

Завдання 6: Визначити опції монтування, що контролюють проєкцію дозволів

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

Що це означає: Немає опції metadata; власність проєктована через відображення uid/gid.

Рішення: Якщо вам потрібні семантики chmod/chown для інструментів збірки, ввімкніть metadata (і прийміть компроміси) або перенесіть репозиторій у ext4.

Завдання 7: Перевірити поточну конфігурацію automount WSL

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

Що це означає: Automount увімкнено; DrvFS-монти включатимуть metadata і конкретні маски.

Рішення: Якщо enabled встановлено в false або опції відсутні, виправте файл, потім перезапустіть WSL, щоб застосувати.

Завдання 8: Застосувати зміни конфігурації перезапуском WSL (із середовища Linux)

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

Що це означає: Завершує всі екземпляри WSL; при наступному запуску буде прочитано конфіг і змонтуються диски.

Рішення: Робіть це після редагування /etc/wsl.conf або коли монти виглядають застарілими.

Завдання 9: Підтвердити поведінку metadata через chmod на 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

Що це означає: Якщо chmod зберігається і виконавчий біт з’являється, metadata працює (або виконавчі біти проєктуються масками).

Рішення: Якщо виконавчий біт не зберігається, у вас немає metadata (або fmask блокує його). Виправте опції монтування або перестаньте розміщувати виконувані файли на DrvFS.

Завдання 10: Помітити явні блокування Windows, спробувавши перейменувати

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

Що це означає: «Device or resource busy» на DrvFS часто вказує, що Windows має відкритий дескриптор з несумісними прапорами спільного доступу, або антивірус/EDR його утримує.

Рішення: Закрийте Windows-застосунки, що торкаються файлу (редактори, індексатори). Якщо проблема триває, розгляньте виключення шляху (після схвалення політики) або перенесіть навантаження в ext4.

Завдання 11: Порівняти продуктивність: Windows mount проти файлової системи 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

Що це означає: Це велика накладна вартість для дрібних файлових операцій на DrvFS.

Рішення: Якщо ваша збірка робить подібні операції (node, git, pip), припиніть використовувати /mnt/c для репозиторію.

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

Що це означає: ext4 у WSL2 значно швидший для навантажень, що інтенсивно працюють з метаданими.

Рішення: Тримайте репозиторії та артефакти збірки у файловій системі Linux; використовуйте доступ з Windows через \\wsl$, якщо потрібно.

Завдання 12: Підтвердити використання диска дистрибуції (переповнення VHDX може викликати дивні помилки)

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

Що це означає: Файлова система Linux має обмежене вільне місце. Низький простір може перетворити нормальні операції на помилки.

Рішення: Очистіть артефакти збірки, шари docker або кеші. Якщо зайнято 100%, вирішіть це перед тим, як звинувачувати монт.

Завдання 13: Діагностувати очікування власності (хто я, насправді?)

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

Що це означає: Підтверджує uid/gid, корисно, коли опції монтування примушують відображення власності.

Рішення: Якщо монт показує інший uid/gid, ніж ваш користувач, виправте опції монтування або ви постійно будете дивуватись «чому все належить 1001?».

Завдання 14: Підтвердити поведінку чутливості до регістру на монт

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

Що це означає: DrvFS обробляє пошук шляхів нечутливо до регістру символів.

Рішення: Якщо у вас є репозиторії з файлами, що відрізняються тільки регістром, не тримайте їх на /mnt/c. Помістіть їх на ext4, щоб уникнути хаосу між інструментами.

Завдання 15: Підтвердити доступ з Windows до файлів WSL (зворотний напрям)

cr0x@server:~$ explorer.exe .

Що це означає: Відкриває Провідник Windows у поточній директорії Linux через інтеграцію WSL.

Рішення: Якщо Windows не може переглянути або виникає помилка, можливо, є проблеми інтеграції WSL або політика; це впливає на робочі процеси, що очікують доступ інструментів Windows до файлів WSL.

Завдання 16: Перевірити записи fstab, що можуть перевизначати automount

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

Що це означає: Ви явно монтуєте C:. Це перевизначає значення за замовчуванням і може конфліктувати з automount.

Рішення: Якщо щось дивне, спростіть: або використовуйте automount через wsl.conf, або керуйте монтами в fstab — не робіть обидва одночасно, якщо не любите сюрпризи.

Три короткі корпоративні історії з практики

Міні-історія 1: Інцидент через неправильне припущення

Команда продукту стандартизувала підхід «тримати монорепозиторій на C:\, щоб Windows-інструменти працювали, а WSL просто використовував /mnt/c». Звучало розумно. Працювало під час пілоту, коли репозиторій був малим і машини розробників були свіжі.

Потім це розгорнули на кілька десятків інженерів. Часи збірки виросли, тести почали таймаутитися, і кілька збірок почали падати з раптовими помилками «file not found». Перші хвилі дебагу зосередилися на системі збірки. Звісно. Ніхто не хоче визнати, що причина в файловій системі — це ніби звинуватити землю у підкосягуванні.

Фактичний режим відмови: збірка генерувала десятки тисяч дрібних файлів під /mnt/c, що запускало сканування та індексацію на боці Windows. Під навантаженням файлові операції стали настільки повільними, що інструменти влучали у внутрішні таймаути і почали поводитись невизначено. Дехто «вирішив» це, відключивши засоби безпеки, що створило інший інцидент, лише питання часу.

Виправлення було нудним, але ефективним: перемістити активні репозиторії в ext4 WSL (~/src) і доступатися до них з Windows-редакторів через \\wsl$ коли потрібно. Зберегли невеликий Windows-бічний чек-аут лише для робочих процесів, що дійсно потребували рідних Windows-шляхів. Інцидент не був помилкою збірки — це була помилка припущення.

Міні-історія 2: Оптимізація, що дала зворотний ефект

Один інфраструктурний розробник намагався «одного разу й назавжди вирішити дозволи», ввівши metadata на DrvFS по всьому флоту і встановивши пом’якшені umask. Мета: зробити Linux-інструменти більш linux‑подібними, особливо щодо виконуваних файлів і git-хуків.

Розгортання пройшло гладко — поки кілька Windows-агентів бекапу і декілька плагінів IDE не почали реагувати погано. Деякі інструменти інтерпретували додаткові метадані так, що змінили атрибути файлів або викликали повторні сканування. На декількох машинах великі дерева папок почали крутитися: оновлення часових міток, зміни атрибутів і постійні сповіщення про «змінені файли».

Результат не був втратою даних, але був втратою робочого процесу: git status завжди виглядав «брудним», деякі Windows-інструменти сповільнилися, і люди перестали довіряти своїм копіям. Оптимізація «працювала» для Linux‑семантики, але ігнорувала Windows-екосистему, яка також торкалася тих файлів.

Виправлення: припинили шукати універсальну конфігурацію. Обмежили metadata-монти для конкретних директорій проєктів, де потрібні Linux‑семантики, і залишили поведінку DrvFS за замовчуванням в інших місцях. Ще краще: перемістили більшість репозиторіїв в ext4 і трактували /mnt/c як межу інтеграції, а не як дім.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Одна команда з високими вимогами безпеки мала правило: ніяких саморобних змін у налаштуваннях безпеки Windows, щоб «змусити інструменти працювати». Замість цього вони підтримували стандартну теку розробника під профілем користувача з відомими ACL і документували, куди WSL-навантеження має право писати.

Спочатку це дратувало людей. Інженери не люблять, коли їм доводиться слідувати політиці теки, коли вони «просто запускають тести». Але потім оновлення Windows ввело суворішу поведінку для захищених тек, і багато машин почали видавати Permission denied, коли WSL намагався писати на Desktop або Documents.

Команди без політики скотилися в паніку: люди робили локальні винятки, деякі відключали захист, і служба безпеки мусила відновлювати неконсистентні налаштування. Команда з нудною політикою майже не помітила нічого. Їхні робочі процеси вже писали в погоджені теки для scratch/workspace, а репозиторії жили в ext4 WSL.

Практичний урок: ви не перехитрите політику кінцевої точки за допомогою chmod. Можна лише проєктувати робочий процес так, щоб обходитись без цього.

Типові помилки: симптом → корінна причина → виправлення

1) «/mnt/c відсутній»

Симптом: ls /mnt/c повертає «No such file or directory».

Корінна причина: Automount вимкнений у /etc/wsl.conf, WSL не перезапущено або битий запис у /etc/fstab завадив монтуванню.

Виправлення: Увімкніть automount або виправте /etc/fstab; запустіть wsl.exe --shutdown і знову відкрийте середовище.

2) «Permission denied на Desktop/Documents»

Симптом: Записи в теках користувача, що «мають бути вашими», не проходять.

Корінна причина: Windows controlled folder access, корпоративні контролі кінцевої точки або заточені ACL на захищених теках.

Виправлення: Використовуйте відому записувану теку під вашим профілем (або робоче місце, погоджене командою). Якщо політика дозволяє, запросіть виняток через команду безпеки — не робіть випадкових локальних хаки.

3) «chmod +x не зберігається на /mnt/c»

Симптом: Файл залишається невиконуваним після chmod; git-хуки не працюють; скрипти не запускаються.

Корінна причина: DrvFS без metadata, або fmask маскує виконувальні біти.

Виправлення: Увімкніть metadata для цього монту, або тримайте виконувані файли у файловій системі Linux. Відрегулюйте fmask/umask якщо ви проєктуєте дозволи.

4) «Усе належить root»

Симптом: ls -l показує root root або несподівані uid/gid на /mnt/c.

Корінна причина: Опції монтування неправильно відображають власність (відсутні uid/gid), або користувач явно змонтував у /etc/fstab.

Виправлення: Встановіть uid=1000,gid=1000 (або ваші реальні ID) в опціях automount; перезапустіть WSL.

5) «Git status повільний / збірки повзають»

Симптом: Дрібні операції повільні на /mnt/c, але нормальні під ~.

Корінна причина: Накладні витрати на перетин кордонів + сканування/індексація Windows + невідповідність семантики NTFS для навантажень Linux.

Виправлення: Перенесіть репо в ext4 у WSL2. Доступайтеся з Windows через \\wsl$. Тримайте артефакти збірки поза /mnt/c.

6) «Input/output error на /mnt/c»

Симптом: Випадкові I/O помилки при читанні файлів Windows.

Корінна причина: Помилки файлової системи Windows, відключення диска (зовнішні носії) або нестабільні мережеві диски, представлені як букви.

Виправлення: Перевірте здоров’я диска у Windows, уникайте зовнішніх/мережевих дисків для критичних шляхів розробки та перемонтуйте після перепідключення.

7) «Переіменування тільки по регістру не працює»

Симптом: Перейменування Readme.md у README.md поводиться дивно; інструменти не погоджуються.

Корінна причина: Налаштування чутливості до регістру відрізняються; DrvFS може мати case=off.

Виправлення: Тримайте такі репо на ext4 або впровадьте правила іменування, що не залежать від відмінностей тільки в регістрі.

8) «Створення симлінка не вдається»

Симптом: Створення симлінків помилково, або лінки поводяться по-різному по обох боках.

Корінна причина: Політика Windows обмежує створення симлінків; семантика Windows і Linux відрізняється.

Виправлення: Віддавайте перевагу симлінкам на боці Linux в ext4; уникайте крос-граничних симлінків коли можливо; ввімкніть потрібні функції Windows для розробників, якщо це дозволено.

Чеклісти / покроковий план

Чекліст A: «WSL2 не бачить /mnt/c» (відмова на рівні монту)

1. Запустіть mount | grep drvfs і підтвердіть, чи змонтовано C: взагалі.
2. Перевірте /etc/wsl.conf на наявність [automount] і enabled=true.
3. Перевірте /etc/fstab на биті записи DrvFS. Тимчасово закоментуйте підозрілі рядки.
4. Перезапустіть WSL за допомогою wsl.exe --shutdown.
5. Перевірте ще раз за допомогою findmnt /mnt/c. Якщо досі не працює, розглядайте це як проблему інтеграції Windows/WSL, а не Linux-дозволів.

Чекліст B: «Permission denied» (помилка запису)

1. Відтворіть проблему командою touch у тій самій директорії.
2. Спробуйте запис у менш захищений шлях (наприклад, /mnt/c/Users/<you>/wsl_scratch).
3. Якщо там працює — зупиніться. Це не проблема chmod.
4. Прийміть рішення: перенести навантаження в ext4 або виправити Windows ACL/політику для тієї теки.
5. Якщо середовище корпоративне: відкрийте тикет із точним шляхом і мінімальним repro-командами, а не «WSL зламався».

Чекліст C: «chmod/chown не працює» (Linux-інструменти незадоволені)

1. Перевірте опції монтування з findmnt -no OPTIONS /mnt/c.
2. Якщо metadata відсутнє, вирішіть, чи справді вам потрібні POSIX-дозволи на NTFS.
3. Якщо так: увімкніть metadata через /etc/wsl.conf або явний запис у fstab.
4. Перезапустіть WSL.
5. Повторно протестуйте chmod +x і підтвердіть через ls -l.
6. Якщо все ще нестабільно: перенесіть виконувані файли та вихідні файли збірки в ext4. Це доросла відповідь.

Чекліст D: «Усе повільно» (тріаж продуктивності)

1. Пропустіть бенчмарк навантаження з дрібними файлами на /mnt/c і порівняйте з ~ (як у прикладах вище).
2. Якщо /mnt/c значно повільніший, припиніть намагатись вирішити це випадковими прапорами.
3. Перенесіть репо в ext4. Використовуйте інструменти Windows через \\wsl$ або explorer.exe .
4. Тримайте лише «має бути на NTFS» ресурси на /mnt/c (великі медіафайли, спільні теки для Windows‑тільки інструментів).
5. Повторіть бенчмарк, щоб підтвердити виправлення; документуйте його для наступного інженера.

FAQ

1) Чому WSL2 інколи показує дивні дозволи на /mnt/c?

Тому що DrvFS відображає NTFS ACL у POSIX-подібний вигляд. Без metadata бітові режими — це переважно проєкція, керована опціями монтування, а не авторитетна правда.

2) Де зберігати git-репозиторій: на /mnt/c чи у файловій системі Linux?

Тримайте активні репозиторії у файловій системі Linux (ext4), якщо немає сильної вимоги до рідного Windows. Зазвичай збірки, пакетні менеджери і git там швидші й надійніші.

3) Якщо chmod не працює на /mnt/c, чи зламався WSL?

Ні. Це очікувана поведінка без metadata. Або ввімкніть metadata (з компромісами), або не покладайтеся на chmod на DrvFS-монтах.

4) Чому я можу читати файл Windows, але не записувати його з WSL2?

Читання часто дозволене ширше, тоді як запис може блокуватися NTFS ACL, захищеними теками, controlled folder access або інструментами безпеки кінцевої точки.

5) Який найчистіший спосіб застосувати зміни wsl.conf для монту?

Відредагуйте /etc/wsl.conf, потім перезапустіть WSL за допомогою wsl.exe --shutdown. Простий вихід з дистрибуції не завжди надійно перевстановлює automount.

6) Чи завжди корисно вмикати metadata?

Ні. Воно покращує Linux‑семантику на NTFS, але може здивувати Windows‑інструменти і створити неконсистентність, якщо кілька середовищ торкаються тієї самої ієрархії. Використовуйте цілеспрямовано, лише там, де потрібно.

7) Чому деякі операції на /mnt/c зависають або таймаутяться?

Операції через межу файлових систем можуть уповільнюватися скануванням на боці Windows, індексацією, блокуванням файлів або просто накладними витратами трансляції. Якщо на ext4 швидко, а на DrvFS повільно — відповідь очевидна.

8) Чи можна надійно отримати доступ до файлів WSL з Windows?

Загалом так, через \\wsl$ і інтеграцію explorer.exe. Для інтенсивних записів з Windows у файлову систему Linux тестуйте конкретні інструменти — деякі досі поводяться краще на NTFS.

9) Чому перейменування тільки по регістру поводиться дивно?

Windows зазвичай нечутливий до регістру за замовчуванням; Linux чутливий. Якщо ваш монт має case=off, відмінності тільки в регістрі можуть плутати інструменти. Тримайте такі репо на ext4.

10) Що робити, якщо корпоративна безпека блокує WSL-записи у певні теки?

Не займайтесь whack-a-mole. Використовуйте погоджену робочу теку, тримайте репозиторії в ext4 і подавайте запит на зміну політики через офіційний канал з мінімальним repro і бізнес-обґрунтуванням.

Висновок: подальші кроки, які не витратять вам тиждень

Якщо WSL2 не може доступитися до файлів Windows, припиніть гадати і дотримуйтесь ланцюга відповідальності:

1. Підтвердіть монту, що він існує і має тип DrvFS з очікуваними опціями.
2. Відтворіть мінімальний запис, щоб відокремити проблему монту від політик/ACL Windows.
3. Прийміть рішення, де житиме навантаження: файлова система Linux для Linux‑навантажень; NTFS тільки якщо інструменти Windows дійсно потребують цього.
4. Стандартизируйте конфігурацію (wsl.conf + процедура перезапуску), щоб виправлення не зникали після оновлень або перезавантажень.

Найнадійніше «виправлення» часто архітектурне: тримайте швидкозмінні дерева розробки в ext4, трактуйте /mnt/c як межу інтеграції й залишайте налаштування дозволів для випадків, де вони справді потрібні. Цей підхід нудний, зате діє.