umask在WSL中不生效的根本原因是VSCode Remote-WSL启动的非登录shell绕过完整初始化链路，且挂载Windows文件系统时优先采用/etc/wsl.conf中的umask配置，而非用户shell配置；必须正确配置该文件并执行wsl --shutdown重启才能生效。
为什么 umask 在 WSL 中不生效？
VSCode 集成终端启动的 shell（如 bash）默认不会读取你手动设置的 umask，尤其当它通过 Windows 启动、再连接到 WSL 实例时，shell 初始化流程被截断。常见现象是：你在 ~/.bashrc 里写了 umask 022，但新建文件权限仍是 666 或目录为 777 —— 这说明 shell 没走完整初始化链路。
根本原因在于 VSCode Remote-WSL 扩展启动的终端会绕过登录 shell 的配置加载（比如不触发 /etc/profile 或 ~/.bash_profile），而只加载部分交互式配置。因此依赖 .bashrc 设置 umask 往往失效。
- 检查当前生效的
umask：运行umask命令，输出应为0022（八进制），不是0002或0000 - 确认是否在登录 shell 中：执行
shopt login_shell，返回login_shell off表示当前是非登录 shell - 临时修复：直接在终端里运行
umask 022，但重启终端后丢失
/etc/wsl.conf 的 umask 配置优先级最高
WSL 自身挂载 Windows 文件系统（如 /mnt/c）时，会用 /etc/wsl.conf 里的 umask 值覆盖所有用户 shell 的设置。这是唯一能确保新建文件权限一致的方案，尤其对 Git、Node.js 构建等依赖默认权限的工具至关重要。
必须把配置写进 /etc/wsl.conf（不是用户家目录下的配置），且格式严格：
#[automount] enabled=true options="metadata,uid=1000,gid=1000,umask=022"
-
umask=022是八进制写法，不能写成umask=22或umask=0o022 - 该配置仅影响挂载点（
/mnt/c等），不影响 WSL 本地路径（如~/），后者由 shell 自己控制 - 修改后必须执行
wsl --shutdown，再重启 VSCode（不是只重启终端）
VSCode 终端启动时绕过 umask 的真实路径
VSCode Remote-WSL 默认用 code --remote wsl+Ubuntu 启动，其底层调用的是 wsl.exe -d Ubuntu -e /bin/bash -i -l（带 -l 表示登录 shell）。但实际行为取决于发行版默认 shell 和 WSL 版本 —— WSL2 多数情况下仍跳过 ~/.profile，只读 ~/.bashrc。
若你坚持用 shell 配置而非 wsl.conf，需确保：
- 在
~/.bashrc开头添加：if [ -z "$WINEPREFIX" ]; then umask 022; fi（防误触发） - 禁用 VSCode 的“自动检测 shell”：在设置中搜索
terminal.integrated.defaultProfile.linux，手动设为bash并勾选terminal.integrated.inheritEnv - 避免在
~/.bashrc里用return提前退出，否则后续umask不执行
权限不一致时最该先查的三个位置
当你发现 chmod 生效但新建文件权限不对，或 Git 报 “bad ownership”，不要急着改代码，先定位源头：
- 运行
mount | grep drvfs，确认/mnt/c挂载参数含umask=022—— 若显示umask=0000，说明wsl.conf没生效或格式错 - 在 VSCode 终端里执行
id，检查 UID 是否为1000；若为0（root），umask可能被忽略（root 默认 umask 是022，但某些发行版例外） - 新建测试文件：
touch /mnt/c/tmp/test.txt && ls -l /mnt/c/tmp/test.txt，观察权限是否为-rw-r--r--（即 644）；不是则说明挂载层未接管
真正起作用的永远是挂载时的 umask，不是 shell 里的那行命令 —— 这点容易被忽略，但决定了你改半天 .bashrc 为什么白忙活。
