如何设置Docker中ThinkPHP日志权限及挂载目录权限修正？

本文共计1084个文字，预计阅读时间需要5分钟。

ThinkPHP容器内日志写入失败，根本原因并非代码问题，而是容器启动时挂载目录的UID/GID与应用进程用户不匹配，导致storage/logs不可写。

为什么 storage/logs 挂载后仍报“Permission denied”

常见现象是容器启动后访问接口直接 500，docker logs 显示类似 file_put_contents(/var/www/html/storage/logs/laravel.log): failed to open stream: Permission denied（ThinkPHP 同理，路径为 runtime/log/ 或 storage/log/）。这不是 SELinux 或 root 权限缺失，而是宿主机挂载目录的所有者 UID（比如 1001）与容器内运行 PHP-FPM 的用户 UID（比如 82，即 www-data）不一致，Linux 文件系统按 UID 判定权限。

• 用 docker exec -it <container> id 查容器内 PHP 进程实际 UID
• 用 ls -ld /path/on/host/runtime/log 确认宿主机目录所有者 UID
• 两者不等 → 写入拒绝，哪怕目录权限是 777 也无效

三种可靠修复方式（按推荐顺序）

优先选方案一，它不依赖宿主机用户配置，也不引入特权模式：

• 方案一（推荐）：在 Dockerfile 中显式创建日志目录并 chown
  在 RUN composer install 后、COPY . /var/www/html 前插入：

  RUN mkdir -p /var/www/html/runtime/log /var/www/html/runtime/cache \ && chown -R www-data:www-data /var/www/html/runtime再确保 PHP-FPM 配置里 user = www-data，这样容器启动时目录所有权已就位

• 方案二：启动时用 --user 强制匹配宿主机 UID
  若宿主机目录属主 UID 是 1001，则启动命令加：docker run --user 1001:1001 -v /host/runtime:/var/www/html/runtime ...。注意：该 UID 必须在容器内存在对应用户（可用 getent passwd 1001 验证），否则 PHP-FPM 可能无法加载扩展
• 方案三：挂载前预设宿主机目录 UID
  在宿主机执行：sudo chown 82:82 /host/runtime/log（82 是容器内 www-data UID），再挂载。缺点是需提前知道容器内 UID，且跨环境易出错

docker-compose.yml 中必须避开的坑

很多人以为加 user: "82:82" 就够了，但实际常被忽略的关键点：

立即学习“PHP免费学习笔记（深入）”；

• volumes 下挂载路径不能是相对路径，如 ./runtime:/var/www/html/runtime 在某些 Docker 版本会因路径解析失败导致权限继承异常 —— 改用绝对路径：/full/path/to/host/runtime:/var/www/html/runtime
• 不要在 command 或 entrypoint 中动态 chown，因为挂载发生在容器初始化早期，此时 chown 对已挂载目录无效（只影响挂载点本身，不影响其下文件）
• 避免使用 --privileged=true 解决日志权限 —— 这是过度授权，且对 ThinkPHP 日志问题完全无用

验证是否真正修复

别只看容器是否启动成功，要实测日志落地：

• 触发一次日志写入（如访问一个会记录 trace 的接口）
• 执行：docker exec <container> ls -l /var/www/html/runtime/log/，确认生成的 .log 文件属主是 www-data
• 再检查宿主机对应挂载目录：ls -l /host/runtime/log/，文件应存在且 UID 匹配（数值一致，非用户名）
• 如果仍失败，用 docker exec <container> ps aux | grep php 确认实际 worker 进程 UID，它可能和配置的 user 不同（例如被 FPM pool 配置覆盖）

最易被忽略的是：ThinkPHP 的 runtime 目录下有多个子目录（log、cache、temp），权限问题可能只暴露在某个子目录；而 chown -R 必须覆盖全部，漏掉 temp 也可能导致后续缓存写入失败，连带影响日志初始化。