Every PHP request through Nginx to PHP-FPM returns 'File not found.'; what does SCRIPT_FILENAME do, and what usually went wrong?

## Who decides which file runs In a web-server-plus-PHP-FPM setup, the **web server** receives the HTTP request and decides it is a PHP request; **PHP-FPM** only runs what it is told. The FastCGI protocol carries the request as a set of parameters (like CGI environment variables), and the one that names the script is **`SCRIPT_FILENAME`**: an absolute path to the PHP file to execute. With Nginx, the PHP manual's example location is: ```nginx location ~* \.php$ { fastcgi_index index.php; fastcgi_pass 127.0.0.1:9000; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param SCRIPT_NAME $fastcgi_script_name; } ``` `$document_root` is the server's `root` and `$fastcgi_script_name` the URI's script part, so `/index.php` under `root /srv/app/public` becomes `/srv/app/public/index.php`. With Apache httpd 2.4, `mod_proxy_fcgi` builds the parameter itself, prefixed with `proxy:fcgi://host:port`; PHP-FPM recognises that prefix (and `proxy:balancer://`) and strips it to recover the file path. ## Reading FPM's answers PHP-FPM checks the script before running it, and each failure has its own response body and status: | Response body | Status | Cause | |---|---|---| | `File not found.` | 404 | No usable script path: the parameter is missing, or (with the default `cgi.fix_pathinfo=1`) neither the path nor any parent of it is an existing file where FPM runs; FPM logs `Primary script unknown`, which the web server shows in its error log | | `No input file specified.` | 404 | A path was accepted but opening it failed for a reason other than permissions — for example a missing file with `cgi.fix_pathinfo=0`; FPM logs `Unable to open primary script` | | `Access denied.` | 403 | The file exists but the pool user cannot read it | | `Access denied.` | 403 | The extension is not allowed by `security.limit_extensions`; FPM logs `Access to the script '…' has been denied (see security.limit_extensions)` | ## The usual culprits 1. **Parameter missing.** The PHP location includes a params file that does not set `SCRIPT_FILENAME`, or the line was lost in a refactor. Result: `Primary script unknown` and `File not found.` for every request — the same symptom as a path that does not exist. 2. **Wrong root.** `$document_root` is inherited from a different `root` than expected, so the path points to a non-existent directory. 3. **Different file systems.** Nginx and FPM in separate containers: Nginx has the code at `/usr/share/nginx/html`, FPM at `/var/www/html`. The path must be the one **FPM** sees — often it is hard-coded in the parameter, or both containers mount the code at the same path. 4. **chroot.** A pool with `chroot` sees paths relative to the jail, so a path valid on the host fails inside it. 5. **Permissions.** The pool's `user` cannot traverse a parent directory or read the file: `Access denied.` with 403. ## security.limit_extensions `security.limit_extensions` (default `.php`) restricts which file extensions FPM will execute as the main script, matched against the end of the path. Its purpose, per the sample configuration, is to prevent configuration mistakes on the web-server side from letting users run other files as PHP. The classic attack: an uploaded `avatar.jpg` containing PHP code, requested as `/uploads/avatar.jpg/x.php`; with a loose web-server rule and PHP's path-info fixing, the script path could resolve to the `.jpg` file. With the default setting FPM refuses it with 403. Keep it at `.php` unless an application genuinely needs another extension; an empty value allows everything. ## A checklist when PHP pages fail - Look at the **body** and **status**: they tell you which check failed. - Read the web server's error log for `Primary script unknown` and FPM's log for `Unable to open primary script` or the `limit_extensions` notice. - Log the parameter value temporarily (for example with a custom access-log format in the web server) and verify the file exists **inside FPM's environment** with `ls -l` as the pool user. - Check that non-PHP static files are served by the web server directly and never passed to FPM. ## Why the split matters Because the web server chooses the file, a mistake there can run the wrong code — or, if FPM is reachable directly, anyone can choose the file. FPM's checks (existence, readability, allowed extension) are the last line; a correct `SCRIPT_FILENAME` built from a fixed document root is the first.