Windows下Docker Desktop挂载报“权限不足”主因是磁盘未共享：需在Settings→Resources→File Sharing中勾选对应盘符（如E:）、重启Docker，并验证路径格式（E:/path或//e/path）及Windows ACL权限。
Windows 上 Docker Desktop 挂载目录报“权限不足”，十有八九不是容器里 UID 没对上，而是宿主机根本没把磁盘共享给 Docker——它压根连文件都读不到。
确认 Docker Desktop 已启用对应磁盘共享
这是 Windows 环境下最常被跳过的一步。Docker Desktop 默认不自动挂载任意本地盘符，必须手动勾选并重启生效。
- 打开 Docker Desktop → Settings → Resources → File Sharing
- 在列表中勾选你的项目所在盘（比如
E:、D:），确保右侧没有红色警告图标 - 点击
Apply & Restart，等 Docker 完全重启完成（状态栏显示绿色 “running”） - 验证是否生效：运行
docker run --rm -v E:/test:/mnt alpine ls /mnt，若报no such file or directory或permission denied，说明共享未生效
检查 Windows 文件系统权限是否阻断访问
Docker Desktop 底层通过 WSL2 访问 Windows 文件，而 WSL2 会继承 Windows 的 ACL 权限。如果目录被设为“仅管理员可访问”或归属了已删除账户，WSL2 进程（即 Docker）就拿不到句柄。
- 右键目标目录 → 属性 → 安全 → 高级 → 所有者，确认所有者是
Administrators或SYSTEM - 在“权限”列表中，确保
Administrators组有“完全控制”，且“继承自父项”已启用 - 若看到“拒绝”条目（尤其是针对
ALL APPLICATION PACKAGES或ALL RESTRICTED APPLICATION PACKAGES），需手动移除 - 避免使用加密文件系统（如 BitLocker 加密卷未解锁、OneDrive 暂挂文件），这类路径 Docker 无法穿透
挂载路径格式写错导致解析失败
Windows 路径在 docker run -v 中必须转换为 Linux 风格，且大小写和斜杠方向敏感；写错不会报错，但实际挂载为空目录，后续操作全失败。
- 正确写法只有两种：
-v E:/myapp:/app或-v //e/myapp:/app（注意双反斜杠开头） - 错误写法示例：
-v E:\myapp:/app（反斜杠会被 shell 当转义）、-v e:/myapp:/app（盘符小写在某些版本不识别） - 路径中不能含中文、空格或特殊符号；如有，改用短路径（如
C:\tmp\proj）或先用mklink建硬链接 - 测试命令：
docker run --rm -v E:/test:/t alpine sh -c "ls -l /t && echo 'OK'"，输出OK才算真正挂进去了
SELinux 不是问题，但 WSL2 的 uid 映射可能干扰
Windows 本身没有 SELinux，但 WSL2 启动的 distro（如 Ubuntu）默认启用了 metadata 挂载选项，会导致 Windows 文件在容器内显示为 uid=0（root），而容器应用若以非 root 用户跑，就会因 uid 不匹配被拒。
- 这不是权限不足，是 uid 错位；现象是
ls -l看文件属主全是root，但容器里id显示当前用户是1001 - 临时绕过：启动时加
--user root测试是否恢复读写（仅用于验证） - 长期解法：在 WSL2 的
/etc/wsl.conf中添加：[automount] options = "metadata,uid=1001,gid=1001"
，然后wsl --shutdown重启 WSL2 - 注意：该配置只影响新挂载的 Windows 路径，旧会话需重启 WSL2 才生效
真正卡住人的往往不是容器内的 UID/GID 对齐，而是 Docker Desktop 根本没拿到文件句柄——盘没共享、ACL 拦着、路径写错，三者占了 Windows 挂载失败的 90%。先盯死这三处，再调容器用户。
