前言

WSL ( Windows Subsystem for Linux ) 通过/mnt目录下的cde等目录可分别访问本地的C、D、E等盘,虽然可以直接访问 Windows 下的文件内容,但输入ls -al查看文件你会发现文件权限全都是777。这会导致一些问题出现,比如 Git 会保留这些文件的执行权限,如果你之前在 Windows 下使用过 Git Bash ,那么在 WSL 中使用git status查看本地仓库的文件状态时你会发现它们全部被标记成了modified

分析问题

首先要了解 WSL 中的两种文件系统

  • VolFs

    着力于在 Windows 文件系统上提供完整的 Linux 文件系统特性,通过各种手段实现了对 Inodes、Directory entries、File objects、File descriptors、Special file types 的支持。比如为了支持 Windows 上没有的 Inodes,VolFs 会把文件权限等信息保存在文件的 NTFS Extended Attributes 中。

    WSL 中的 / 使用的就是 VolFs 文件系统。

  • DrvFs

    着力于提供与 Windows 文件系统的互操作性。与 VolFs 不同,为了提供最大的互操作性,DrvFs 不会在文件的 NTFS Extended Attributes 中储存附加信息,而是从 Windows 的文件权限(Access Control Lists,就是你右键文件 > 属性 > 安全选项卡中的那些权限配置)推断出该文件对应的的 Linux 文件权限。

    所有 Windows 盘符挂载至 WSL 下的 /mnt 时都是使用的 DrvFs 文件系统。

简单来说就是 WSL 对/目录下的文件拥有完整的控制权,而/mnt目录中的文件无法被 WSL 完全控制(可修改数据,无法真实的修改权限)。WSL 对/mnt目录中权限的修改不会直接记录到文件本身,而在 Windows 下对文件权限的修改直接可作用到 WSL 。关于权限在微软开发者博客中有更详细的说明

解决方案

这只是让文件在 WSL 中的权限看起来正常(目录755,文件644),实际并不会作用到 Windows 文件系统下的文件本身。

/etc/wsl.conf中添加以下配置:

[automount]
enabled = true
root = /mnt/
options = "metadata,umask=22,fmask=111"
mountFsTab = true

由于enabledrootmountFsTab均为默认值,可以对其进行精简:

[automount]
options = "metadata,umask=22,fmask=111"

上面的方法对所有盘符都有效,如果你想在 WSL 中调用 Windows 下的应用程序(比如explorer.exe .调用资源管理器打开当前路径)就需要对C盘进行单独设置,否则会提示没有权限。首先确认wsl.conf中的mountFsTab没有被设置为false,然后编辑/etc/fstab,添加如下内容:

C:\ /mnt/c drvfs rw,noatime,uid=1000,gid=1000,metadata,umask=22,fmask=11 0 0

此时以为所有问题都解决了,但用mkdir命令新建一个目录,会发现新建的目录权限依然是777

目前民间解决方案是在.profile.bashrc.zshrc或者其他 shell 配置文件中添加如下命令,重新设置 umask

# Fixing Bad Default Permissions
if [ "$(umask)" = "000" ]; then
  umask 022
fi

未来官方解决方案是在/etc/wsl.conf添加以下配置:

[filesystem]
umask = 022

在未来某个版本的系统更新后生效,与上面的方案理论上不会冲突,所以添加无副作用。

参考文章

WSL 配置指北:打造 Windows 最强命令行

fstab (简体中文) - ArchWiki

Fix Windows Subsystem for Linux (WSL) File Permissions