必须将宿主机路径添加到Docker Desktop的File Sharing列表中，否则挂载失败且仅报“Mounts denied”；Windows需勾选对应盘符，Mac需精确添加绝对路径并避免父子目录冲突。
Windows 上 Docker Desktop 报 Mounts denied：先查 File Sharing 设置
这个错误根本不是路径写错了，而是 Docker Desktop 根本没被授权访问你写的那个盘符或目录。哪怕 C:/mydata 确实存在、权限也没问题，只要没在设置里勾选对应驱动器，docker run -v 就会直接失败，报错里连具体路径都懒得提。
操作步骤很明确：
- 右键任务栏 Docker 图标 → Settings → 左侧选 Resources → File Sharing
- 检查你要挂载的路径所属盘符是否已勾选（比如挂
D:/project，就必须勾上D:） - 如果刚加了新盘符，点 Apply & Restart；Docker 重启后状态栏显示 “running” 才算生效
- 若弹出凭据框，填当前 Windows 登录的**用户名 + 密码**（不能用 PIN 或 Microsoft 账户临时密码）
Mac 上 Mounts denied: EOF 或 path is not shared from the host 怎么修
Mac 的报错更隐蔽，常见两种形式：Mounts denied: EOF 多半是 File Sharing 列表里路径有包含关系；path is not shared from the host 就是路径压根没加进白名单。
关键限制就两条，必须同时满足：
- 要挂载的路径必须**精确添加**到 File Sharing 列表中，不能靠父目录“顺带覆盖”——比如列表里有
/Users，但你想挂/mydata，那就得单独加/mydata - 列表中任意两个路径**不能互为父子目录**，例如不能同时存在
/和/Users，否则 Docker Desktop 启动时会拒绝加载配置，导致 EOF 错误 - 路径必须是宿主机上的**绝对路径**，且目录需提前创建好（
docker run -v不会自动建父级目录） - 避免使用符号链接路径，Docker Desktop 不会自动解析它指向的真实位置
-v 参数路径写法：Windows 和 Mac 都别用反斜杠
路径格式不对不会报语法错误，但挂载一定失败。核心原则是：用正斜杠，不带多余空格，不手动拼 /host_mnt。
Windows 正确写法：
-
C:/mydata✅（推荐，CMD/PowerShell 都认） -
D:/project/subdir✅（D 盘路径同理） -
C:\mydata❌（反斜杠在 CMD 中可能被当转义） -
//c/mydata❌（这是 WSL 内部路径，宿主机命令里不能用）
Mac 正确写法：
-
/Users/yourname/project✅（绝对路径，开头必须是/） -
/Volumes/ExternalHD/data✅（外接硬盘也一样处理） -
~/project❌（波浪号不展开，Docker 不识别） -
./data❌（相对路径无效）
验证挂载是否真生效，别只看容器启动成功
容器能起来不代表挂载成功。很多情况下 -v 参数被静默忽略，或者挂载成了只读、空目录，但命令没报错。
验证动作必须做：
- 启动容器时加
-it进入交互模式，执行ls -l /mnt（假设你挂到/mnt），确认能看到宿主机文件 - 在容器内新建一个文件：
echo "test" > /mnt/test.txt，然后退出，去宿主机对应目录下找这个文件是否存在 - 反过来，在宿主机新建文件，再进容器看能否读到——双向同步才算真正打通
- 如果用的是
docker-compose.yml，注意volumes:下的路径写法同样受 File Sharing 限制，不能绕过
最常被忽略的一点：挂载路径在宿主机上必须已存在，且 Docker Desktop 进程有读写权限。某些 NAS 或加密卷，即使路径可见，也可能因 ACL 或挂载选项被 Docker 拒绝访问——这时候报错还是 Mounts denied，但真实原因藏在系统日志里。
