php Nginx 403 禁止所有文件
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/6795350/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Nginx 403 forbidden for all files
提问by Angus Ireland
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.
我在 CentOS 5 机器上安装了带有 PHP-FPM 的 nginx，但我正在努力让它为我的任何文件提供服务 - 无论是否为 PHP。
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.
Nginx 作为 www-data:www-data 运行，并且默认的“Welcome to nginx on EPEL”站点（由具有 644 权限的 root:root 拥有）加载正常。
The nginx configuration file has an include directive for /etc/nginx/sites-enabled/*.conf,and I have a configuration file example.com.conf, thus:
nginx 配置文件有一个包含/etc/nginx/sites-enabled/*.conf 的指令，我有一个配置文件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;
}
}
Despite public_html being owned by www-data:www-data with 2777 file permissions, this site fails to serve any content -
尽管 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"
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.
我发现了许多其他帖子，用户从 nginx 获得 403，但我看到的大多数帖子都涉及使用 Ruby/Passenger 进行更复杂的设置（过去我实际上已经成功了），或者仅在上游 PHP 时收到错误-FPM 涉及，所以他们似乎没有什么帮助。
Have I done something silly here?
我在这里做了什么傻事吗？
回答by kolbyHyman
One 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).
一个经常被忽视的权限要求是用户在文件的每个父目录中需要 x 权限才能访问该文件。检查 /、/home、/home/demo 等的权限以获取 www-data x 访问权限。我的猜测是 /home 可能是 770 并且 www-data 无法通过它 chdir 到达任何子目录。如果是，请尝试 chmod o+x /home （或任何拒绝请求的目录）。
EDIT: To easily display all the permissions on a path, you can use namei -om /path/to/check
编辑：要轻松显示路径上的所有权限，您可以使用 namei -om /path/to/check
回答by Kurt
If you still see permission deniedafter verifying the permissions of the parent folders, it may be SELinuxrestricting access.
如果permission denied验证了父文件夹的权限后仍然看到，可能是SELinux限制访问。
To check if SELinux is running:
要检查 SELinux 是否正在运行：
# getenforce
To disable SELinux until next reboot:
要在下次重新启动之前禁用 SELinux：
# setenforce Permissive
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)
重新启动 Nginx 并查看问题是否仍然存在。允许 nginx 为您的 www 目录提供服务（确保在测试之前重新打开 SELinux。即，setenforce Enforcing）
# chcon -Rt httpd_sys_content_t /path/to/www
See my answer herefor more details
回答by Anderson
I solved this problem by adding user settings.
我通过添加用户设置解决了这个问题。
in nginx.conf
在 nginx.conf 中
worker_processes 4;
user username;
change the 'username' with linux user name.
使用 linux 用户名更改“用户名”。
回答by jsina
I've got this error and I finally solved it with the command below.
我遇到了这个错误，我终于用下面的命令解决了它。
restorecon -r /var/www/html
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.
当您将某物从一个地方移动到另一个地方时，就会导致该问题。当您移动它时，它会保留原始的 selinux 上下文，因此如果您在 /home 或 /tmp 中解压缩某些内容，它会得到一个与其位置匹配的 selinux 上下文。现在你将它 mv 到 /var/www/html 并且它需要上下文说它属于 /tmp 或 /home 并且策略不允许 httpd 访问这些文件。
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.
如果您 cp 文件而不是 mv 它们，则 selinux 上下文将根据您复制到的位置而不是来自哪里来分配。运行 restorecon 将上下文恢复为默认值并修复它。
回答by Andron
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.
我尝试了不同的情况，并且只有当所有者设置为 nginx ( chown -R nginx:nginx "/var/www/myfolder") 时 - 它才开始按预期工作。
回答by David Ding
If you're using SELinux, just type:
如果您使用的是 SELinux，只需键入：
sudo chcon -v -R --type=httpd_sys_content_t /path/to/www/
This will fix permission issue.
这将解决权限问题。
回答by David
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.
老问题，但我有同样的问题。我尝试了上面的每个答案，没有任何效果。对我来说修复它的是删除域，然后再次添加它。我正在使用 Plesk，并且在域已经存在之后安装了 Nginx。
Did a local backup to /var/www/backups first though. So I could easily copy back the files.
不过，首先对 /var/www/backups 进行了本地备份。所以我可以轻松地将文件复制回来。
Strange problem....
奇怪的问题....
回答by Slavomir Miskovec
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:
我们有同样的问题，使用 Plesk Onyx 17。而不是搞乱权限等，解决方案是将 nginx 用户添加到 psacln 组，其中所有其他域所有者（用户）是：
usermod -aG psacln nginx
Now nginx has rights to access .htaccess or any other file necessary to properly show the content.
现在 nginx 有权访问 .htaccess 或任何其他正确显示内容所需的文件。
On the other hand, also make sure that Apache is in psaserv group, to serve static content:
另一方面，还要确保 Apache 在 psaserv 组中，以提供静态内容：
usermod -aG psaserv apache
And don't forget to restart both Apache and Nginx in Plesk after! (and reload pages with Ctrl-F5)
之后不要忘记在 Plesk 中重新启动 Apache 和 Nginx！（并使用 Ctrl-F5 重新加载页面）
回答by Francisco Zanatta
If you are using PHP, make sure the indexNGINX directive in the server block contains a index.php:
如果您使用的是 PHP，请确保index服务器块中的NGINX 指令包含一个 index.php：
index index.php index.html;
index index.php index.html;
For more info checkout the index directivein the official documentation.
有关更多信息，请查看官方文档中的index 指令。
回答by Harvey
I was facing the same issue but above solutions did not help.
我遇到了同样的问题，但上述解决方案没有帮助。
So, after lot of struggle I found out that sestatuswas set to enforce which blocks all the ports and by setting it to permissive all the issues were resolved.
因此，经过大量努力，我发现sestatus设置为强制执行哪些阻止所有端口，并通过将其设置为允许所有问题都得到解决。
sudo setenforce 0
Hope this helps someone like me.
希望这可以帮助像我这样的人。
