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.
ProtectHome=truewhich restricts access to files located within
/run/user, yielding the error message
No input file specified.
- To fix this problem, either set
php-fpm.servicefile 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.
SCRIPT_FILENAME is wrong, it may also be PHP is running as the wrong user/group. I take a look on
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/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
ProtectHome=true then change it to
false or add the following:
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
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 “
- If true, the directories
/run/userare 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
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
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
This option is only available for system services and is not supported for services running in per-user instances of the service manager.