Home > Enterprise >  I get FastCGI "Primary script unknown" error in a NGINX / PHP-FPM containers situation
I get FastCGI "Primary script unknown" error in a NGINX / PHP-FPM containers situation

Time:03-16

Context

I've got these two docker containers connected to a network:

  • php:8-fpm-alpine with my web app, exposing port 9000.
  • nginx:alpine serving the app.

Both containers have access to a local directory containing the app files.

My NGINX configuration:

server {
    listen 80;
    index index.php index.html;
    error_log  /var/log/nginx/error.log;
    access_log /var/log/nginx/access.log;
    root /usr/share/nginx/html;

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(. \.php)(/. )$;
        fastcgi_pass app:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;
        gzip_static on;
    }
}

Problem

When trying to access the site, the browser shows "File not found.".

NGINX container logs:

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

PHP-FPM container logs:

"GET /index.php" 404

Things I've checked

  • App is running.
  • root in NGINX config actually points to where the app files are.
  • App directory, inside the app container, has at least public read and execute rights all the way through, which should rule out access issues... right?
  • There is no other container in the network blocking port 9000.

Could you please point me in some direction? I'm lost.

CodePudding user response:

The NGINX container can see that the file exists at /usr/share/nginx/html/index.php otherwise the try_files statement would be generating the 404 response rather than PHP-FPM.

So the PHP-FPM container has received the request with SCRIPT_FILENAME set to /usr/share/nginx/html/index.php but PHP cannot see the file using that pathname.

As your comment confirms, this is a discrepancy in the pathname routes between the two containers.

  • Related