镜像导入后无法直接检查文件权限，必须启动临时容器（如 docker run --rm -it 镜像 ls -l 路径）或进入运行中容器执行 stat、cat 等命令验证；挂载场景需同步核对宿主机 uid/gid 与容器运行用户是否一致。
导入镜像后，不能直接“检查容器内文件权限”，因为镜像本身不运行、不含进程，也没有运行时的用户上下文。必须先启动容器（哪怕临时），才能查看和验证实际挂载或解压后的文件权限状态。
启动临时容器快速检查
用 docker run --rm -it 启动一个一次性容器，直接执行 ls -l 查看目标路径：
- 如果知道文件路径（比如
/app/config.yaml）：docker run --rm -it your-image:tag ls -l /app/config.yaml - 如果要查看整个目录：
docker run --rm -it your-image:tag ls -l /app/ - 加
-u 1001模拟非 root 用户运行时的视角（更贴近生产环境）：docker run -u 1001 --rm -it your-image:tag ls -l /app/
检查文件所有者与用户 UID 是否匹配
权限问题常出在 UID 不一致：宿主机文件被挂载进容器后，若容器内运行用户 UID 与文件所有者 UID 不同，就会无权访问。
- 查容器内默认用户：
docker run --rm -it your-image:tag id→ 输出类似uid=0(root) gid=0(root) - 查镜像中是否指定了用户：
docker inspect your-image:tag | jq '.[0].Config.User'（需安装 jq） - 若镜像设了
USER 1001，但挂载的宿主机文件属主是uid=1000，就可能读取失败
对已运行容器进行深入验证
如果容器已在后台运行，可用 docker exec 进入并模拟应用行为：
- 进入容器：
docker exec -it container-name /bin/sh（Alpine）或/bin/bash（Ubuntu） - 确认当前用户能否读取关键文件：
cat /path/to/config.json > /dev/null && echo "OK" || echo "Permission denied" - 用
stat查看详细权限和属主：stat /path/to/file（比ls -l更明确显示 UID/GID 数值） - 若需验证写权限，可尝试创建测试文件：
touch /path/to/test.tmp 2>/dev/null && rm /path/to/test.tmp && echo "writable"
结合挂载场景重点核对
若使用 -v 或 --mount 挂载了宿主机路径，权限检查必须兼顾两端：
- 在宿主机上运行：
ls -lnd /host/path/to/file→ 关注 UID/GID 数字，而非用户名（容器里未必有该用户） - 确认挂载后容器内看到的 UID 是否与运行用户一致：
docker exec container-name stat /container/mount/path - 常见修复方式：
• 宿主机改文件属主：sudo chown 1001:1001 /host/path
• 启动容器时指定匹配 UID：docker run -u 1001 -v /host:/container ...
• 镜像中用adduser创建同 UID 用户并设为默认
