1

I know this is a common question, but I found no discussion matching exactly with my case.

nginx error log shows:

FastCGI sent in stderr: "Unable to open primary script: /usr/share/nginx/drupal7/index.php

But:

  1. this path is correct, this is the root of my website

  2. www-data has permission to access it (if I do su www-data then cat /usr/share/nginx/drupal7/index.php the file is displayed).

  3. both nginx root AND fpm/pool.d/myserver.conf chroot point to the same folder: /usr/share/nginx/drupal7

  4. www-data user and group have 660 access to this same folder into pool.d/myserver.conf

  5. ps -u www-data shows that it owns nginx and php5-fpm processes

  6. I do not have SElinux installed (as some discussions say it could be the problem)

So why can the www-data user can access my index.php but not FastCGI? Why does FastCGI try the correct path, but then say it doesn't exist?

womble
  • 96,255
  • 29
  • 175
  • 230
Giova
  • 143
  • 1
  • 1
  • 7

1 Answers1

1

You have a chroot set up. When the process is in chroot, the path from the root to the script is like this:

/index.php

So, you need to modify the paths used with the FastCGI script calls so that they don't include the full directory path to the script file.

Tero Kilkanen
  • 36,796
  • 3
  • 41
  • 63
  • thank you for your answer but i'm not sure to understand... i've read that chroot was to prevent cgi scripts from running outside of www root folder (for security reasons). am I right? if yes, does '/' value breaks the role of chroot? – Giova Aug 22 '15 at 22:19
  • Yes, chroot puts a roadblock in the way of scripts attempting to read files on the system outside of the chrooted directory. No, `/` does not break the role of chroot. – womble Aug 23 '15 at 05:04
  • `chroot` shows a modified filesystem to the applications inside the `chroot`. The `/index.php` that applications see inside the chroot is `/usr/share/nginx/drupal7/index.php` in reality. – Tero Kilkanen Aug 23 '15 at 08:30