![wordpress文件上传在nginx下成功,但尝试加载文件返回403](https://linux22.com/image/738038/wordpress%E6%96%87%E4%BB%B6%E4%B8%8A%E4%BC%A0%E5%9C%A8nginx%E4%B8%8B%E6%88%90%E5%8A%9F%EF%BC%8C%E4%BD%86%E5%B0%9D%E8%AF%95%E5%8A%A0%E8%BD%BD%E6%96%87%E4%BB%B6%E8%BF%94%E5%9B%9E403.png)
在过去的几个小时里,我一直在尝试调试这个问题,尽管已经解决了这么多问题,但我似乎遇到了瓶颈
我在 CentOS7 上使用 nginx 安装了 Wordpress(如果需要的话,AWS Lightsail)。为此,我确保
wp-content/uploads
目录是 766- 该目录由该用户拥有
apache:apache
,并且 nginx 和 php-fpm 均在该用户下运行 - seLinux
httpd_sys_rw_content_t
用于目录
这让我成功上传了文件。它创建了文件,并且上述权限正确传播(ln -Z
并stat
以apache
用户身份运行)。文件是 666,但 766 似乎没有改变任何东西。我手动上传的旧文件可以正常使用。我能找到的唯一区别是手动上传的文件在 seLinux 中设置为
Context: unconfined_u:object_r:httpd_sys_rw_content_t:s0
虽然新的 403 文件是
Context: system_u:object_r:httpd_sys_rw_content_t:s0
我试过了setenforce 0
,但没什么变化。重启了 nginx 也还是没变化。记录的错误是
2019/05/19 22:35:06 [error] 21393#0: *4010 open() "/usr/share/nginx/example/wp-content/uploads/2019/05/file.jpg" failed (13: Permission denied), client: 172.69.44.142, server: example.com, request: "GET /wp-content/uploads/2019/05/file.jpg HTTP/1.1", host: "www.example.com"
但/usr/share/nginx/example/wp-content/uploads/2019/04/another_file.jpg
运行良好,所以它似乎与 nginx 配置无关。
我还遗漏了什么吗?
答案1
修复权限。766 不是目录的有效模式,至少当您想访问其中的文件时不是。