这种容器内的权限拒绝问题真的很磨人，我之前踩过不少坑，给你几个实用的排查和解决方向：

• 先确认容器运行时的用户身份
  有时候你在Dockerfile里改了目录权限，但容器启动时用的不是你预期的用户。先登录到容器里看看当前用户：

  docker exec -it <你的容器ID/名称> whoami
  

  如果输出不是www-data，那要么在Dockerfile末尾加上USER www-data来指定运行用户，要么如果是启动时用--user参数指定了其他用户，就得把那个用户加入www-data组，比如：

  RUN usermod -aG www-data <你的用户名>
  

• 排查是否是挂载卷的权限问题
  如果/var/www/html/folder是宿主机挂载的目录（不管是bind mount还是volume），那Dockerfile里的RUN指令是在镜像构建阶段执行的，根本碰不到挂载后的目录。这种情况得直接在宿主机上调整目录权限：

  chown -R www-data:www-data /宿主机上对应的挂载路径
  

  或者更灵活的方式，启动容器时用宿主机当前用户的UID/GID来运行，避免权限不匹配：

  docker run -v /宿主机路径:/var/www/html/folder --user $(id -u):$(id -g) <你的镜像名>
  

• 确保构建时目录已存在
  要是你在Dockerfile里先执行了chown，但目录是后面才创建的（比如通过挂载或者其他指令），那之前的权限修改就白做了。记得先创建目录再改权限：

  RUN mkdir -p /var/www/html/folder && chown -R www-data:www-data /var/www/html/folder
  

• 检查SELinux限制（Linux主机专属）
  如果你的宿主机开了SELinux，它可能会阻止容器写入挂载目录。可以先临时关闭测试：

  setenforce 0
  

  如果关闭后能正常写入了，就给宿主机的挂载目录添加正确的SELinux上下文：

  chcon -Rt svirt_sandbox_file_t /宿主机上的挂载路径
  

• 临时测试权限范围（仅限排查）
  虽然不推荐用777这种不安全的权限，但可以先临时测试：

  RUN chmod 777 -R /var/www/html/folder
  

  如果能写入了，说明确实是权限范围不够，再调回更安全的775或者755，同时确保运行用户属于目录的所属组。

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