WSL mountFsTab: как управлять обработкой /etc/fstab

За что отвечает mountFsTab в WSL

Параметр mountFsTab находится в секции [automount] файла /etc/wsl.conf и определяет, будет ли WSL обрабатывать /etc/fstab при запуске дистрибутива. По умолчанию значение true: записи fstab могут автоматически подключать дополнительные файловые системы, например сетевую SMB-шару или другой заранее описанный ресурс. Это отдельный механизм от обычного автомонтирования дисков Windows C: и D: через DrvFs. Поэтому ситуация «я отключил automount, а запись из fstab всё равно подключилась» возможна, если mountFsTab оставлен включённым. И наоборот, C: может появляться под /mnt/c даже при пустом fstab, потому что за него отвечает enabled=true. Понимание этой развилки важно перед диагностикой: если ломается стандартный Windows-диск, смотрите параметры automount; если не подключается ресурс из /etc/fstab, сначала проверьте mountFsTab и саму запись fstab.

Совет: Не редактируйте fstab, пока не определили, какой механизм создаёт проблемное монтирование: DrvFs automount или processing /etc/fstab.

Как включить или отключить обработку /etc/fstab

1. Откройте /etc/wsl.conf внутри нужного дистрибутива. Если секции [automount] нет, добавьте её. Для обычного поведения используйте mountFsTab=true; чтобы WSL не обрабатывал /etc/fstab при старте, задайте mountFsTab=false.
2. Не меняйте параметр enabled без необходимости. enabled=false отключает автоматическое подключение фиксированных Windows-дисков, но Microsoft отдельно указывает, что их всё ещё можно подключать вручную или через fstab. Это другая настройка и другой эффект.
3. После сохранения полностью остановите WSL командой wsl --shutdown из PowerShell. Затем снова запустите дистрибутив. Простое закрытие окна терминала не всегда означает остановку всей WSL-среды, поэтому для проверки конфигурации лучше использовать явное завершение.
4. Проверьте результат командами mount, findmnt или просмотром ожидаемой точки монтирования. Если mountFsTab=true, а ресурс не появился, проблема уже не в переключателе: проверяйте синтаксис /etc/fstab, существование точки монтирования, сеть, учётные данные и доступность самого ресурса.

Предупреждение: Перед экспериментами сохраните копию /etc/fstab. Ошибочная запись может усложнить запуск сервисов, которые ожидают этот ресурс.

Чем отличаются enabled и mountFsTab

• enabled=true. автомонтировать фиксированные Windows-диски через DrvFs. C: → /mnt/c
• enabled=false. не автомонтировать фиксированные диски. C: сам не появляется через стандартный automount
• mountFsTab=true. обрабатывать /etc/fstab при старте. ресурсы из fstab могут подключаться автоматически
• mountFsTab=false. не обрабатывать /etc/fstab при старте. записи fstab остаются, но WSL их не применяет автоматически

Почему mountFsTab=true не гарантирует успешное монтирование

Параметр только разрешает WSL обработать файл; он не делает неправильную запись правильной. Для локального пути должна существовать точка монтирования и быть доступен источник. Для SMB-ресурса важны сеть, имя сервера, пакет поддержки нужного типа файловой системы, корректные credentials и права. Если ресурс зависит от VPN, он может быть недоступен в момент запуска дистрибутива, а позднее появиться. В таком случае автоматическая попытка стартует слишком рано. Ещё одна частая ошибка — тестировать команду mount вручную с одними параметрами, а в fstab оставить старую строку с другими опциями. Сначала добейтесь успешного ручного монтирования тем же набором параметров, затем переносите конфигурацию в fstab. Для диагностики полезно запускать mount -a вручную: так вы проверяете сами записи отдельно от факта старта WSL и быстрее видите ошибку.

Важно: mountFsTab=true означает «прочитать fstab», а не «гарантировать доступность каждого ресурса».

Когда имеет смысл временно поставить mountFsTab=false

Отключение полезно как диагностический переключатель. Если после редактирования /etc/fstab при запуске появляются задержки, ошибки или неожиданные точки монтирования, mountFsTab=false позволяет проверить, исчезает ли симптом без удаления самих записей. Это безопаснее, чем хаотично комментировать несколько строк одновременно: вы сначала разделяете проблему на «обработка fstab» и «остальная конфигурация WSL». После этого возвращайте true и включайте записи по одной. Ещё один сценарий — дистрибутив, где все внешние ресурсы подключаются отдельным скриптом после VPN или интерактивной авторизации. Там автоматическая обработка fstab может быть нежелательной. Но для обычной системы оставлять false без причины неудобно: вы теряете ожидаемое автоматическое монтирование и потом вынуждены объяснять каждому скрипту, почему каталог существует, но ресурс в него не подключён.

Совет: Используйте false как контролируемую диагностику, а не как универсальный способ скрыть ошибку в fstab.

Чек-лист, если запись из fstab не монтируется

• Проверьте /etc/wsl.conf: секция [automount] должна содержать mountFsTab=true либо не переопределять значение по умолчанию.
• Выполните wsl --shutdown после изменения конфигурации и запустите дистрибутив заново, чтобы исключить проверку на старом экземпляре.
• Запустите sudo mount -a и прочитайте конкретную ошибку. Это отделяет проблему самой записи fstab от механизма автозапуска WSL.
• Убедитесь, что точка монтирования существует, источник доступен, тип файловой системы поддерживается, а для сетевого ресурса сеть или VPN уже подняты.
• Сравните фактическую строку в /etc/fstab с той ручной командой mount, которая точно работает. Не меняйте сразу несколько опций: иначе вы потеряете причину успеха или отказа.

Как вернуть конфигурацию к предсказуемому состоянию

Если эксперимент не помог, верните минимальный вариант: [automount] с mountFsTab=true и без лишних переопределений, затем остановите WSL и запустите его снова. После старта проверьте стандартные Windows-диски и только затем ресурсы fstab. Такой порядок важен: он показывает, исправна ли базовая интеграция DrvFs до подключения сетевых или нестандартных файловых систем. Если fstab нужен для одного ресурса, временно оставьте одну проверенную запись вместо большого набора. Когда она стабильно монтируется после чистого запуска, возвращайте остальные. Для автоматизации не полагайтесь только на наличие каталога: скрипт должен проверять, что это действительно смонтированная файловая система, например через findmnt. Иначе команда может записать данные в пустую локальную директорию, а после успешного монтирования эти файлы окажутся скрыты под точкой монтирования — неприятная и трудно заметная ошибка.

Учитывайте, что wsl.conf действует отдельно для каждого дистрибутива

Если установлено несколько дистрибутивов, настройка mountFsTab в Ubuntu не меняет поведение Debian и наоборот. Это особенно важно при автоматизации: одинаковый /etc/fstab может существовать в двух системах, но обрабатываться по-разному из-за разных /etc/wsl.conf. Перед диагностикой выполните wsl -l -v в Windows и убедитесь, какой дистрибутив вы открываете. Затем проверяйте конфигурацию именно внутри него. Такой простой контроль убирает типичную путаницу, когда пользователь редактирует один экземпляр, а тестирует другой.

Что учитывать

Параметр только разрешает WSL обработать файл; он не делает неправильную запись правильной. Для локального пути должна существовать точка монтирования и быть доступен источник. Для SMB-ресурса важны сеть, имя сервера, пакет поддержки нужного типа файловой системы, корректные credentials и права. Если ресурс зависит от VPN, он может быть недоступен в момент запуска дистрибутива, а позднее появиться. В таком случае автоматическая попытка стартует слишком рано. Ещё одна частая ошибка — тестировать…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Advanced settings configuration in WSL). Пример и формулировки — редакция N1RO на 2026-09-21.

• Advanced settings configuration in WSL