After upgrading a server from Ubuntu 22.04 (Jammy Jellyfish) to 24.04 (Noble Numbat), a Nextcloud installation may break with the following error:

Internal Server Error 

The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.

The log file is stored in the data folder of the Nextcloud installation folder (/data/nextcloud.log).

Inspecting this file revealed the following error:

Exception”:”Doctrine\\DBAL\\Exception”,”Message”:”Failed to connect to the database: An exception occurred in the driver: could not find driver

The upgrade to Ubuntu 24.04 installs PHP version 8.3.  In some cases your system may have multiple versions of PHP installed which can cause issues during a Ubuntu release upgrade. You can check which version of PHP is set as the system default with the following command:

sudo update-alternatives --config php

Now check that Apache or Nginx are using the same version.

For Apache, you can check the version of PHP that is loaded with this command

ls /etc/apache2/mods-enabled/

To change the PHP version, use the following commands. Change X.X to appropriate value if it is not 8.3.

sudo a2dismod phpX.X

sudo a2enmod php8.3

Then restart Apache.

For Nextcloud and PHP-FPM, check the config files for enabled sites at this location

/etc/nginx/sites-enabled

For example, change any lines containing the old version /var/run/php/php8.x-fpm.sock to point to the new version/var/run/php/php8.3-fpm.sock. Then restart Nginx:

With PHP out of the way, check that you have the correct PHP modules installed.   Review your Nextcloud config file in the config folder of the Nextcloud installation folder (/config/config.php).

You’ll need the correct module based on dbtype variable, for example php-mysql.

sudo apt-get install php-mysql

If you have memory caching (optional), you will need to install the appropriate module based on the memcache.local variable for that as well, such as php-apcu.

sudo apt-get install php-apcu

Once complete, restart Apache or Nginx.

After upgrading a server from Ubuntu 22.04 (Jammy Jellyfish) to 24.04 (Noble Numbat), the Apache installation no longer functioned properly.  WordPress was also installed and would give the error:

Your PHP installation appears to be missing the MySQL extension which is required by WordPress.
Please check that the mysqli PHP extension is installed and enabled.

Also phpMyAdmin would give the following error

The mysqli extension is missing. Please check your PHP configuration.

This was confusing because the php-mysql plugin was already installed on the system.  Many guides walk you through manually uncommenting the lines for the mysqli and pdo_mysql extensions in php.ini.  Doing that had no effect.

Some guides will also have you create a PHP Info page to confirm whether the MySQL extension is enabled.  In the server’s webroot location, create a new php file with the following code:

<?php
phpinfo();
?>

Save the file , then browse to that webpage using a web browser.  This offered the first clue. At the top it the titled listed PHP Version 8.2 but Ubuntu 24.04 is by default configured for PHP 8.3.

Digging into this further, the server had multiple versions of php installed. You can check this by running the following command:

sudo update-alternatives --config php

In this case it was confirmed that 8.3 was set as the system default, but the title of the PHP Info webpage confirmed Apache was configured for the older 8.2 version.

You can check which version of PHP is configured for Apache by using the following command to list all of the modules currently loaded:

ls /etc/apache2/mods-enabled/

It was found that the server had a file named php8.2.load in the list.  The following commands will change the version of PHP module that Apache used from 8.2 to 8.3:

sudo a2dismod php8.2

sudo a2enmod php8.3

sudo service apache2 restart

After that was complete, both WordPress and phpMyAdmin started working again.

If you are using Nginx with PHP-FPM, then you will need to edit the config file for each enabled site to point to the newer version. The site configuration files are stored at:

/etc/nginx/sites-enabled

For example, change any lines containing the old version /var/run/php/php8.2-fpm.sock to point to the new version/var/run/php/php8.3-fpm.sock. Then restart Nginx:

sudo service nginx restart

Veeam has the ability to backup File Shares and in this case I had an NFS backup that randomly started failing.  The only thing that had changed was a recent upgrade from Veeam 11 (specifically 11.0.1.1261) to Veeam 12 (specifically 12.3.1.1139).   The upgrade went smoothly with no errors generated during the installation process.  However about a month later, I received this error during the execution of a scheduled backup job:

Agent: Failed to process method {NasMaster.ExecuteBackupProcessor}: The file specified already exists.

The details of the error included:

Path: [Host: [xxx.xxx.xxx.xxx], Mount: [/path/to/backup], Disk: [Name/name/data/data/xxx.vblob], Type: [nfs3 (1)]]. The file specified already exists. NFS status code: 17 Failed to create nfs file stream. Failed to create nfs file. Failed to perform file backup Error: Agent: Failed to process method {NasMaster.ExecuteBackupProcessor}: The file specified already exists. Error: Agent: Failed to process method {NasMaster.ExecuteBackupProcessor}: The file specified already exists.

The automatic retries failed in the same manner.  At first I thought perhaps it was just a fluke, so I ignored it.  However, on the next scheduled backup the same error occurred.

The first thing I tried was to do a health check and repair on the backup using these two steps:

1. Upgrade Veeam to the latest version (specifically 12.3.2.3617)
2. Manually run a health check on the backup files

To perform a health check:

1. Open Veeam Backup and Replication
2. Go to Jobs -> Backup
3. Find the job that was failing
4. Right click on it -> Run health check

When I ran the health check, some errors were found and repairs were made to the backup:

Succeeded Repairing backup completed successfully

After it was complete, the job was manually run and it completed without any error.

I thought the issue was resolved, but it occur again on the next backup with the same error. However this time even though it failed, files would still be backed up. Also the job would automatically retry and the retry job would be successful. The details of the retry job showed that it processed no files, but completed without any error.

This pattern kept repeating.

I tried increasing the CPU and memory of the machine to check if it was starved of resources, however that also didn’t fix the problem.

I then tried deleting the backup on disk. The steps I followed to delete the backup from the disk:

1. Open Veeam Backup and Replication
2. Go to Backups -> Disk
3. Find the backup related to the job that was failing
4. Right click on it -> Delete from disk

This seemed to work initially, however the errors started showing up again after multiple cycles.

The final solution I found as a clue in this thread

https://www.reddit.com/r/Veeam/comments/vagwao/veeam_errors_failed_to_create_backup_file_because/

One key topic seemed to be around permissions of the ProgramData folder associated with the backup:

C:\ProgramData\Veeam\BACKUP folder

however, nothing looked unusual about the permissions at this location for this configuration.

What finally worked for me was to perform the following:

1. Shut down Veeam and all related background services
2. Completely delete the folder at the C:\ProgramData\Veeam\ location that is associated with the job.
3. Reboot the system

After rebooting the system, it may take a couple backup cycles to completely flush out the failures. After that the errors should not return.