umask设置不当导致写入失败，本质是容器进程创建文件时默认权限被过度限制（如600/700），使挂载卷中新文件对其他用户或组不可写；需验证umask值、进程UID/GID匹配及权限链完整性，推荐生产环境设umask 0002。
umask 设置不当导致的写入失败，本质是容器内进程创建文件时默认权限被过度限制，使得挂载卷中的新文件或目录对后续操作（如 php 写日志、上传临时文件）不可写。这类问题隐蔽性强——文件能创建成功，但权限过严（如 600 或 700），其他用户或组无法访问，尤其在多服务协作或宿主机同步场景下极易暴露。
确认 umask 是否生效于目标进程
不要假设容器启动脚本或 Apache/PHP-FPM 的 umask 与预期一致。需直接进入容器验证：
- 运行 docker exec -it <container> sh，切换到应用工作目录（如 /var/www/html）
- 执行 umask 查看当前值（如 0022 表示默认创建文件为 644，目录为 755）
- 手动测试：运行 touch testfile && ls -l testfile，观察实际权限是否符合 umask 推算结果
- 若使用 PHP，可在脚本中调用 echo umask(); 或 var_dump(decoct(fileperms('test'))); 验证运行时值
检查服务主进程的 umask 继承来源
Apache、PHP-FPM 等通常不直接读取系统 /etc/profile，其 umask 来自启动方式：
- systemd 启动的服务：检查 systemctl show --property=UMask 或单位文件中 UMask= 设置
- Dockerfile 中通过 RUN 设置的 umask 仅影响构建阶段，CMD 或 ENTRYPOINT 启动的进程需显式设置
- 常见错误：在 apache2-foreground 脚本中未重置 umask，导致继承了 root 的严格值（如 0077）
- 建议统一在入口脚本开头强制设置：umask 0002（保证组可写）或 umask 0000（开发环境快速验证）
结合 UID/GID 匹配验证权限链是否完整
即使 umask 合理，若文件属主不匹配，宽松权限也无意义：
- 新建文件权限为 664（umask 0002），但属主是 root:root，而 PHP 进程以 www-data:www-data（UID/GID 33）运行 → 仍属“其他用户”，受最后一位权限控制
- 必须同时满足：umask 允许组/其他写入 + 进程 UID/GID 与文件属组匹配（例如将 www-data 加入宿主机对应组，或同步 UID/GID）
- 验证命令：ls -ld /mounted/dir 和 ps aux | grep apache 对照 UID/GID
临时绕过与长期修复建议
快速定位是否为 umask 主因：
- 启动容器时覆盖 umask：docker run --rm -it --entrypoint sh image -c "umask 0002; exec apache2-foreground"
- 在 PHP 中临时放宽：umask(0); file_put_contents(...)（仅调试，勿上线）
- 长期方案：在 Dockerfile 的 ENTRYPOINT 脚本第一行写死 umask 0002，并确保该脚本以目标用户（如 www-data）身份执行
- 生产环境推荐 umask 0002：兼顾安全性（不开放 world-writable）与协作性（组内可写）
