I'd like to get some answers or suggestions to my problem.
So I'm getting a simple error:

2014/02/16 12:01:43 [error] 7384#0: *1 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client:, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host: "localhost"

Firstly, my nginx configuration is well done (for me - i.e. it is working well). The only problem I have is with linux permissions to files/folders. I can't understand a situation I'm in. Ok, so here is some info needed:

  • my nginx works well, with PHP and mysql configured.
  • a user used for nginx is named "nginx"
  • index index.php index.html index.htm (nginx configuration for index directive)

Here is my problem:

I have a tree like: /home/user/

home dir is: root:root with 755
user dir is: user:user with 700

I created a file named index.php in /home/user/index.php. Nginx said (/var/log/nginx/error.log) that I have no permissions. Ok, I did "usermod -a nginx -G user" and changed permissions for "user" dir to: 750 (so now nginx belongs to user's group, and can read or execute contents of the user dir). Ok, this works but not in a 100% way. If I create now a file index.html, or index.htm - nginx works in a browser! wow! yeah.. now I want to create index.php, to write some code. Boom! The file was NOT FOUND. Hmmm, that's really interesting for me, what did I do wrong? The interesting fact is, if I change user dir permissions to: 755 (from 750), nginx sees index.php. If I understand correctly, nginx goes first through the "o" permissions into /home dir (r-x). Next it needs to go into "user" dir, and as nginx user is in user's group, so nginx can make a next step to use "g" permissions (user/ dir permissions) to come in. But what is making nginx can't see index.php (and sees index.html and .htm)?

Ok, maybe my knowledge has some bugs, but I need to ask, why does it happen?

  • This never happened to me. I am having in nginx.conf: user www-data; File owner is MyNonRootUser and Group is www-data, everything works fine. However I would suggest you to use ip sock instead of php-fpm.sock :) – Wiggler Jtag Feb 16 '14 at 12:18
  • Your error message is not a permissions issue. Post your server block. – Michael Hampton Feb 16 '14 at 14:03
  • @WigglerJtag a UNIX socket is more secure and faster than any IP socket. – Fleshgrinder Feb 16 '14 at 18:45
  • @MichaelHampton it is, because if you read his question again you'll notice that nginx and php-fpm are able to serve index.php if permissions are set to 755 (reading allowed for the rest of the world, which is php-fpm). See my answer. – Fleshgrinder Feb 16 '14 at 18:46
  • @Fleshgrinder You're true, I had some problems with unix socket, but maybe it was only my problem, because of not tweaked linux. I will try switching it back to unix socket and see if it is better than TCP/IP. – Wiggler Jtag Feb 16 '14 at 22:16

Well, the question is what are your file permissions?

Because you're running the php as a cgi, it probably needs the a +x for the group on the .php files, which it probably doesn't have int he normal case. And it doesn't that for displaying the .html, which is obviously only read, not executed.


Wanted to answer over at Stackoverflow, but your question was closed to fast, glad you moved it here.

Primary script unknown is reported by php-fpm and almost always a problem with the path that you pass (from nginx) to php-fpm. The process simply can't find any PHP file at that location. In your case it can't find the file because the php-fpm process doesn't have permissions to read the file. That's right, you don't need any execution permissions for a PHP script (unless it's a CLI entry point). The reason for this is simple, PHP scripts are not executed, they are parsed (read).

It's generally a good idea to use the same user/group for nginx, PHP, and php-fpm if it's your server and nobody else is messing around. Then apply the following permissions (assuming /var/www as root for all websites, which is best practice imho):

# Fix user and group for all directories and files.
$ chown -R www-data:www-data /var/www

# Fix directory permissions (incl. sticky bit for group).
$ find /var/www -type d -exec chmod 2770 {} \;

# Fix file permissions (incl. sticky bit for group).
$ find /var/www -type f -exec chmod 2660 {} \;

Now everything should be fine for anything that you execute with nginx, PHP, and php-fpm and that's below /var/www.


Try changing the permissions of the directory from where you serve your files to drwx--x--x (that's 711). This way the web server will be able to "cd" to this directory and read the php file (providing it has read permissions to it)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.