Nextcloud not starting after Bullseye-update

I had installed nextcloud/nextcloudpi on a raspberry pi with the help of a manual. I am really no expert in linux. Everything worked fine. Then I upgraded to bullseye. I probably took the wrong version because the system booted into a GUI after the update. I changed that and during boot I can see that apache has been started. SSH is also working. But how do I activate nextcloud again? When I try to enter Nextcloud with a Browser I just get the message that this page is unsecure. It would be great if you know what I have to do to get my nextcloud back. Many thanks in advance!

which one? Link please.


NCP doesn’t support it yet, it is still in testing phase, as far as NCP is concerned.

I wouldn’t really call myself an expert in Linux either if I had to describe myself, we all still has to start in the beginning at one point and you’ll learn as you go, as we all do in our own pace.

I agree with OliverV in what most likely caused it to break was the upgrade to bullseye (Debian 11) from buster (Debian 10) which is as OliverV said in the post above this one

You can also read this list from the Debian wiki about known problems when upgrading from buster to bullseye.

Personally I’d recommend reinstalling it, seems like a headache to go through and fix every little detail yourself and wait for the community devs testing out the upgrade/release to bullseye for NCP :slightly_smiling_face:

You can also find the GitHub issue for nextcloudpi here about the upgrade to bullseye, there is a package missing and rpi/armbian support

(List above is from these release notes)
Upgrades from Debian 10 (buster) - Debian wiki

I updated my HC1 to bullseye, and i have broken my instance. Trying to update:


This is my instance...
 * @copyright Copyright (c) 2016, ownCloud, Inc.
 * @author Christoph Wurst <>
 * @author Joas Schilling <>
 * @author Jörn Friedrich Dreyer <>
 * @author Lukas Reschke <>
 * @author Morris Jobke <>
 * @author Robin Appelman <>
 * @author Roeland Jago Douma <>
 * @author Sergio Bertolín <>
 * @author Thomas Müller <>
 * @author Vincent Petry <>
 * @license AGPL-3.0
 * This code is free software: you can redistribute it and/or modify
 * it under the terms of the GNU Affero General Public License, version 3,
 * as published by the Free Software Foundation.
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * GNU Affero General Public License for more details.
 * You should have received a copy of the GNU Affero General Public License, version 3,
 * along with this program. If not, see <>
require_once __DIR__ . '/lib/versioncheck.php';

try {
	require_once __DIR__ . '/lib/base.php';

} catch (\OC\ServiceUnavailableException $ex) {
	\OC::$server->getLogger()->logException($ex, ['app' => 'index']);

	//show the user a detailed error page
	OC_Template::printExceptionErrorPage($ex, 503);
} catch (\OCP\HintException $ex) {
	try {
		OC_Template::printErrorPage($ex->getMessage(), $ex->getHint(), 503);
	} catch (Exception $ex2) {
		try {
			\OC::$server->getLogger()->logException($ex, ['app' => 'index']);
			\OC::$server->getLogger()->logException($ex2, ['app' => 'index']);
		} catch (Throwable $e) {
			// no way to log it properly - but to avoid a white page of death we try harder and ignore this one here

		//show the user a detailed error page
		OC_Template::printExceptionErrorPage($ex, 500);
} catch (\OC\User\LoginException $ex) {
	$request = \OC::$server->getRequest();
	 * Routes with the @CORS annotation and other API endpoints should
	 * not return a webpage, so we only print the error page when html is accepted,
	 * otherwise we reply with a JSON array like the SecurityMiddleware would do.
	if (stripos($request->getHeader('Accept'), 'html') === false) {
		header('Content-Type: application/json; charset=utf-8');
		echo json_encode(['message' => $ex->getMessage()]);
	OC_Template::printErrorPage($ex->getMessage(), $ex->getMessage(), 401);
} catch (Exception $ex) {
	\OC::$server->getLogger()->logException($ex, ['app' => 'index']);

	//show the user a detailed error page
	OC_Template::printExceptionErrorPage($ex, 500);
} catch (Error $ex) {
	try {
		\OC::$server->getLogger()->logException($ex, ['app' => 'index']);
	} catch (Error $e) {
		header('Content-Type: text/plain; charset=utf-8');
		print("Internal Server Error\n\n");
		print("The server encountered an internal error and was unable to complete your request.\n");
		print("Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.\n");
		print("More details can be found in the webserver log.\n");

		throw $ex;
	OC_Template::printExceptionErrorPage($ex, 500);

I’m opening this up again since I think some people might still benefit.

In my case (upgrading Debian from Buster to Bullseye, using Nextcloud 24.0.5 with a Mariadb database), it seemed to me that there were 2 issues:

  1. The upgrade from buster to bullseye somehow does not handle the database correctly.
    (I found that here: Debian 10 auf 11 upgrade: MySQL läuft nicht mehr | ComputerBase Forum)

  2. Nextcloud does not work with php8.1 without manual tweaking.

I addressed both issues on the console as follows:

  1. Installing mariadb-server:
    apt install mariadb-server

  2. Going back from php 8.1 to php7.4 for the time being:
    a2dismod php8.1
    a2enmod php7.4
    systemctl restart apache2

After that, I could access my Nextcloud installation again.

PHP 8.1 is not a standard package from Debian Bullseye.
Why do you not use PHP 7.4. It still works with Nextcloud 24.

Debian Buster with PHP 7.3
Debian Bullseye with PHP 7.4

php8.1 without manual tweaking

Whithout manual tweaking you do not get PHP 8.1 in Debian Bullseye at all.