• 8
name Punditsdkoslkdosdkoskdo

Nginx 1 FastCGI sent in stderr: “Primary script undisclosed”

My first time using Nginx, but I am more than familiar with Apache and Linux. I am using an existing project and when ever I am trying to see the index.php I get a 404 File not found.

Here is the access.log entry:

2013/06/19 16:23:23 [error] 2216#0: *1 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client:, server: localhost, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://", host: "www.ordercloud.lh"

And here is the sites-available file:

server {
    set $host_path "/home/willem/git/console/www";
    access_log  /www/logs/console-access.log  main;

    server_name  console.ordercloud;
    root   $host_path/htdocs;
    set $yii_bootstrap "index.php";

    charset utf-8;

    location / {
        index  index.html $yii_bootstrap;
        try_files $uri $uri/ /$yii_bootstrap?$args;

    location ~ ^/(protected|framework|themes/w+/views) {
        deny  all;

    #avoid processing of calls to unexisting static files by yii
    location ~ .(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ {
        try_files $uri =404;

    # pass the PHP scripts to FastCGI server listening on
    location ~ .php {
        fastcgi_split_path_info  ^(.+.php)(.*)$;

        #let yii catch the calls to unexising PHP files
        set $fsn /$yii_bootstrap;
        if (-f $document_root$fastcgi_script_name){
            set $fsn $fastcgi_script_name;

        include fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fsn;

        #PATH_INFO and PATH_TRANSLATED can be omitted, but RFC 3875 specifies them for CGI
        fastcgi_param  PATH_INFO        $fastcgi_path_info;
        fastcgi_param  PATH_TRANSLATED  $document_root$fsn;

    location ~ /.ht {
        deny  all;

My /home/willem/git/console is owned by www-data:www-data (my web user running php etc) and I have given it 777 permissions out of frustration...

My best guess is that something is wrong with the config, but I can't figure it out...

UPDATE So I moved it to /var/www/ and used a much more basic config:

server {
    #listen   80; ## listen for ipv4; this line is default and implied
    #listen   [::]:80 default ipv6only=on; ## listen for ipv6

    root /var/www/;
    index index.html index.htm;

    # Make site accessible from http://localhost/
    server_name console.ordercloud;

    location / {
        root           /var/www/console/frontend/www/;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /var/www;
            include        fastcgi_params;

    location ~ .(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ {
            try_files $uri =404;

    location /doc/ {
        alias /usr/share/doc/;
        autoindex on;
        deny all;


Also if I call localhost/console/frontend/www/index.php I get a 500 PHP which means it is serving there. It just isn't serving off console.ordercloud ...

Ok, so 3 things I found after a day of struggling

  1. For some reason I had already something running on port 9000 so I changed to 9001
  2. My default site was intercepting my new one, once again I don't under stand why since it shouldn't, but I just unlinked it
  3. Nginx doesn't automatically do the sym link for sites-available to site-enabled.

Hope this saves someone some trouble!

  • 1
Reply Report

It's not always that the SCRIPT_FILENAME is wrong.
It may also be PHP is running as the wrong user/group.

This example is specific to Mac OS X, which in my experience is the most troublesome to setup (Debian is easy by comparison) - I've just upgraded from PHP 5.6 to 7.0, using homebrew and the excellent josegonzalez packages.

The problem was that a new copy of the config files was created.

The main config file is /usr/local/etc/php/7.0/php-fpm.conf, but note the Pool Definitions section at the end where it includes a whole subdirectory.


In php-fpm.d there's a www.conf file. By default this has:

user = _www
group = _www

On OS X, you may need to change this to:

user = [your username]
group = staff

(you should find this matches an ls -lh of your document_root)

Unfortunately without this change, you will still see this in your Nginx error log even if it's looking for the file in the correct place.

"Primary script unknown" while reading response header from upstream

Verify what it's currently running as:

ps aux | grep 'php-fpm'

or more cleanly:

ps aux | grep -v root | grep php-fpm | cut -d  -f1 | sort | uniq

How to verify if the script filename is correct:

(stolen from igorsantos07 in the other answer)

Add to http block of main /usr/local/etc/nginx/nginx.conf:

log_format scripts '$document_root$fastcgi_script_name > $request';

(where the first bit needs to be whatever you're currently using, so you can see if it's right.)

And to use the log you've just defined, in your site's server block:

access_log /var/log/nginx/scripts.log scripts;

If it's correct, requesting will produce something like this:

/path/to/docroot/phpinfo.php > GET /phpinfo.php

Can you simplify your existing config?

Are you using a location ~ .php { block you copied/pasted from somewhere off the internet? Most packages allow you to do it more quickly and cleanly. e.g. on OS X you now just need this:

location ~ .php {
    include snippets/fastcgi-php.conf;

    # any site specific settings, e.g. environment variables

Things like fastcgi_split_path_info, try_files and fastcgi_index (defaults to index.php) are in /usr/local/etc/nginx/snippets/fastcgi-php.conf.

That in turn includes /usr/local/etc/nginx/fastcgi.conf which is a list of fastcgi_param settings, including the crucial SCRIPT_FILENAME.

Don't ever duplicate root in the PHP location block.

  • 1
Reply Report

The error message “primary script unknown” is almost always related to a wrongly set SCRIPT_FILENAME in the nginx fastcgi_param directive (or incorrect permissions, see other answers).

You’re using an if in the configuration you posted first. Well it should be well known by now that if is evil and often produces problems.

Setting the root directive within a location block is bad practice, of course it works.

You could try something like the following:

server {
    location / {
        location ~* .php$ {
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            try_files $uri @yii =404;
    location @yii {
        fastcgi_param SCRIPT_FILENAME $document_root$yii_bootstrap;

Please note that the above configuration is untested. You should execute nginx -t before applying it to check for problems that nginx can detect right away.

  • 2
Reply Report

Related Questions

Trending Tags