I'm trying to set up a freshly installed Ubuntu (12.04) server, but I can't get PHP files running through php-fpm. No matter what I do, I always get a "Access denied." page (plain text, not html or anything).

Installed packages:


Configuration details:


user = www-data
group = www-data
listen = /var/run/php5-fpm.sock


user www-data;
worker_processes 3;
events { worker_connections 1024; }

Default/test domain:

server {
    listen       80;
    server_name  localhost;
    root         /extra/htdocs/default;
    index        index.html index.php

    access_log   /extra/logs/default/access.log;
    error_log    /extra/logs/default/error.log;

    location / {
        try_files  $uri $uri/ /index.html;

    location ~ \.php
        fastcgi_split_path_info  ^(.+\.php)(/.+)$;

        include fastcgi_params;

        fastcgi_index   index.php;
        fastcgi_pass    unix:/var/run/php5-fpm.sock;
        fastcgi_param   PATH_INFO         $fastcgi_path_info;
        fastcgi_param   PATH_TRANSLATED   $document_root$fastcgi_path_info;
        fastcgi_param   SCRIPT_FILENAME   $document_root$fastcgi_script_name;



Everything else is default. Both the Nginx and php-fpm logs show no errors. Yet when I load http://<server-ip>/index.php I get the "Access denied" page.


  • The index.html file works just fine. Therefore it must be either php-fpm, or the fastcgi binding between Nginx and php-fpm.
  • I've set the ownership (both user and group) of the entire /extra directory to www-data, and ownership to 777, just to be sure (I'll tone it down once it works of course). So it's certainly not a permissions issue
  • It's not the security.limit_extensions issue that I see a lot: by default that is set to .php, which is exactly what I'm requesting. I've explicitly set it to .php .html, with the same result.

I'm really getting tired of this, I've installed this setup twice already (albeit on OSX machines), and everything worked flawlessly. Is there anything I'm overlooking?

The log contents:

The Nginx error log is empty.

Nginx access log (removed ip):

<ip> - - [17/Jul/2012:11:21:25 +0200] "GET /favicon.ico HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11"
<ip> - - [17/Jul/2012:11:21:28 +0200] "GET /index.php HTTP/1.1" 403 46 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11"
<ip> - - [17/Jul/2012:11:21:34 +0200] "-" 400 0 "-" "-"

php-fpm log:

[17-Jul-2012 10:44:14] NOTICE: fpm is running, pid 4969
[17-Jul-2012 10:44:14] NOTICE: ready to handle connections

2 Answers 2


Finally fixed it.

The culprit was this line in my config:

fastcgi_param   PATH_TRANSLATED     $document_root$fastcgi_path_info;

If I commented this line, everything worked fine. However I saw this in almost every post I read about Nginx configs, so it bothered me. When looking at my configs for the millionth time, I saw that cgi.fix_pathinfo (in php.ini) was set to 0, where it should have been 1. The default value PHP uses is also 1, so I must have changed this in my debugging hours, because I remember reading about this value, and thought it was set correct.

Anyway, maybe it helps anyone Googling for this issue.

  • 5
    Thanks for sharing the solution. It's recommended not to trust the tutorials as those tutorials may contains unsecured configurations. Those configurations may still work correctly, though. Jul 18, 2012 at 1:57
  • Thanks for the link, I came across that a couple of times and have applied those instructions. The mistake was probably my own in my debugging rage (after x hours you start to lose track of some of the things you have altered). Jul 18, 2012 at 8:00
  • Mine was a chown issue. Aug 4, 2012 at 2:52
  • Thank you so much. Been working on this problem for hours and cgi.fix_pathinfo set to 0 (default configuration) was the problem. Jul 23, 2014 at 18:28
  • 2
    cgi.fix_pathinfo = 0 is recommended by a lot of tutorials because it helps mitigate vulnerabilities, specifically vulnerabilities executing php code through arbitrary files. So if you do set this to 1 make sure you know what you are doing or specify other mitigations to make up for it. I found this post to have a good explanation on the issue: nealpoole.com/blog/2011/04/…
    – MikeD
    May 23, 2019 at 22:23

On Ubuntu and openSUSE, the access denied error could also be related to AppArmor. You can easily check this by running:

sudo grep -i denied /var/log/audit/audit.log

If you get something like this, it's AppArmor:

type=AVC msg=audit(1678543274.258:837): apparmor="DENIED" operation="open" profile="php-fpm" name="/srv/www/htdocs/test.php" pid=31787 comm="php-fpm" requested_mask="r" denied_mask="r" fsuid=487 ouid=1000

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .