I am running a simple PHP based site using nginx. After a recent update of a number of system components, the site stopped working. When I try to access the site, I get a blank page with the text "File not found." The server logs tell me that

FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream

and the PHP log contains

- - 25/Jan/2020:17:18:50 +0100 "GET /index.php" 404 - 0.151 2048 0.00%

The nginx config is as follows.

# configuration file /etc/nginx/nginx.conf:

user http http;
worker_processes  1;

events {
    worker_connections  1024;

http {
    include       mime.types;
    default_type  application/octet-stream;

    types_hash_max_size 2048;
    types_hash_bucket_size 128;

    sendfile        on;

    keepalive_timeout  65;

    # some server blocks elided

    include /home/myuser/www/com.mydomain.conf;

# configuration file /etc/nginx/mime.types:
types {
application/A2L                    a2l;
# lots of types elided so as not to exceed post size limit

# configuration file /etc/nginx/fastcgi.conf:

fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;
fastcgi_buffers 16 16k; 
fastcgi_buffer_size 32k;

# configuration file /home/myuser/www/com.mydomain.conf:
server {
  listen 80;
  server_name mydomain.com;
  # enforce https
  return 301 https://$server_name$request_uri;

server {
    listen 443 ssl;
    server_name mydomain.com;

    client_max_body_size 16m;

    root /home/myuser/www/com.mydomain;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;

    location ~ \.php$ {
        try_files $uri $fastcgi_script_name =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_index index.php;
        fastcgi_pass unix:/run/php-fpm/php-fpm.sock;

nginx and php-fpm are running as user http and the index.php file is accessible by that user:

-rwxrwxr-x 1 http http 1,7K  8. Nov 10:40 /home/myuser/www/com.mydomain/index.php

I have ascertained that $document_root and $fastcgi_script_name are correct by passing them as SCRIPT_NAME for testing.

What am I doing wrong?

Edit: This is indeed looking like a permission problem, but I still don't understand it. If I move the content of the site to /usr/share/webapps/ for a test, it works. Unfortunately, that is not an option for production use. With the files in their intended (original) location, I can run things like sudo -u http php /home/myuser/www/com.mydomain/test.php and get the expected result. What could prevent php-fpm (or the socket) from accessing those files? open_basedir is not set.

  • Have you checked the php-fpm socket itself? If php got updated it might have a different name now. E.g php7.2-fpm.sock. Also check permissions of the socket. – esoroka Jan 26 at 16:12
  • $ ls -lah /run/php-fpm/php-fpm.sock srw-rw---- 1 http http 0 25. Jan 14:33 /run/php-fpm/php-fpm.sock – Heres Jan 26 at 16:29
  • Also ... would the error show up in the PHP log if the socket did not exist? I would think not, but then again, there's clearly something I don't understand here ;-) – Heres Jan 26 at 16:36
  • post your nginx.conf also. – esoroka Jan 27 at 4:54
  • replaced the server block with the config – Heres Jan 27 at 9:00

Aside from all the things that can go wrong in the interaction between nginx and php-fpm (discussed in multiple questions on this site), systemd allows for another pitfall, which turned out to be the culprit in this case.

The php-fpm.service unit file contained the ProtectHome=true directive. I was able to remedy this by running systemctl edit php-fpm.service and specifying

| improve this answer | |

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.