--user参数必须与宿主机挂载目录属主UID/GID数值严格对齐，否则因Linux权限系统只认数字ID，即使目录权限为777也会报Permission denied；Docker Desktop无图形化用户配置，所有控制须通过CLI或Compose显式指定。
--user 参数必须和宿主机目录属主 UID/GID 对齐，否则挂载卷写入失败；Docker Desktop 本身不提供图形界面配置用户的功能，所有用户控制都依赖 CLI 或 Compose 配置。
docker run --user 指定 UID/GID 时为什么报 permission denied
常见错误现象是容器能启动、ls 看到挂载目录但无法 touch 或写入文件，错误信息类似 Permission denied。根本原因不是镜像没建用户，而是宿主机上挂载路径（如 /host/data）的属主 UID 和 --user 值不一致。
- 用
ls -ld /host/data查宿主机目录实际 UID（比如显示drwxr-xr-x 2 1000 1000） - 运行容器时必须用
--user 1000:1000，不能写--user 1001或--user nobody -
--user不改变宿主机文件归属，只决定“谁在容器里操作这些文件” - 如果宿主机目录属主是 root（UID 0），而你指定
--user 1000，那即使目录权限是 777 也会拒绝写入
docker-compose.yml 中设置 user 后容器仍以 root 启动
典型表现是 docker-compose exec myapp id 显示 uid=0，说明 user 字段没生效。最常踩的坑是镜像中未预置对应用户或 UID 冲突。
- 确认镜像内存在该 UID：进容器执行
getent passwd 1000，无输出说明 UID 1000 在镜像中不存在 - 避免用用户名（如
user: appuser），除非你明确在 Dockerfile 里用useradd创建了它；优先用user: "1000:1000"（字符串格式防 YAML 解析错误） - 检查是否被 Dockerfile 的
USER指令覆盖：如果镜像构建时已写死USER root，docker-compose.yml的user会被忽略 - Windows/macOS 上通过 Docker Desktop 启动时，
user设置完全生效，无需额外操作——它只是调用后台 Docker Engine，行为和 CLI 一致
Docker Desktop for Windows 需要 WSL2 用户映射配合 --user
在 Windows 上，Docker Desktop 底层走 WSL2，而 WSL2 默认将 Windows 用户映射为 UID 1000。若你在 WSL2 发行版里改过默认 UID（比如用 usermod -u 1001），就会导致宿主机挂载路径权限错位。
- 查 WSL2 当前 UID：
wsl -u root -c "cat /etc/passwd | grep $(whoami)"，看第一字段数值 - 保持一致性：要么让 WSL2 用户 UID 回到 1000，要么把挂载目录属主改成对应 UID（
sudo chown -R 1001:1001 /mnt/wsl/mydata） - 不要试图在 Docker Desktop GUI 里点选“用户”，它根本没有这个配置项——所有用户控制必须写在
docker run命令或docker-compose.yml里 - Windows 路径挂载（如
-v C:\data:/app）实际落在 WSL2 的/mnt/c/data，其权限由 WSL2 的 UID/GID 决定，不是 Windows ACL
真正容易被忽略的是：宿主机路径权限和容器内 UID 的对齐发生在挂载瞬间，不是容器启动后才校验；一旦错配，连日志都可能写不进 volume，排查时别只盯容器内，先看 ls -n 输出的数字 UID。
