Ah01071 got error access to the script

I seem to be getting these lines in my /var/log/apache2/error.log and the corresponding records in /var/log/apache2/access.log

/var/log/apache2/error.log

[Fri Sep 20 02:28:36.654357 2019] [proxy_fcgi:error] [pid 28619:tid 140003157985024] [client 49.233.5.191:37604] AH01071: Got error 'Primary script unknownn'
[Fri Sep 20 02:28:38.136282 2019] [proxy_fcgi:error] [pid 28618:tid 140003082450688] [client 49.233.5.191:43806] AH01071: Got error 'Primary script unknownn'

/var/log/apache2/access.log

49.233.5.191 - - [20/Sep/2019:02:28:36 +0000] "GET /TP/html/public/index.php HTTP/1.1" 404 392 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0;en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6)"
49.233.5.191 - - [20/Sep/2019:02:28:36 +0000] "GET /elrekt.php HTTP/1.1" 404 433 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0;en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6)"

Those files obviously do not exist so this seems like a bot scan from the ip location and the behavior. However, when i request another file that does not exist. I do not get the ‘Got error ‘Primary script unknownn’ errors in the /var/log/apache2/error.log file

php-fpm configuration

<IfModule !mod_php7.c>
<IfModule proxy_fcgi_module>
    # Enable http authorization headers
    <IfModule setenvif_module>
    SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
    </IfModule>

    <FilesMatch ".+.ph(ar|p|tml)$">
        SetHandler "proxy:unix:/run/php/php7.2-fpm.sock|fcgi://localhost"
    </FilesMatch>
    <FilesMatch ".+.phps$">
        # Deny access to raw php sources by default
        # To re-enable it's recommended to enable access to the files
        # only in specific virtual host or directory
        Require all denied
    </FilesMatch>
    # Deny access to files without filename (e.g. '.php')
    <FilesMatch "^.ph(ar|p|ps|tml)$">
        Require all denied
    </FilesMatch>
</IfModule>
</IfModule>

Is this something that i can do something about, configuration change maybe?

I know i can block the ip using iptables, i am more interested in getting rid of the log entry if possible by some configuration change.

TL;DR: The permission problem is being introduced during composer update. Possibly during one of the scripts (a list of which can be found in composer.json).

I started from scratch on a VM with your repository and followed your startup instructions.

git clone https://github.com/reypm/symfony3app
cd symfony3app
docker-compose up -d --build --force-recreate

At this point, the chown from 20-permissions.sh should have been run. To verify that, I looked inside the container. The error I have seen related to /data/www/var/cache/dev, so I looked at the permissions on every directory in that path.

[my-vm]# docker-compose exec php-fpm bash
[container]# ls -la /data/www{,/var{,/cache{,/dev}}}

ls: cannot access /data/www/var/cache/dev: No such file or directory
/data/www:
total 168
drwxrwsr-x 8 apache root   4096 Jan 15 19:26 .
drwxr-xr-x 8 root   root   4096 Jan 15 19:27 ..
-rw-rw-r-- 1 apache root    248 Jan 15 19:26 .gitignore
-rw-rw-r-- 1 apache root     74 Jan 15 19:26 README.md
drwxrwsr-x 5 apache root   4096 Jan 15 19:27 app
drwxrwsr-x 2 apache root   4096 Jan 15 19:26 bin
-rw-rw-r-- 1 apache root   2387 Jan 15 19:26 composer.json
-rw-rw-r-- 1 apache root 119533 Jan 15 19:26 composer.lock
-rw-rw-r-- 1 apache root    978 Jan 15 19:26 phpunit.xml.dist
drwxrwsr-x 3 apache root   4096 Jan 15 19:26 src
drwxrwsr-x 3 apache root   4096 Jan 15 19:26 tests
drwxrwsr-x 4 apache root   4096 Jan 15 19:26 var
drwxrwsr-x 2 apache root   4096 Jan 15 19:26 web

/data/www/var:
total 52
drwxrwsr-x 4 apache root  4096 Jan 15 19:26 .
drwxrwsr-x 8 apache root  4096 Jan 15 19:26 ..
-rw-rw-r-- 1 apache root 34272 Jan 15 19:26 SymfonyRequirements.php
drwxrwsr-x 2 apache root  4096 Jan 15 19:26 cache
drwxrwsr-x 2 apache root  4096 Jan 15 19:26 sessions

/data/www/var/cache:
total 8
drwxrwsr-x 2 apache root 4096 Jan 15 19:26 .
drwxrwsr-x 4 apache root 4096 Jan 15 19:26 ..
-rw-rw-r-- 1 apache root    0 Jan 15 19:26 .gitkeep

So far, so good. The chown has set everything to apache:root and using the modes specified in the script.

Next, I exited the container and ran the composer update.

docker-compose exec php-fpm composer update

When prompted, I used the database parameters I found in the git repo, and everything installed fine. Next, I went back into the container to see if the permissions had changed.

[my-vm]# docker-compose exec php-fpm bash
[container]# ls -la /data/www{,/var{,/cache{,/dev}}}

/data/www:
total 164
drwxrwsr-x  9 apache root   4096 Jan 15 19:20 .
drwxr-xr-x  8 root   root   4096 Jan 15 19:18 ..
-rw-rw-r--  1 apache root    248 Jan 15 19:17 .gitignore
-rw-rw-r--  1 apache root     74 Jan 15 19:17 README.md
drwxrwsr-x  5 apache root   4096 Jan 15 19:18 app
drwxrwsr-x  2 apache root   4096 Jan 15 19:21 bin
-rw-rw-r--  1 apache root   2387 Jan 15 19:17 composer.json
-rw-rw-r--  1 apache root 114331 Jan 15 19:20 composer.lock
-rw-rw-r--  1 apache root    978 Jan 15 19:17 phpunit.xml.dist
drwxrwsr-x  3 apache root   4096 Jan 15 19:17 src
drwxrwsr-x  3 apache root   4096 Jan 15 19:17 tests
drwxrwsr-x  5 apache root   4096 Jan 15 19:21 var
drwxr-sr-x 25 root   root   4096 Jan 15 19:21 vendor
drwxrwsr-x  3 apache root   4096 Jan 15 19:21 web

/data/www/var:
total 96
drwxrwsr-x 5 apache root  4096 Jan 15 19:21 .
drwxrwsr-x 9 apache root  4096 Jan 15 19:20 ..
-rw-rw-r-- 1 apache root 34272 Jan 15 19:21 SymfonyRequirements.php
-rw-r--r-- 1 root   root 39637 Jan 15 19:21 bootstrap.php.cache
drwxrwsr-x 3 apache root  4096 Jan 15 19:21 cache
drwxr-sr-x 2 root   root  4096 Jan 15 19:21 logs
drwxrwsr-x 2 apache root  4096 Jan 15 19:17 sessions

/data/www/var/cache:
total 12
drwxrwsr-x 3 apache root 4096 Jan 15 19:21 .
drwxrwsr-x 5 apache root 4096 Jan 15 19:21 ..
-rw-rw-r-- 1 apache root    0 Jan 15 19:17 .gitkeep
drwxr-sr-x 4 root   root 4096 Jan 15 19:21 dev

/data/www/var/cache/dev:
total 636
drwxr-sr-x 4 root   root   4096 Jan 15 19:21 .
drwxrwsr-x 3 apache root   4096 Jan 15 19:21 ..
-rw-r--r-- 1 root   root     90 Jan 15 19:21 annotations.map
-rw-r--r-- 1 root   root 277718 Jan 15 19:21 appDevDebugProjectContainer.php
-rw-r--r-- 1 root   root  38062 Jan 15 19:21 appDevDebugProjectContainer.php.meta
-rw-r--r-- 1 root   root 213247 Jan 15 19:21 appDevDebugProjectContainer.xml
-rw-r--r-- 1 root   root  84170 Jan 15 19:21 appDevDebugProjectContainerCompiler.log
-rw-r--r-- 1 root   root   4790 Jan 15 19:21 classes.map
drwxr-sr-x 3 root   root   4096 Jan 15 19:21 doctrine
drwxr-sr-x 4 root   root   4096 Jan 15 19:21 pools

As you can see, some things are now owned by root:root. As far as I can tell, this is simply because the container itself runs things as root. So when you exec a job inside, that job is run as root. Therefore, anything it creates is, by default, owned by root.

Meanwhile, Apache runs as the user «apache», because that is what supervisord is configured to do.

There are probably more elegant fixes for this problem, but this one was the simplest one I came up with:

docker-compose exec php-fpm chown -R apache:root /data/www/var/cache
docker-compose restart php-fpm

After that, the app returns

Welcome to
Symfony 3.2.2

Your application is now ready. You can start working on it at: /data/www/

I haven’t tried to fix things any better than this. But my suggestion would be to try to have the startup run composer update for you and do the chown job after that. You probably don’t need to chown all of /data/www, as Apache probably doesn’t need write privs to everything in there. My guess was that the cache directory is one place it needs to write, so I chown’d that path.

Wondering how to fix AH01071: got error ‘primary script unknown’ in Plesk? We can help you.

Often our customers report to us that they found this error in the website error log after upgrading to Plesk Obsidian.

Here at Bobcares, we often handle requests from our customers to fix similar Plesk errors as a part of our Server Management Services. Today we will see how our support engineers fix this for our customers.

What causes AH01071: Got error ‘Primary script unknown’ in Plesk

Before going into the steps for fixing this error we will see what causes this error.

A typical error from the website error log looks like the one given below:

AH01071: Got error 'Primary script unknown' - Apache Error

Although all the services in the server run fine, we may see that the websites on php showing a “File not found” error.

Cause

Generally, this happens due to incorrect permissions on the domain’s folder.

Symptoms

Following are some of the symptoms that we notice with the error:

1. Unable to access File Manager for a certain domain or for all domains on a server:

Server Error
500 PleskUtilException
Internal error: Unable to find the directory /var/www/vhosts/example.com/: filemng failed: filemng: opendir failed: Permission denied System error 13: Permission denied

2. Not being able to execute actions on File Manager: such as ZIP extraction, Copy, Rename, Changing Permissions, etc.

3. Unable to connect via FTP to a domain main folder or a sub-folder with the following error:

4. Unable to connect FTP: 421 Service not available, remote server has closed.

4. Alternatively, it is not possible to add files to archive in Domains > example.com > File Manager > Add to Archive:

Unable to create the archive: filemng failed: filemng: /usr/bin/zip execution failed: zip warning: Permission denied zip warning: Permission denied zip warning: Permission denied zip warning: Permission denied zip warning: Permission denied zip warning: Permission denied.

Next, we will see how to fix this error either from Plesk GUI or via SSH.

How to fix AH01071: got error ‘primary script unknown’ in Plesk

Now we will see the steps that our Support Engineers follow to fix this issue for our customers.

Plesk GUI

1.  First, Log in to Plesk GUI

2. Then we have to install the Repair Kit extension

3. For this we can go to Tools & Settings > Diagnose & Repair > File System > Repair

 SSH

1. First, we have to connect to the server via SSH

2. Then run the following command to repair file permissions:

# plesk repair fs -y example.com

To fix permissions for all the domains:

# plesk repair fs -y

[Still, stuck with the error? We can help you]

Conclusion

In short, we saw how our Support Techs fix AH01071: got error ‘primary script unknown’ in Plesk for our customers.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;