Mac Docker挂载宿主机目录需先将路径添加到Docker Desktop的File Sharing列表，再用-v或--mount指定不带尾斜杠的绝对路径挂载。
直接改宿主机目录的 chmod 777 或进容器里 chown 临时修，大概率治标不治本，还会掩盖 UID/GID 映射失配这个真正病灶。
确认 Docker Desktop 卷实际挂载在宿主机哪条路径
Docker Desktop 的命名卷（named volume）默认不直接映射到你可见的宿主机路径，而是由它自己管理——Windows/macOS 上藏在虚拟机或后台服务里，docker volume inspect myvol 看到的 Mountpoint 是容器内视角，不是宿主机真实路径。强行去宿主机找 /var/lib/docker/volumes/... 通常找不到，或找到的是空目录。
- Windows：实际数据在 WSL2 虚拟机中，路径类似
/mnt/wsl/docker-desktop-data/version-pack-data/community-data/volumes/...，但不建议手动操作 - macOS：数据在
~/Library/Containers/com.docker.docker/Data/vms/0/data/DockerDesktop.vmdk内部，不可直访 - 真正可干预的只有绑定挂载（bind mount），即
-v /host/path:/container/path这种显式路径
绑定挂载时权限不对，优先对齐 UID/GID 而非硬 chmod
典型现象是容器内进程写文件失败，报 Permission denied，但宿主机上目录明明有写权限。本质是容器内用户（比如 UID 1001）和宿主机目录属主（比如 UID 1000）不一致。
- 启动容器时用
--user $(id -u):$(id -g)，让容器进程身份和当前 shell 用户一致 - 宿主机提前执行
sudo chown -R $(id -u):$(id -g) /host/path，把目录属主设成匹配值 - 避免
chmod -R 777 /host/path：绕过权限模型，SELinux/AppArmor 可能静默拒绝，且破坏最小权限原则 - 如果用 Docker Compose，写成
user: "${UID}:${GID}"，并在env_file或 shell 中导出UID/GID
命名卷（named volume）权限问题必须从镜像构建阶段解决
命名卷本身没有“宿主机权限”概念，它的权限完全取决于容器内进程以谁的身份写入。一旦第一次写入发生，后续所有容器都得用相同 UID 才能读写已有文件。
- Dockerfile 中必须预设用户：
RUN mkdir -p /data && chown 1001:1001 /data，再USER 1001 - 首次运行前，可用临时容器初始化：
docker run --rm -v myvol:/data alpine chown 1001:1001 /data - 不要依赖
entrypoint.sh启动时chown：如果卷里已有文件且属主是 root，非 root 用户根本进不去目录，脚本压根执行不了 - Mac 上 Docker Desktop 的命名卷还受
osxfs文件系统层影响，若启用了 “Use gRPC FUSE for file sharing”，权限传递更稳定，建议开启
Mac 上特别注意 NFS 和 gRPC FUSE 的权限表现差异
Mac 的 Docker Desktop 默认用 osxfs 共享文件，但它对 UID 映射较弱；切换到 gRPC FUSE 后，UID/GID 透传更准，但要求宿主机目录权限宽松（至少 755）且属主匹配。
- 检查是否启用：Docker Desktop → Settings → General → ✅
Use the new Virtualization framework+ ✅Use gRPC FUSE for file sharing - 启用后仍报错？确认宿主机目录没被 ACL 或扩展属性锁死：
ls -le /host/path，清理用xattr -rc /host/path - NFS 挂载到 Mac 再被 Docker 挂载进去？极容易双重 UID 错位，应尽量避免，改用绑定挂载或命名卷
最易被忽略的一点：命名卷的权限状态在第一次容器写入时就固化了，之后换任何用户、任何镜像，只要 UID 不同，就可能读不到旧文件——这不是 bug，是设计使然。处理前务必确认卷里有没有关键数据，别盲目 docker volume rm。
