Warnings after install on Ubuntu server

Hi!
I’m trying to install Matomo on my Ubuntu server.
Everything so far was smooth, but I have 2 warning which I don’t know how to fix:

1) PHP SAPI fpm-fcgi
PHP FPM will ignore .htaccess rules for .php files. To ensure that sensitive files cannot be accessed directly it is recommended to exclude certain directories from being handled by PHP FPM. For more information please see the official nginx server configuration

2) Server Info nginx/1.18.0
To ensure that sensitive files cannot be accessed directly it is recommended to configure your web server to restrict access to certain directories. For more information please see the official nginx server configuration

I did everythng as instructions said. What did I do wrong?

server {
	listen               443 ssl;
	listen               [::]:443 ssl;

	server_name          matomo.thevegcat.ubt;
	server_tokens        off;
	root                 /var/www/matomo;

	ssl_certificate      /root/certificates/localhost.crt;
	ssl_certificate_key  /root/certificates/localhost.decrypted.key;

	add_header           Referrer-Policy origin always;
	add_header           X-Content-Type-Options "nosniff" always;
	add_header           X-XSS-Protection "1; mode=block" always;

	index                index.php;

	client_max_body_size 20M;

	gzip                 on;
	gzip_min_length      512;
	gzip_proxied         expired no-cache no-store private auth;
	gzip_types           text/plain application/xml text/css application/javascript application/json;

	add_header           Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

	access_log           /var/log/nginx/php-access.log;
	error_log            /var/log/nginx/php-error.log;

	location ~ ^/(index|matomo|piwik|js/index|plugins/HeatmapSessionRecording/configs)\.php$ {
		include       snippets/fastcgi-php.conf;
		fastcgi_param HTTP_PROXY "";
		fastcgi_pass  unix:/run/php/php8.1-fpm.sock;
	}
	location ~* ^.+\.php$ {
		deny          all;
		return        403;
	}
	location / {
		try_files     $uri $uri/ =404;
	}
	location ~ ^/(config|tmp|core|lang) {
		deny          all;
		return        403;
	}
	location ~ /\.ht {
		deny          all;
		return        403;
	}
	location ~ js/container_.*_preview\.js$ {
		expires       off;
		add_header    Cache-Control 'private, no-cache, no-store';
	}
	location ~ \.(gif|ico|jpg|png|svg|js|css|htm|html|mp3|mp4|wav|ogg|avi|ttf|eot|woff|woff2)$ {
		allow         all;
		expires       1h;
		add_header    Pragma public;
		add_header    Cache-Control "public";
	}
	location ~ ^/(libs|vendor|plugins|misc|node_modules) {
		deny          all;
		return        403;
	}
	location ~/(.*\.md|LEGALNOTICE|LICENSE) {
		default_type  text/plain;
	}
}

This nginx config looks good to me.

What server response you get when you try to access https://your.matomo/lang/en.json from your web browser? Is there the expected 403 response?

1 Like

Thank you for your fast answer!

Yes, it’s 403: https://matomo.thevegcat.com/lang/en.json

In the meantime, my Matomo is up and running - hope it’s not open to attacks because of those 2 warnings.

Migrated 2 websites from GA4 which is a mess to set up:

  • https:// thevegcat (dot) com
  • https:// veganskivodic (dot) thevegcat (dot) com
    (they share the same data and search engine but having different site ID in Matomo)

P.S. Only 2 links allowed here, that’s why I wrote “(dot)

I checked your link and I got 403 too.
So nginx it’s configured right.

Can’t see an open Issue about System Checks at https://github.com/matomo-org/matomo/issues?q=is%3Aissue+is%3Aopen

I do not know how the Matomo code works. Maybe someone else can tell us, how the check is done from the “inside” of Matomo.

@innocraft, do you know if this behavior (the remaining warning after configuration fix) is the one expected?

Tried my diagnostic page today and warnings are gone. Don’t know how, but there are none of them. I could be a fariy. :rofl:

I have 2 Matomo instances running. One at a Plesk webhosting and one at my own LEMP server. .htaccess and nginx config worked always as expected.

Maybe some caching at the server, triggered that temporary behavior?