最直接验证方式是用 docker inspect 查看 Mounts 字段：存在非空数组、Source 与 Destination 路径匹配、RW 为 true，即表明挂载元数据已正确配置。
检查 docker inspect 的 Mounts 字段是否显示挂载项
这是最直接的验证方式，不依赖容器内命令或文件操作。运行容器后，用 docker inspect 查看挂载元数据是否真实存在、路径是否匹配、RW 是否为 true：
- 启动带挂载的容器：
docker run -d --name test-mount -v C:/test-data:/mnt ubuntu:22.04 sleep infinity - 执行：
docker inspect test-mount - 在输出中定位
Mounts数组，确认有类似条目：[{"Type":"bind","Source":"C:\test-data","Destination":"/mnt","Mode":"","RW":true,"Propagation":"rprivate"}] - 注意
Source是 Windows 路径（含反斜杠转义），RW:true表示挂载本身启用了读写——但不代表一定能写，只是排除了:ro配置错误
在容器内执行 ls 和 touch 验证双向同步
仅看 inspect 不够，必须测试实际 I/O。重点不是“能不能看到文件”，而是“改了宿主机，容器里立刻有；容器里写了，宿主机上立刻出现”：
- 宿主机提前创建目录并放一个文件：
mkdir C: est-data & echo "host-init" > C: est-datainit.txt - 进容器：
docker exec -it test-mount bash - 检查可见性：
ls /mnt应列出init.txt - 写入新文件：
echo "from container" > /mnt/container.txt - 退出后，在 Windows 资源管理器打开
C: est-data，确认container.txt已存在 - 反过来，在 Windows 里新建
C: est-datahost-new.txt，再进容器ls /mnt，应立刻看到它
遇到 Permission denied 时优先排查 UID/GID 匹配
挂载成功、RW:true、路径也对，却 touch 失败？大概率是权限问题，Windows 上尤其隐蔽：
- Ubuntu/Debian 容器默认以 root 运行，但很多镜像（如
node:alpine、php:apache）会切换到非 root 用户（UID 1001、www-data 等） - Windows 文件系统没有 Unix UID 概念，Docker Desktop 会把宿主机目录的“所有者”映射为容器内 UID 0（root），而非 root 的进程就无权写入
- 临时解决：加
--user root强制以 root 运行容器，验证是否是 UID 问题：docker run -it --user root -v C:/test-data:/mnt ubuntu:22.04 touch /mnt/test.txt - 长期方案：若必须用非 root 用户，需在宿主机上用 WSL2 或 PowerShell 的
icacls手动放宽目录权限（例如icacls C: est-data /grant Users:F /t），或换用支持:z标签的 Linux 发行版（Windows 原生不支持:z，此标签在 Docker Desktop + WSL2 后端下才有效）
Windows 路径写错会导致 no such file or directory 且不报挂载失败
这个错误常被误判为 Docker 权限问题，其实只是路径格式没过 Docker Desktop 解析关：
- 绝对路径必须用正斜杠 + 驱动器前缀：
C:/data✅，C:data❌，/c/data❌（这是 WSL2 内部路径，宿主机命令里不能用） - 盘符必须大写，
c:/data在某些 Docker Desktop 版本下会静默失败 - 路径无需引号，即使含空格或中文：
-v C:/my project:/app和-v C:/项目:/app都合法 - 宿主机目录必须提前存在，Docker 不会自动创建父级目录——
C:/missing/sub中若C:/missing不存在，挂载直接失败
真正容易被忽略的是：挂载成功 ≠ 写入成功，而写入失败又常被归因为“Docker 权限设置”，实际八成卡在 UID 映射或路径格式上。验证时务必跳过“我以为它该工作”的环节，老老实实走一遍宿主→容器→宿主的完整文件流转。
