Unexpected 404 response from php-fpm when file exists and is readable

Question

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 '20 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 '20 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 '20 at 16:36
what's your OS? Do you have SELinux enabled by any chance? Also check permissions on all parent directories. Check if listen directive of php-fpm changed. The config itself looks good, so i'm brainstorming here. Also would be good if you posted what was updated. The error you are getting is either permissions or incorrect path. So you gotta check all of these — esoroka, Jan 27 '20 at 17:41
I'm running Arch Linux, no SELinux enabled. Permissions all look good. Updates are a bit tricky because I can't say for sure when this stopped working and the service was probably not restarted after the update. Pretty sure that php (7.4.1-1 -> 7.4.2-1) (and constituents) falls into the range. nginx (1.16.1-1 -> 1.16.1-2) is also possible but unlikely. — Heres, Jan 28 '20 at 10:18
Listen directive has not changed. FWIW, if I comment out listen.owner, /run/php-fpm/php-fpm.sock is owned by root and I get a 503 on the page, so that all checks out. — Heres, Jan 28 '20 at 10:39

score 1 · Answer 1 · answered Jan 29 '20 at 13:24

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

[Service]
ProtectHome=false

Unexpected 404 response from php-fpm when file exists and is readable

1 Answers1