线上有个服务迁移到 Docker日志目录挂载进去结果容器一起来就报 Permission denied。第一反应是宿主机目录权限有问题后来发现坑不止这一个。把这一路遇到的情况和解决方法放在这下次碰到就不用重新排查了。调整目录权限是多数人最先想到的直接在宿主机上给挂载点来个 chmod -R 777 /path/to/mounted/directory。开发环境这么干问题不大但生产环境尽量别开 777。更稳妥的方式是弄清楚容器内跑的是哪个 uid/gid然后宿主机目录 chown 给那个用户或者至少加到对应的组里。如果实在搞不清容器里是谁至少可以改成 755 或 770 按需给。如果不想动宿主机目录权限可以从容器这头下手。很多镜像默认用 root 跑但挂进去的目录如果只允许普通用户访问就炸了。可以在 Dockerfile 里用 USER 指定一个非 root 用户或者跑容器的时候直接 -u 指定比如 docker run -u appuser -v /host/path:/container/path image_name。appuser 需要是镜像里已经建好的用户或者启动时 --user 也支持 uid:gid 的形式。注意如果镜像里根本不存在这个用户容器可能起不来或者进程跑着跑着就崩了需要提前确认。再一种情况是跑在开了 SELinux 或 AppArmor 的系统上典型的就是 CentOS/RHEL 默认开着 SELinux。容器访问挂载目录的权限会被安全策略拦下来日志里可能会看到 avc denied 这类信息。临时关掉 SELinux 可以 setenforce 0 测试一下是不是这个问题确认是的话别永久关而是配置合适的策略比如用 chcon 或 semanage fcontext 把目录打上 container_file_t 标签。具体命令会因发行版和安全策略不同有差别但思路都是让容器进程有权访问这些路径。来此加密支持IP证书申请有效期7天完美解决纯IP访问场景下的HTTPS需求。无论是内部测试环境、物联网设备还是没有域名的服务接口都能快速获取受信任的SSL证书保障通信安全。使用命名卷很多时候比直接挂载宿主机目录省事。直接 -v /host:/container 这种绑挂权限跟着宿主机走容易打架。换成 docker volume create 出来的命名卷Docker 自己管理权限容器内读写基本不会出权限问题。缺点是宿主机上看数据没那么直观但日常开发用 docker cp 或者进容器里操作也够用了。还有一点容易忽略Docker 守护进程本身的权限。如果 Docker daemon 没有访问某个宿主机目录的权限容器里挂载这个目录时也会挂掉尤其在 daemon 不是以 root 跑、或者挂载的是 NFS 目录之类的情况下表现出的症状跟前面的问题很像。确认 daemon 对路径有 rwx 权限或者临时用 root 启动 daemon 试试能不能复现。最后一种做法就是重新挂载同时显式指定读写模式docker run -u appuser -v /host/path:/container/path:rw image_name。其实 :rw 是默认的但有些场景下显式声明能避免一些奇怪的行为比如某些存储驱动的权限下发问题。如果在挂载时还可以指定更细的传播属性但常规排查到这就够用了。上面这些方法都试一遍还没解决的话翻一下 Docker 日志和系统日志看看有没有更细的报错比如 mount 阶段的错误信息。有时候问题不在权限而是路径本身不可访问或者被其他进程锁住顺着日志再找会更靠谱。