On Wed, Mar 21, 2012 at 01:10:19PM -0400, maverick78 wrote:
My files are located in /www/example.com/public. This is set as document
root in nginx server block.
That is relevant for files that nginx needs to touch.
In my pool of php-fpm I set a chroot path.
chroot = /www/example.com
That means that the filesystem from the perspective of your fastcgi
server is not the same as the filesystem from the perspective of nginx.
That’s why I have to set another path to document_root in my location
block for php-files.
In general, nginx doesn’t need to touch the php files, so it doesn’t
care what “root” is set to. Except that the “default” values for some
important fastcgi_param parameters are based on what “root” is set to.
it can matter there.
You must ensure that “fastcgi_param SCRIPT_FILENAME” is the name of the
file from the perspective of the fastcgi server.
In your case, setting “root /public” achieves that. (There are other
For security reasons I want to check, if the called file with
php-extension really exists. For this purpose I want to use try_files.
But when I put try_files $uri =404; in the php location block, I always
get an 404 error for php-files.
In general, nginx cannot know whether a file exists on your upstream
server; so this try_files cannot be the correct solution. In this case,
where the fastcgi server is (presumably) sharing a filesystem with the
nginx server, then it can work.
$uri is the filename that nginx would look for from the perspective
of nginx – which in this case is rooted at /public (because of your
configuration). That file does not exist, so try_files correctly fails
to find it.
You must tell try_files the name of the file that you want to check for
which in this case is presumably /web/example.com$uri.
Use that in your try_files directive
I think nginx cant find the right path because of the chroot setting in
php-fpm. Is the a way to get around this?
You need to tell try_files the nginx-based file to look for, and
fastcgi_param the php-fpm-based file to look for.
The above should do that. (Untested.)
Francis D. [email protected]