Fix “No Input File Specified” on Nginx with PHP-FPM
The “No input file specified” message usually means PHP-FPM cannot find or access the PHP script that Nginx is asking it to run. Check the requested file path, Nginx’s FastCGI parameters, and filesystem permissions; correct the mismatch and reload the affected services.
What You’ll Need
- SSH access to the server and permission to edit Nginx and PHP-FPM configuration.
- The site’s document root, such as
/var/www/example/public, and the PHP-FPM socket or TCP address. - A way to back up configuration files and run syntax checks before applying changes.
Step-by-Step
- Confirm which URL and script fail. Note the full URL, whether the error affects every PHP page or only one route, and the time it occurred. Check that the expected script exists on the server. For example, if the URL is
https://example.test/index.php, confirm the actual file is present in the site’s document root. Do not assume the document root from the domain name; read it from the active Nginx server block. - Find the active Nginx server block. Inspect the site configuration and the Nginx configuration dump. Common locations include
/etc/nginx/sites-available/and/etc/nginx/conf.d/, but layouts differ. Runsudo nginx -Tto print the configuration Nginx currently loads, then identify the matchingserver_nameand itsrootdirective. If the hostname is handled by a different server block, edits to another block will not fix the problem. - Check the document root and file location. Compare the
rootpath with the real location of the site’s entry script. A typical configuration might useroot /var/www/example/public;, with the script at/var/www/example/public/index.php. Correct the root if it points to the wrong directory. Check spelling and capitalization: Linux paths are case-sensitive. If the site is deployed in a release directory or uses a symlink, verify that the configured path resolves to the intended files. - Review PHP handling in the server block. A common pattern is a PHP location that passes requests to PHP-FPM and sets the script filename from Nginx’s document root and request URI. For example:
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
Use the actual socket or address for your PHP-FPM pool. Distribution-provided include files may already setSCRIPT_FILENAME; inspect them before adding another definition. The final value must resolve to the real PHP file, not merely to a URL or directory. - Check the FastCGI path variables. A frequent cause is a wrong
root, an incorrectaliassetup, or aSCRIPT_FILENAMEvalue that combines incompatible paths. Withroot, Nginx appends the URI path to the root. Withalias, path construction works differently, so a generic$document_root$fastcgi_script_nameexpression may point to the wrong place. For an aliased PHP location, configure and verify the script path specifically for that layout. Avoid broad PHP execution rules that allow nonexistent files to be handed to PHP-FPM. - Verify the PHP-FPM endpoint and pool settings. Check the configured
fastcgi_passagainst the pool’slistensetting. A Unix socket path must match exactly; for TCP, both sides must use the same address and port. Confirm PHP-FPM is running using the service name used on your system, for examplesystemctl status php-fpmor a versioned service name. A bad endpoint often produces a connection error rather than this exact message, but it is important to validate while diagnosing the handoff. - Check permissions along the complete path. The PHP-FPM worker needs permission to read the script and traverse each parent directory. Inspect ownership and modes with
namei -l /var/www/example/public/index.php. Grant only the access the site requires; do not usechmod -R 777. If the file exists but access is denied, correct the relevant owner, group, or directory permissions according to the pool’s configured user and group. - Test, reload, and retest. Back up the file before editing. Run
sudo nginx -t; fix any reported errors before applying changes. Reload Nginx withsudo systemctl reload nginx. If you changed PHP-FPM pool configuration, test or restart that service using the system’s appropriate service name. Request the failing URL again, then inspect the Nginx error log and PHP-FPM log if the error remains.
Common Mistakes
- Editing a server block that is not active for the requested hostname, or overlooking a duplicate
server_name. - Using a project directory as the document root when the public web directory is a subfolder.
- Copying a PHP configuration example with a socket path that does not exist on the server.
- Adding duplicate or conflicting
SCRIPT_FILENAMEparameters without checking included FastCGI files. - Assuming permissions are correct because the PHP file itself is readable; parent directories also need traversal permission.
- Reloading without running
nginx -t, or changing files without confirming which configuration Nginx loads.
Tips
- Use
nginx -Tto inspect the merged, active configuration rather than relying only on a file you expect to be enabled. - Temporarily log or inspect the resolved script path when necessary, but remove diagnostic settings after the issue is solved.
- Keep a known-good backup and make one configuration change at a time. That makes it easier to identify which correction resolved the error.
- Do not expose PHP source files as static downloads while changing PHP location rules. Test with a harmless, non-sensitive script and remove it afterward.
Troubleshooting
The script exists, but the error continues: Compare its absolute path with the value Nginx sends as SCRIPT_FILENAME. Recheck for a mismatched root, alias, URI rewrite, symlink, or letter case. Look at the matching Nginx and PHP-FPM logs at the time of the request.
Only routes without a .php suffix fail: The application may rely on a front controller such as index.php. Check the site’s intended rewrite rules and confirm the fallback targets an existing script. Do not pass arbitrary request paths to PHP-FPM; route requests only to the application’s intended entry point.
The error changed after editing: A connection failure suggests Nginx cannot reach the configured PHP-FPM socket or address. A 403 or permission message points toward access controls; a 404 suggests the request is not mapping to the expected file. Use the exact log entry rather than treating every PHP error as the same problem.
Configuration tests pass but the site still fails: Confirm the request reaches this server and the intended virtual host, then check logs again after reproducing it. In managed hosting or containers, the web server and PHP-FPM may see different filesystem paths; ensure the script is mounted and located consistently for both services.
Frequently Asked Questions
What does “No input file specified” mean?
PHP-FPM received a request to execute a script path it could not resolve or read. The path may be wrong, missing, or inaccessible.
Is this usually an Nginx or PHP-FPM problem?
It is often a mismatch between Nginx’s FastCGI script path and the filesystem visible to PHP-FPM. Check both configurations and the actual file.
Should I set cgi.fix_pathinfo=0?
That setting may be appropriate for a PHP-FPM setup, but it does not correct an incorrect script filename, document root, or permission. Fix and verify the path first.
Can incorrect permissions cause this message?
Yes. The PHP-FPM worker must be able to read the script and traverse every directory in its path. Check the pool’s user and group before changing permissions.
Do I need to restart both services?
Reload Nginx after a valid Nginx configuration change. Restart or reload PHP-FPM when its pool configuration changes; a simple file-path correction may not require an FPM restart.
Where should I look for more detail?
Check the error log configured for the matching Nginx server block and the PHP-FPM pool log or system journal. Log locations and service names vary by system.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.