Nginx 403 禁止所有文件
我在 CentOS 5 机器上安装了 nginx 和 PHP-FPM，但我很难让它为我的任何文件提供服务 - 无论是否是 PHP。
Nginx 作为 www-data:www-data 运行，默认的“Welcome to nginx on EPEL”站点（由 root:root 拥有，具有 644 权限）加载良好。
nginx 配置文件有一个 /etc/nginx/sites-enabled/*.conf 的 include 指令， 并且我有一个配置文件 example.com.conf，因此：
server {
listen 80;
Virtual Host Name
server_name www.example.com example.com;
location / {
root /home/demo/sites/example.com/public_html;
index index.php index.htm index.html;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param SCRIPT_FILENAME /home/demo/sites/example.com/public_html$fastcgi_script_name;
include fastcgi_params;
}
}
尽管 public_html 属于 www-data:www-data 并拥有 2777 个文件权限，但该网站无法提供任何内容 -
[error] 4167#0: *4 open() "/home/demo/sites/example.com/public_html/index.html" failed (13: Permission denied), client: XX.XXX.XXX.XX, server: www.example.com, request: "GET /index.html HTTP/1.1", host: "www.example.com"
我发现了许多其他帖子，其中用户从 nginx 收到 403，但我看到的大多数都涉及更复杂的设置和Ruby/Passenger（过去我实际上已经成功了）或者仅在涉及上游 PHP-FPM 时收到错误，因此它们似乎没有什么帮助。
我在这里做了什么傻事吗？
I have nginx installed with PHP-FPM on a CentOS 5 box, but am struggling to get it to serve any of my files - whether PHP or not.
Nginx is running as www-data:www-data, and the default "Welcome to nginx on EPEL" site (owned by root:root with 644 permissions) loads fine.
The nginx configuration file has an include directive for /etc/nginx/sites-enabled/*.conf, and I have a configuration file example.com.conf, thus:
server {
listen 80;
Virtual Host Name
server_name www.example.com example.com;
location / {
root /home/demo/sites/example.com/public_html;
index index.php index.htm index.html;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param SCRIPT_FILENAME /home/demo/sites/example.com/public_html$fastcgi_script_name;
include fastcgi_params;
}
}
Despite public_html being owned by www-data:www-data with 2777 file permissions, this site fails to serve any content -
[error] 4167#0: *4 open() "/home/demo/sites/example.com/public_html/index.html" failed (13: Permission denied), client: XX.XXX.XXX.XX, server: www.example.com, request: "GET /index.html HTTP/1.1", host: "www.example.com"
I've found numerous other posts with users getting 403s from nginx, but most that I have seen involve either more complex setups with Ruby/Passenger (which in the past I've actually succeeded with) or are only receiving errors when the upstream PHP-FPM is involved, so they seem to be of little help.
Have I done something silly here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
我们在使用 Plesk Onyx 17 时遇到了同样的问题。解决方案是将 nginx 用户添加到 psacln 组中，而不是搞乱权限等，其中所有其他域所有者（用户）都是：
现在 nginx 有权访问 .htaccess或正确显示内容所需的任何其他文件。
另一方面，还要确保 Apache 位于 psaserv 组中，以提供静态内容：
并且不要忘记在 Plesk 中重新启动 Apache 和 Nginx！ （并使用 Ctrl-F5 重新加载页面）
We had the same issue, using Plesk Onyx 17. Instead of messing up with rights etc., solution was to add nginx user into psacln group, in which all the other domain owners (users) were:
Now nginx has rights to access .htaccess or any other file necessary to properly show the content.
On the other hand, also make sure that Apache is in psaserv group, to serve static content:
And don't forget to restart both Apache and Nginx in Plesk after! (and reload pages with Ctrl-F5)
我遇到了同样的问题，但上述解决方案没有帮助。
因此，经过一番努力，我发现 sestatus 被设置为强制阻止所有端口，并且通过将其设置为允许，所有问题都得到了解决。
希望这对像我这样的人有帮助。
I was facing the same issue but above solutions did not help.
So, after lot of struggle I found out that sestatus was set to enforce which blocks all the ports and by setting it to permissive all the issues were resolved.
Hope this helps someone like me.
通过错误地运行 setfacl 命令，我发现了这个问题的一个微小变体。我跑了：
我放弃了这条路线，转而将
nginx添加到foo组，但自定义 ACL 阻止了 nginx 访问该文件的尝试。我通过运行清除它：然后 nginx 就能够访问这些文件了。
I dug myself into a slight variant on this problem by mistakenly running the
setfaclcommand. I ran:I abandoned this route in favor of adding
nginxto thefoogroup, but that custom ACL was foiling nginx's attempts to access the file. I cleared it by running:And then nginx was able to access the files.
如果您使用 PHP，请确保服务器块中的
indexNGINX 指令包含 index.php：index index.php index.html;有关详细信息，请查看 <官方文档中的 href="http://nginx.org/en/docs/http/ngx_http_index_module.html#index" rel="nofollow noreferrer">索引指令 。
If you are using PHP, make sure the
indexNGINX directive in the server block contains a index.php:index index.php index.html;For more info checkout the index directive in the official documentation.
你在 nginx 服务器上遇到过 403 Forbidden 吗？
请耐心等待，执行以下步骤(6)：
root /var/www/readcsv;，所以：2.1。逐一检查父文件夹的权限：
2.2。直到满足良好状态：
3.1。文件夹 /var/www/readcsv/fonts/Iosevka/WOFF2 ，使用 chmod 755：
3.2。文件 /var/www/readcsv/fonts/Iosevka/WOFF2/IosevkaFixed-Regular.woff2 ，使用 chmod 644：
快乐 403！
P/S：如果您担心 644、755 代码，请访问：
https:/ /www.multacom.com/faq/password_protection/file_permissions.htm
You meet the 403 Forbidden on nginx server ?
Be patient, perform these steps(6):
root /var/www/readcsv;, so:2.1. check permission of parent folders, one by one:
2.2. until meets the good status:
3.1. folder /var/www/readcsv/fonts/Iosevka/WOFF2 , use chmod 755:
3.2. file /var/www/readcsv/fonts/Iosevka/WOFF2/IosevkaFixed-Regular.woff2 , use chmod 644:
happy 403!
P/S: if you concern about 644, 755 codes, please find at:
https://www.multacom.com/faq/password_protection/file_permissions.htm
一个经常被忽视的权限要求是用户需要在文件的每个父目录中具有 x 权限才能访问该文件。检查 /、/home、/home/demo 等的 www-data x 访问权限。我的猜测是 /home 可能是 770 并且 www-data 无法通过它 chdir 到达任何子目录。如果是，请尝试 chmod o+x /home （或任何拒绝请求的目录）。
编辑：要轻松显示路径上的所有权限，您可以使用
namei -om /path/to/checkOne permission requirement that is often overlooked is a user needs x permissions in every parent directory of a file to access that file. Check the permissions on /, /home, /home/demo, etc. for www-data x access. My guess is that /home is probably 770 and www-data can't chdir through it to get to any subdir. If it is, try chmod o+x /home (or whatever dir is denying the request).
EDIT: To easily display all the permissions on a path, you can use
namei -om /path/to/check如果验证父文件夹的权限后仍然看到
权限被拒绝，则可能是SELinux限制了访问。要检查 SELinux 是否正在运行：
要禁用 SELinux 直到下次重新启动：
重新启动 Nginx 并查看问题是否仍然存在。要允许 nginx 为您的 www 目录提供服务（请确保在测试之前重新打开 SELinux。即
setenforce Enforcing）请参阅我的 在此处回答了解更多信息 细节
If you still see
permission deniedafter verifying the permissions of the parent folders, it may be SELinux restricting access.To check if SELinux is running:
To disable SELinux until next reboot:
Restart Nginx and see if the problem persists. To allow nginx to serve your www directory (make sure you turn SELinux back on before testing this. i.e,
setenforce Enforcing)See my answer here for more details
我通过添加用户设置解决了这个问题。
在 nginx.conf 中将
“用户名”更改为 linux 用户名。
I solved this problem by adding user settings.
in nginx.conf
change the 'username' with linux user name.
我遇到了这个错误，我终于用下面的命令解决了它。
当您将某些内容从一个地方移动到另一个地方时，就会出现此问题。当您移动它时，它会保留原始文件的 selinux 上下文，因此，如果您在 /home 或 /tmp 中解压某些内容，它将获得与其位置相匹配的 selinux 上下文。现在，您将其转移到 /var/www/html ，并且它采用上下文说明它属于 /tmp 或 /home ，并且策略不允许 httpd 访问这些文件。
如果您 cp 文件而不是 mv 文件，则会根据您要复制到的位置而不是文件的来源来分配 selinux 上下文。运行restorecon 会将上下文恢复为默认值并修复它。
I've got this error and I finally solved it with the command below.
The issue is caused when you mv something from one place to another. It preserves the selinux context of the original when you move it, so if you untar something in /home or /tmp it gets given an selinux context that matches its location. Now you mv that to /var/www/html and it takes the context saying it belongs in /tmp or /home with it and httpd is not allowed by policy to access those files.
If you cp the files instead of mv them, the selinux context gets assigned according to the location you're copying to, not where it's coming from. Running restorecon puts the context back to its default and fixes it too.
我尝试过不同的情况，并且仅当所有者设置为 nginx 时（
chown -R nginx:nginx "/var/www/myfolder"） - 它开始按预期工作。I've tried different cases and only when owner was set to nginx (
chown -R nginx:nginx "/var/www/myfolder") - it started to work as expected.如果您使用 SELinux，只需键入：
这将解决权限问题。
If you're using SELinux, just type:
This will fix permission issue.
老问题，但我有同样的问题。我尝试了上面的每个答案，但没有任何效果。不过，对我来说解决这个问题的是删除域，然后再次添加它。我正在使用 Plesk，并且在域已经存在之后安装了 Nginx。
首先对 /var/www/backups 进行了本地备份。所以我可以轻松地复制回文件。
奇怪的问题....
Old question, but I had the same issue. I tried every answer above, nothing worked. What fixed it for me though was removing the domain, and adding it again. I'm using Plesk, and I installed Nginx AFTER the domain was already there.
Did a local backup to /var/www/backups first though. So I could easily copy back the files.
Strange problem....