WSL umask, fmask и dmask для дисков Windows: настройка прав

Чем отличаются umask, fmask и dmask в WSL

В WSL эти параметры относятся к Windows-дискам, которые DrvFs показывает как /mnt/c, /mnt/d и так далее. umask задаёт общую маску, fmask добавляет ограничения только для файлов, а dmask — только для каталогов. Microsoft указывает, что маски объединяются логическим OR: итоговое ограничение может быть строже, если одновременно заданы umask и отдельная маска для файлов или каталогов. Например, umask=022 уже убирает запись для группы и остальных, а fmask способен дополнительно убрать биты у файлов. Это не то же самое, что chmod после создания объекта: маски участвуют в расчёте представляемых прав DrvFs. Критичная деталь: Microsoft указывает, что umask, fmask и dmask применяются только тогда, когда Windows-диск смонтирован с metadata; без metadata эти маски не дают ожидаемого управления Linux mode bits. Для проектов с git, npm, SSH-ключами или shell-скриптами сначала решите, нужны ли именно Linux-метаданные на Windows-разделе, а уже потом подбирайте маску.

Совет: Если цель — нормальная работа Linux-инструментов, хранить проект внутри файловой системы WSL обычно проще, чем усложнять права на /mnt/c.

Как задать маски в /etc/wsl.conf

1. Откройте конфигурацию: Внутри дистрибутива откройте /etc/wsl.conf от root, например через sudo nano /etc/wsl.conf.
2. Добавьте automount: Создайте [automount] и options="metadata,umask=022,fmask=011,dmask=000" как пример, затем подберите значения под свою модель доступа.
3. Сохраните без лишнего расширения: Убедитесь, что файл называется именно /etc/wsl.conf и синтаксис секций INI не повреждён.
4. Полностью остановите WSL: В PowerShell выполните wsl --shutdown; простого закрытия окна терминала недостаточно.
5. Проверьте после запуска: Создайте тестовые файл и каталог на /mnt/c, затем проверьте mount, stat и ls -l.

Почему chmod на /mnt/c ведёт себя не как на ext4

Windows NTFS и Linux-права используют разные модели. WSL может хранить дополнительную информацию о владельце и mode bits в расширенных атрибутах NTFS, когда для DrvFs включён metadata. Без него права, которые показывает Linux, рассчитываются из разрешений Windows и параметров монтирования, поэтому chmod способен дать неожиданный результат. Даже с metadata Windows ACL продолжают действовать со стороны Windows. Это особенно важно для SSH-ключей и других файлов, где Linux-программы требуют строгий режим. Если файл должен гарантированно подчиняться обычной Linux-модели, храните его в домашнем каталоге дистрибутива, например ~/.ssh или ~/project. Для кода это часто ещё и быстрее по файловым операциям, чем работа через /mnt/c. Не пытайтесь лечить проблему разрешений 0777: сначала определите, на каком уровне — Linux mode bits или Windows ACL — появляется отказ.

Предупреждение: Перед изменениями сохраните текущий wsl.conf. Неверная маска способна неожиданно закрыть доступ инструментам сборки.

Какие маски подходят для типовых задач

• Обычная домашняя работа. umask=022. Владелец пишет, группа и остальные в основном читают
• Закрыть доступ другим пользователям. umask=077. Права в Linux-представлении остаются в основном владельцу
• Отдельно ограничить файлы. fmask=011. Добавочная маска только для файлов
• Отдельно ограничить каталоги. dmask=000. Не добавляет ограничений каталогам поверх umask

Как проверить, что параметры реально применились

После изменения создавайте новый тестовый файл и каталог, а не судите только по старым объектам. Уже существующий файл с metadata может сохранять собственные UID, GID и mode bits. Выполните mount | grep drvfs, stat и ls -l, затем сравните результат с ожидаемой маской. Если поведение отличается, временно верните прежние options, сделайте wsl --shutdown и повторите тест. Такой A/B-подход отделяет эффект конфигурации от прав конкретного файла. Помните, что .wslconfig и wsl.conf — разные уровни: первый задаёт глобальные параметры WSL 2, второй — настройки конкретного дистрибутива. Маски DrvFs относятся именно к wsl.conf или fstab. Для командной среды зафиксируйте выбранные параметры в документации проекта, чтобы другой разработчик не получил другой набор прав на том же Windows-диске.

Что проверить, если права не изменились

• Выполнен wsl --shutdown, а не только закрыт терминал
• Проверяется тот дистрибутив, где изменён /etc/wsl.conf
• Диск смонтирован через DrvFs
• В options нет конфликтующих значений
• metadata включён, если нужен chmod/uid/gid
• Для одного диска рассмотрен /etc/fstab

Важно: Не ставьте 0777 «для исправления доступа»: это маскирует причину и может открыть файлы другим локальным пользователям.

Когда лучше использовать /etc/fstab

Секция [automount] удобна, когда одинаковые правила нужны всем фиксированным Windows-дискам. Но если C: должен оставаться с обычными параметрами, а отдельный D: используется как рабочий том с metadata и другой маской, Microsoft рекомендует задавать специфические параметры через /etc/fstab. Это уменьшает побочные эффекты: системные пути на /mnt/c не меняют поведение, а отдельный рабочий диск получает собственные опции. После изменения fstab всё равно полезно полностью перезапустить WSL и убедиться, что нужная запись смонтирована ожидаемо. Не смешивайте диагностику Windows ACL и Linux mode bits: если Windows сама запрещает учётной записи доступ к файлу, Linux-маска внутри WSL не превратит этот запрет в разрешение. Для одного проблемного каталога иногда рациональнее перенести проект внутрь файловой системы WSL, чем усложнять правила всего диска.

Почему сначала нужно проверить metadata, а не менять цифры маски

Если после изменения umask права выглядят так же, не перебирайте 022, 027 и 077 вслепую. Сначала посмотрите фактические параметры mount: наличие metadata принципиально, потому что без него Microsoft не обещает работу umask/fmask/dmask для DrvFs. Затем создайте новый файл и каталог и сравните stat. Такой порядок отделяет неверно применённую конфигурацию от неверно выбранной маски и не заставляет ослаблять разрешения ради случайного результата.

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

Windows NTFS и Linux-права используют разные модели. WSL может хранить дополнительную информацию о владельце и mode bits в расширенных атрибутах NTFS, когда для DrvFs включён metadata. Без него права, которые показывает Linux, рассчитываются из разрешений Windows и параметров монтирования, поэтому chmod способен дать неожиданный результат. Даже с metadata Windows ACL продолжают действовать со стороны Windows. Это особенно важно для SSH-ключей и других файлов, где Linux-программы требуют строгий…

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

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

• Advanced settings configuration in WSL