最权威的方式是执行 docker inspect 查看 Mounts 中的 "RW": false 或 "Mode": "ro" 字段，二者一致且直接反映 Docker daemon 记录的挂载配置，不依赖容器内权限或行为验证。
docker inspect 能直接看到 RW 字段
容器启动后，挂载是否只读，最权威的方式就是查 docker inspect 的输出。它不依赖容器内行为（比如 touch 失败可能是权限问题，不是只读），而是直接读取 Docker daemon 记录的挂载配置。
执行：docker inspect
在返回的 JSON 中搜索 Mounts 数组，每个挂载项里有两个关键字段：
-
"RW": true或false—— 这是 Docker 内部标记的读写状态，真实可靠 -
"Mode": "ro"或"rw"—— 对应命令中写的:ro或:rw，和RW值一致
注意：如果没显式加 :ro 或 :rw，Mode 字段可能为空，但 RW 一定为 true（默认可写）。
Windows 上用 docker run -v 挂载时 :ro 是否生效
在 Docker Desktop for Windows 上，:ro 是完全支持的，但有个容易被忽略的前提：它只限制容器内对该路径的写入，**不改变宿主机目录本身的权限或状态**。
常见误判场景：
- 你在容器里
echo test > /mnt/file报错 Permission denied → 先别急着认为 :ro 生效了，可能是宿主机目录权限不对（比如只给了 Users 组读权限） - 你改用
:rw后还是写不了 → 很可能根本不是挂载模式问题，而是 Docker Desktop 没获得 Windows 文件系统访问授权（首次共享目录需提权） - 挂载路径是 WSL2 后端的 Linux 子系统路径（如
/home/user/data）→:ro依然有效，但实际行为还受 WSL2 文件系统 mount 参数影响（比如 WSL2 默认以metadata,uid=1000,gid=1000挂载，可能覆盖容器内 UID）
进容器后怎么快速验证只读挂载是否起作用
不要只靠 ls 看得见就认为能写，要真动手试写。推荐用一行命令判断：
touch /mnt/test-ro-check 2>/dev/null && echo "writable" || echo "readonly or permission denied"
但这个结果需要结合上下文解读：
- 返回
readonly→ 大概率是:ro生效，或容器根文件系统被--read-only锁死 - 返回
permission denied（无输出）→ 更可能是 UID/GID 不匹配、宿主机目录权限不足、或 SELinux/Windows ACL 阻断 - 即使
:ro没设，也有可能因--read-only导致整个/mnt下游路径都不可写
所以验证时务必确认你测的是挂载点本身（如 /mnt），而不是它的子目录（如 /mnt/subdir），后者权限可能被子目录自身属性覆盖。
为什么 docker inspect 显示 RW:true，但容器里还是写不了
这是最常让人困惑的情况。RW:true 只代表 Docker 允许写，不代表“一定能写成功”。真正卡住的环节往往在操作系统层：
- 宿主机目录属主不是容器进程 UID，且权限没开放（例如目录是
755，容器用户 UID=1001，但目录所有者 UID=1000） - Windows 上 Docker Desktop 没启用 “Use the WSL2 based engine” 或共享目录未在 Settings → Resources → File Sharing 中勾选
- SELinux 启用时没加
:z或:Z标签（常见于 CentOS/RHEL 宿主机，但 Docker Desktop for Windows 不涉及） - 挂载路径跨了不同文件系统（比如从 NTFS 挂到 WSL2 的 ext4），某些元数据操作被拦截
这时候 docker inspect 是对的，问题不在 Docker 挂载配置，而在运行时环境。先看容器内 id 和 ls -ld /mnt，再回宿主机查对应路径的 icacls（Windows）或 ls -ld（WSL2/Linux）。
