Dockerfile执行chown后仍出现PermissionError权限拒绝，如何解决？

根据你提供的Dockerfile、代码和错误栈，这里整理几个可能的原因及对应的解决思路：

1. Kubernetes卷挂载导致权限冲突 #

你提到Kubernetes日志sidecar会读取该日志目录，说明是在K8s环境部署。如果/opt/docker/logs被挂载为emptyDir或其他类型的卷，K8s默认会给卷设置root:root的权限，此时即使镜像中目录权限正确，daemon用户也无法写入。

解决方法：

• 在Pod的securityContext中添加fsGroup配置，让卷的属组与daemon用户一致：

  securityContext:
    fsGroup: 1  # Ubuntu 16.04中daemon用户的GID通常为1
  

• 或者直接指定容器以daemon用户运行：

  securityContext:
    runAsUser: 1
    runAsGroup: 1
  

2. 镜像构建中权限被意外修改 #

虽然你在创建/opt/docker/logs后立即执行了chown -R daemon:daemon /opt/docker，但可以验证后续操作是否意外修改了权限：

验证与修复：
在Dockerfile的USER daemon之前添加一行打印目录权限：

RUN ls -ld /opt/docker/logs

构建镜像时查看输出，确认目录所有者是daemon:daemon，权限至少为drwxr-xr-x（755）。如果权限异常，可在chown后追加chmod命令：

RUN chown -R daemon:daemon /opt/docker && chmod -R 755 /opt/docker/logs

3. uWSGI配置覆盖了运行用户 #

你的ENTRYPOINT使用uWSGI启动应用，如果app.ini配置文件中指定了uid或gid参数，会覆盖Dockerfile中USER daemon的设置，导致应用以其他用户运行，无法写入日志。

解决方法：
检查app.ini，确保没有设置与daemon用户不符的uid/gid，或者显式指定：

uid = daemon
gid = daemon

4. 日志文件已存在且属主为其他用户 #

如果之前的Pod实例已经创建了application.log文件，且该文件属主是root，新启动的容器用daemon用户运行时，会因无法写入现有文件而报错。

解决方法：

• 测试阶段可在启动前删除旧文件：

  ENTRYPOINT rm -f /opt/docker/logs/application.log && uwsgi --wsgi-file src/app.py --http-socket :9000 --callable app --ini app.ini
  

• 生产环境建议确保日志文件始终由daemon用户创建，比如在应用启动时先检查文件属主，或直接使用目录权限控制。

内容的提问来源于stack exchange，提问作者Saturnian