Errors which say Something happened, Unable to create, or Unable to write are caused by lack of permission. Your server user-name is usually www-data or sometimes apache.

To fix this error do all of the steps, in order.

1. Which server do you use: Apache, Nginx, Windows? Please find the configuration file. See what "user name" it runs things as. You can discover this by searching the web server config file for "user" and "group". Confirm that it is www-data. Or go list your files to see the group name and owner name ls -l /var/www/html/matomo/tmp
2. sudo chown -R www-data:www-data /var/www/html/matomo # I am assuming www-data was found in Step 1
3. sudo find /var/www/html/matomo/tmp -type f -exec chmod 644 {} \;
4. sudo find /var/www/html/matomo/tmp -type d -exec chmod 755 {} \;
5. sudo find /var/www/html/matomo/tmp/assets -type f -exec chmod 644 {} \;
6. sudo find /var/www/html/matomo/tmp/assets -type d -exec chmod 755 {} \;
7. sudo find /var/www/html/matomo/tmp/assets -type f -exec chmod 644 {} \;
   
   

Tokens generated by users, starting in Matomo 5, should keep unchecked the box "Only allow secure requests" if the token is meant for a GET request.  However it is recommended that you check this box, and get in the habit of sending tokens in POST requests instead.

Certain operations by modules like Looker Studio Matomo Connector require a GET request from Google. So in that case, generate the token with the box NOT checked.

If your site gets more than 100,000 pageviews per month, you must, must, must enable core:archive. And you must disable browser based archiving.  This can be done in the config/config.ini.php file.

How long does core:archive take to run
A very large site with 12M hits per day (300M hits per month) can take 8 hours to finish the core:archive. This is with some CPU-intensive options enabled, like uniqueness and segments.  Here is one example of a real site which takes 8 hours:

• They have 100 defined segments
  
• They get ~12M hits a day
  
• The largest segments returns 5M visits for the iOS segment
  

Is PHP installed?
sudo apt update
sudo apt install php

There are two!
Matomo runs two PHPs. One is on the Apache server for the Matomo backend. The other is the PHP for the CLI, which executes the core:archive command

PART ONE: JUST CHECKING THE SERVER PHP WHERE REPORTS AND TRACKING HAPPEN
Check memory and the version of PHP in the web server which serves your Matomo Interface
First, make a serveable phpinfo(); page. I placed mine at https://littlefurnace.com/foobarbaz.php
Then serve that page, in the browser. Or from CURL. 
In Curl: curl https://littlefurnace.com/foobarbaz.php | grep memory

In your browser, the classic pink and blue PHP information page will appear. 

This will have important information about the memory_limit, the path to where the configuration files are, and the PHP version you are running.


PART TWO: JUST CHECKING THE CLI ENVIRONMENT PHP, WHERE CORE:ARCHIVE AND OTHER CONSOLE COMMANDS ARE EXECUTED

Check memory and the version of PHP in CLI (for Matomo core:archive) 
IMPORTANT The core:archive of Matomo uses the PHP settings of CLI, not of the web server.
php -i | grep memory_limit
To find the path to the config file where you can edit things like  memory_limit
php -i | grep -i config

Example in my Matomo CLI environment
This:
php -i | grep -i config
Returns this:
Loaded Configuration File => /etc/php/8.1/cli/php.ini
So edit that file to look like this:
memory_limit=6G

Is PHP enabled for Apache?
sudo apt install libapache2-mod-php
(restart Apache)
sudo systemctl restart apache2

Configuration
Check the PHP configuration file (php.ini) to ensure that the disable_functions directive does not include any module that you need!
Find the php.ini
php -i | grep php.ini
Then, edit the php.ini file
And restart server
sudo systemctl restart apache2

Increase PHP memory in Matomo
A typical Matomo error is
Allowed memory size of 4294967296 bytes exhausted

Typical steps to fix this error:
Find the php.ini
php -i | grep php.ini
Then, edit this line in the php.ini file
memory_limit=8G
And restart server
sudo systemctl restart apache2

(Or, if you want to experiment on-the-fly with benchmarking the performance, you can actually override the memory limit directly, including in the crontab, using an option
such as: php -d memory_limit=2G /var/www/html/console core:archive )

A less common, laborious, alternative solution to prevent the php process from using too much memory is only process a specific number of reports at a time in order. We can achieve this by using a combination of --force-periods and --force-date-range in the core:archive task to process only a few specific reports for each core:archive run: For example: php path/to/matomo/console core:archive --force-idsite=13 --force-periods=day,week,month --force-date-range=2021-01-01,2021-01-31 And then repeat this process for each month that the reports were invalidated for.