I got error message:
FastCGI sent in stderr: \"Unable to open primary script: /home/messi/web/wordpress/index.php (No such file or directory)\" while reading r
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; ->
fastcgi_param SCRIPT_FILENAME/home/messi/web/wordpress$fastcgi_script_name;
SELinux will cause this error on CentOS/RHEL 7+ by default :(
To test if SELinux is the source of your woes, do
setenforce 0
... and see if everything works. If that fixed it, you can leave SELinux off (weak, you're better than that), or you can turn it back on with
setenforce 1
... and then properly fix the issue.
If you do
tail -f /var/log/audit/audit.log
... you'll see the SELinux issue. In my case, it was denying PHP-FPM access to web files. You can run the following directives to fix it:
setsebool -P httpd_can_network_connect_db 1
setsebool -P httpd_can_network_connect 1
This actually didn't fix it for me at first, but then restoring SELinux context did it
restorecon -R -v /var/www
Hope that helps.
It was SELinux in my case as well. I read some documentation found here:
https://wiki.centos.org/HowTos/SELinux
https://linux.die.net/man/1/chcon
and ended up with the command:
chcon -R -v --type=httpd_sys_content_t html/
....this changed the context of the files to the httpd type which is what my web server (Nginx) was running as.
You can find what context your web server runs as using:
ps axZ | grep nginx
....which in my case gave me:
system_u:system_r:**httpd_t**:s0 6246 ? Ss 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
system_u:system_r:**httpd_t**:s0 6249 ? S 0:00 nginx: worker process
Seeing the context of the running service was httpd_t I changed the context of my web site's root folder to that (recursively)
The point of SELinux is to only allow services and processes to access files of the same type as them. Since the web server ran as httpd_t than it made sense to set the context of the files/folder in the site to the same.
I'm new at this by the way.... But this seemed to be the best approach to me. It kept SELinux enabled, didn't lessen the security of what it does, nad matched up context of the files with the process/service.
This is likely a permissions problem.
Make sure that every parent directory has +x permissions for the user (the nginx user and/or php-fpm user).
You can check these permissions with: namei -om /path/to/file
.
If you have symlinks, make sure they point to a valid path.
Make sure chroots have access to the right paths.
Make sure SELinux (e.g. Fedora / Centos) or AppArmor (e.g. Ubuntu) or any other MAC security systems are not interfering with the file access.
For SeLinux: Check /var/log/audit/audit.log or /var/log/messages
For AppArmor: Im not a Ubuntu user and as far as I understand the logging for AppArmor isnt always easy to figure out. You might check here for info: http://ubuntuforums.org/showthread.php?t=1733231