Have you tried to give the named user write access to the config folder?

(And to the cache/tmp folder aswell)

Yes, the user has write access to the folders. I just tested that

It should definitely fire the installer in that case unless you are on CLI? I assume that's not the case as you say navigate to your browser.

Maybe it thinks for some reasons that you are on CLI that would be pretty much the only explanation for me.

In core/Common.php around line 130 could you change the function isPhpCliMode like this:

public static function isPhpCliMode()
    {
return false;
}

This at least caused the script to show the installer but now it complains (it shows a red warning) that my browser isn't able to load scripts and stylesheets. It just presents me with a plain html page.

That might be some other server issue. I see you are using Nginx, maybe try this config here? https://github.com/matomo-org/matomo-nginx/ not sure if it helps. But for such server issues the forum be the best: https://forum.matomo.org and a google search for matomo and not loading scripts or stylesheet might help as well.

In case you are familiar with PHP, could you check which of the two checks result in true meaning where it falsely detects your system is in cli mode? https://github.com/matomo-org/matomo/blob/3.9.0-b3/core/Common.php#L134-L140

eg does it still show the installer when you do

  public static function isPhpCliMode()
    {
        if (is_bool(self::$isCliMode)) {
            return self::$isCliMode;
        }
        if(PHP_SAPI == 'cli'){
            return true;
        }
    return false;
    }

and when doing this:

   public static function isPhpCliMode()
    {
        if (is_bool(self::$isCliMode)) {
            return self::$isCliMode;
        }
        if(PHP_SAPI == 'cli'){
            return true;
        }
        
        if(self::isPhpCgiType() && 1){
            return true;
        }
        
        return false;
    }

The third check failed due to an configuration error in nginx. My fastcgi.conf wasn't properly loaded which caused the third if to be true. Sorry. I never expierenced problems because of REMOTE_ADDR not being present. That's why I thought this was a bug.

Maybe we should replace this with \Piwik\IP::getIpFromHeader(). Do you know if in your case the IP is maybe set in another Header/$_SERVER entry?

I don't actually know the difference, but in my case this was really just a misconfiguration. No header contained the remote ip at all:

It seems that it is really important at which line you include fastcgi.conf and that was my problem.
The server was previously configured to pass only these variables:

    SYSTEM ENVIRONMENT VARIABLES
    ...
    [HTTP_ACCEPT_LANGUAGE] => de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
    [HTTP_ACCEPT_ENCODING] => gzip, deflate, br
    [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
    [HTTP_DNT] => 1
    [HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36
    [HTTP_UPGRADE_INSECURE_REQUESTS] => 1
    [HTTP_CACHE_CONTROL] => max-age=0
    [HTTP_CONNECTION] => keep-alive
    [HTTP_HOST] => localhost
    [SCRIPT_NAME] => C:\Server\nginx/html/test.php
    [SCRIPT_FILENAME] => C:\Server\nginx/html/test.php
    [FCGI_ROLE] => RESPONDER
    [PHP_SELF] => C:\Server\nginx/html/test.php
    [REQUEST_TIME_FLOAT] => 1552351190.6844
    [REQUEST_TIME] => 1552351190

Thanks.