Nginx的403禁止所有文件

我在CentOS 5盒子上安装了PHP-FPM的nginx,但是我正努力让它为我的任何文件服务 – 无论是否PHP。

Nginx以www-data:www-data的forms运行,默认的“EPEL欢迎使用nginx”站点(拥有644权限的root用户)加载正常。

nginxconfiguration文件有一个include指令/etc/nginx/sites-enabled/*.conf,我有一个configuration文件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; } } 

尽pipepublic_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获得403s,但是我所看到的大部分都涉及到Ruby / Passenger的更复杂的设置(过去我实际上已经成功了),或者只有在上游PHP -FPM参与,所以他们似乎没有什么帮助。

我在这里做了些傻事吗?

一个经常被忽略的权限要求是用户需要在文件的每个父目录中访问该文件的权限。 检查/,/ home,/ home / demo等的www-data x access权限。 我的猜测是/ home可能是770,www-data无法通过它来获取任何subdir。 如果是,请尝试chmod o + x / home(或任何目录拒绝请求)。

编辑:要轻松显示path上的所有权限,您可以使用namei -om /path/to/check

如果您在validation父文件夹的权限后仍然看到permission denied ,则可能是SELinux限制访问权限。

要检查SELinux是否正在运行:

 # getenforce 

要在下一次重新启动之前禁用SELinux:

 # setenforce Permissive 

重新启动Nginx,看看问题是否存在。 为了让nginx能够为你的www目录服务(确保你在testing之前重新打开SELinux,例如setenforce Enforcing

 # chcon -Rt httpd_sys_content_t /path/to/www 

在这里看到我的答案更多的细节

我通过添加用户设置来解决这个问题。

在nginx.conf中

 worker_processes 4; user username 

用linux用户名更改“用户名”。

我已经尝试了不同的情况,只有当所有者被设置为nginx( chown -R nginx:nginx "/var/www/myfolder" )时,才开始按预期工作。

我有这个错误,我终于用下面的命令解决了它。

 restorecon -r /var/www/html 

这个问题是由你从一个地方转移到另一个地方时造成的。 当你移动它时,它会保留原始的selinux上下文,所以如果你在/ home或/ tmp中解压一些东西,它会得到一个和它的位置相匹配的selinux上下文。 现在,你mv到/ var / www / html,它需要上下文说它属于/ tmp或/ home,并且httpd不被策略允许访问这些文件。

如果你使用cp文件而不是mv文件,selinux上下文将根据你正在复制的位置得到分配,而不是来自哪里。 运行restorecon会将上下文恢复为默认值并修复它。

通过错误地运行setfacl命令,我在这个问题上挖了一个小小的变种。 我跑了:

 sudo setfacl -m user:nginx:r /home/foo/bar 

为了将nginx添加到foo组中,我放弃了这条路线,但是这个自定义ACL阻止了nginx尝试访问该文件。 我通过运行清除它:

 sudo setfacl -b /home/foo/bar 

然后nginx能够访问这些文件。

老问题,但我有同样的问题。 我试过上面的每个答案,没有任何工作。 什么解决了我虽然是删除域名,并再次添加。 我正在使用Plesk,并且在域已经存在之后,我安装了Nginx。

虽然有一个本地备份到/ var / www /备份。 所以我可以轻松地复制文件。

奇怪的问题….

我们遇到同样的问题,使用Plesk Onyx 17.与其解决权限等问题,解决scheme是将nginx用户添加到psacln组中,其中所有其他域所有者(用户)都是:

 usermod -aG psacln nginx 

现在,nginx有权访问.htaccess或任何其他正确显示内容所必需的文件。

另一方面,也要确保Apache在psaserv组中,以提供静态内容:

 usermod -aG psaserv apache 

不要忘记在Plesk中重启Apache和Nginx! (并用Ctrl-F5重新加载页面)