PHP-FPM: How to fix ‘Primary script unknown’ or ‘file not found’

by

I encountered this error yesterday after upgraded php-* packages then restart its service. All my websites were stopped working, I got ‘File not found.’ message on the screen and found the ton repeated of error messages in log of nginx Primary script unknown.

How to fix nginx Primary script unknown or file not found
Nginx/PHP-FPM: How to fix ‘Primary script unknown’ or ‘file not found’ issue

TL;DR:

  • Since php-fpm version 7.4.0 php-fpm.service defines ProtectHome=true which restricts access to files located within /home, /root and /run/user, yielding the error message No input file specified.
  • To fix this problem, either set ProtectHome=false in php-fpm.service file or move your document root.

The issue I’m facing after fully upgraded system, reboot my VPS:

  • Browsing to it in browser returns the text “File not found”.
  • nginx error.log contains:

    2019/12/17 15:36:09 [error] 1502#1502: *1 FastCGI sent in stderr: “Primary script unknown” while reading response header from upstream, …

The message is telling us that the FastCGI handler doesn’t like whatever it was sent for some reason. The problem is that sometimes we have no idea what the reason is. On my experience of using nginx, the error message Primary script unknown is almost always related to a wrongly set SCRIPT_FILENAME in the nginx fastcgi_param directive or incorrect permissions. It’s seem correctly answer when the php-fpm.service stopped working with error:

ERROR: failed to open configuration file ‘/etc/php/php-fpm.conf’: Permission denied (13)

I tried turns out that the root location had to match the location of the files on the php-fpm as that’s what was being past through via:

fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name

But it doesn’t work.
Well, if I remove my SCRIPT_FILENAME then all I get is an empty, white, blank page by nginx. No error messages either. It’s mean fastcgi_param is not cause of this problem.
If the SCRIPT_FILENAME is wrong, it may also be PHP is running as the wrong user/group. I take a look on php-fpm.conf, php-fpm.d/www.conf and double-checked for errors and inconsistencies. Everything is ok , no conflicted.
Just wait, I stored all LEMP’s config files in a folder then created symlinks of them to /etc/nginx/ and /etc/php folders. Everything was working fine before I upgraded php-fpm to version 7.4.0. After that, the PHP service only started when all the symbolic links were replaced by real files. Furthermore, my website has ‘file not found‘ error, it’s meaning the files on server is inaccessible. They were isolated.
So I’m seem to figure out what is causing this. It’s PHP-FPM service. It has ProtectHome set to true since 7.4.0!
This problem was caused by ProtectHome=true in the php-fpm systemd unit file if you are serving files in /home such as in a virtual host environment. You can disable this feature by editing the php-fpm unit file and restarting php-fpm. 

# systemctl edit php-fpm

Looking for ProtectHome=true then change it to false or add the following:

[Service]
ProtectHome=false

Alternatively, move your document root.
If you are not sure about the ProtectHome is existed, here is the command to check it is running:

$ sudo systemctl cat php-fpm.service | grep ProtectHome   
ProtectHome=true

Before restart php-fpm service, make sure to reload the systemd daemon:

$ sudo systemctl daemon-reload

It’s done. Everything is OK now.

What is ProtectHome?

Takes a boolean argument or the special values “read-only” or “tmpfs“.

  • If true, the directories /home, /root, and /run/user are made inaccessible and empty for processes invoked by this unit.
  • If set to “read-only“, the three directories are made read-only instead.
  • If set to “tmpfs“, temporary file systems are mounted on the three directories in read-only mode. The value “tmpfs” is useful to hide home directories not relevant to the processes invoked by the unit, while still allowing necessary directories to be made visible when listed in BindPaths= or BindReadOnlyPaths=.

Setting this to “yes” is mostly equivalent to set the three directories in InaccessiblePaths=. Similarly, “read-only” is mostly equivalent to ReadOnlyPaths=, and “tmpfs” is mostly equivalent to TemporaryFileSystem= with “:ro“.
It is recommended to enable this setting for all long-running services (in particular network-facing ones), to ensure they cannot get access to private user data, unless the services actually require access to the user’s private data. This setting is implied if DynamicUser= is set. This setting cannot ensure protection in all cases. In general it has the same limitations as ReadOnlyPaths=.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.