Не видно файлов в Windows Subsystem for Linux (WSL) — как исправить

Windows Subsystem for Linux (WSL) удобен для запуска команд Linux в Windows, но пользователи иногда сталкиваются с проблемой: файлы или папки, созданные в Windows, не видны внутри WSL (bash.exe), и наоборот. Ниже — понятное объяснение причин и пошаговые способы устранения.

Почему файлы могут не отображаться

Краткая модель: WSL1 и WSL2 работают по-разному. WSL2 использует виртуальную машину с отдельной ext4-файловой системой. Windows хранит файлы в NTFS. Редактирование файлов Windows-программами внутри внутренней ext4-файловой системы дистрибутива не рекомендуется — это может приводить к несинхронизации, повреждению или тому, что одна сторона не видит изменения другой.

Важно: если вы создаёте файл прямо в Windows в папке, которая ссылается на файловую систему дистрибутива (через \wsl$), он должен появиться в WSL. Но если вы работаете в разных областях (например, Linux-дистрибутив vs C:\Users), поведение зависит от того, где именно вы создаёте файлы.

Быстрая инструкция — что делать

1) Обновите Windows и WSL

• Откройте winver, чтобы узнать сборку Windows. Установите все обновления через Параметры → Обновление и безопасность.
• Обновите подсистему WSL командой (в PowerShell с правами администратора):

wsl --update
wsl --set-default-version 2

Перезапустите систему, если потребуется.

2) Где хранить файлы — правило простое

• Если вы собираетесь редактировать файлы Windows-приложениями (Notepad, VS Code в режиме Windows и т. п.), храните их в файловой системе Windows, например: /mnt/c/Users/Имя/Документы.
• Если вы используете Linux-инструменты (make, gcc, apt-утилиты, сервисы), храните файлы в файловой системе дистрибутива (например, /home/youruser) и обращайтесь к ним из Linux-среды.

Правило: не редактируйте одновременно одни и те же файлы из Windows и из WSL внутри внутренней ext4-системы дистрибутива — это источник проблем.

3) Как правильно открыть папку в Проводнике и в WSL

• Открыв WSL, выполните:

explorer.exe .

Это откроет текущую директорию WSL в Проводнике через \wsl$\DistroName…

• Из Windows вы можете открыть файловую систему дистрибутива в Проводнике по адресу:

\\wsl$\\home\

Если вы создали папку в Проводнике в обычной Windows-папке (например, C:\Users…), откройте её в WSL как /mnt/c/Users/…

4) Перезапуск WSL при подозрении на кэш/несоответствие

Если изменения не видны сразу, выполните в PowerShell:

wsl --shutdown

Затем запустите свою дистрибуцию снова. Это перезапустит подсистему и сбросит внутренние кэши.

5) Проверка прав и владельца

В WSL проверьте права:

ls -la /mnt/c/Users/ВашеИмя/Папка

Обычно Windows-файлы отображаются с mapping-правами. В редких случаях антивирус или политики безопасности Windows могут блокировать доступ — временно отключите защиту (только для диагностики) или проверьте журнал событий.

Подробный пошаговый метод диагностики (мини-методология)

1. Определите, где создаётся файл: в NTFS (C:…) или в файловой системе дистрибутива (/home…).
2. Убедитесь, что вы используете последнюю версию WSL (wsl –update).
3. Попробуйте открыть папку из WSL в Проводнике (explorer.exe .) и из Windows через \wsl$.
4. Выполните wsl –shutdown и повторно проверьте. Если проблема сохраняется — запишите точную последовательность действий для воспроизведения.
5. Проверьте влияние антивируса/политик безопасности и временно отключите для теста.

Альтернативные подходы

• Использовать WSL2 и Docker Desktop: разворачивайте Linux-сервисы внутри контейнеров, а файлы храните в согласованном месте /mnt или через Docker volume.
• Использовать полноценную VM (Hyper-V, VirtualBox) если нужна полная изоляция и предсказуемое поведение файловых систем.
• Хостить продакшен-сервисы в Azure или на серверах Linux вместо WSL — Microsoft не рекомендует размещать критичные продакшен-сервисы прямо в WSL.

Когда предложенные шаги не помогут — частые причины (контрпримеры)

• Вы используете очень старую сборку Windows/WSL, где известные баги ещё не исправлены.
• Вы редактируете файлы внутри ext4 дистрибутива с помощью Windows-приложений, что может привести к незаметным повреждениям или несинхронизации.
• Сторонний софт (антивирус, файловые фильтры, облачные синхронизаторы) препятствует обновлению/видимости файлов.

Проверочные тесты и критерии приёмки

Критерии приёмки:

• Файл, созданный в Проводнике в C:\Users должен отображаться в WSL под /mnt/c/Users.
• Файл, созданный в WSL в /home/user должен быть доступен из Проводника по \wsl$\DistroName\home\user.
• После wsl –shutdown и перезапуска поведение повторяемо.

Тесты:

• Создайте файл через Проводник, затем в WSL выполните ls /mnt/c/… — файл виден.
• Создайте файл в WSL в /home и откройте \wsl$\DistroName\home\user в Проводнике — файл виден.

Роль-based checklist (разработчик / администратор)

Разработчик:

• Хранить исходники в /mnt/c/ для работы с Windows-редакторами.
• Запускать Linux-сборки в WSL, но не редактировать артефакты VM через Windows.

Системный администратор:

• Обновить WSL и Windows.
• Проверить политику безопасности и журналы.
• При необходимости перезапустить службу через wsl –shutdown.

Быстрые подсказки (cheat sheet)

• Открыть текущую WSL-папку в Проводнике: explorer.exe .
• Перезапустить WSL: wsl –shutdown
• Обновить WSL: wsl –update
• Узнать версию Windows: winver

Заключение

Проблема «не видно файлов в WSL» обычно решается пониманием, где именно хранятся файлы (NTFS vs ext4), обновлением Windows/WSL и корректным размещением файлов для используемых инструментов. Используйте /mnt/c для Windows-редакторов и /home для Linux-инструментов, применяйте \wsl$ для доступа из Проводника и перезапускайте подсистему через wsl –shutdown при подозрении на кэширование.

Важно: не используйте WSL как замену полноценного Linux-сервера для продакшена — для этого подходят Azure, Hyper-V или Docker.

Если наши рекомендации помогли — напишите, как вы используете WSL и какие инструменты предпочитаете. Если нет — опишите последовательность действий и результаты команд, чтобы мы могли помочь точнее.