I have experienced this error on a brand new install of Nextcloud 22 with MariaDB 10.6.2, both in Docker containers, so it’s not just upgrades which cause the error. Nextcloud is not functional at all.
I’m not sure how to deal with it other than using MariaDB 10.5.11 instead. I’ll see if it’s possible to pass the command line options to turn this off to the MariaDB container.
Edit: Swapping to MariaDB 10.5.11 solved the issue for me. Not ideal but it works
One can easy avoid issues like that by not upgrading to new MariaDB, PHP and even new Nextcloud major releases on day one. I have long since moved to a more conservative strategy when it comes to upgrading Nextcloud and it’s main dependencies. This way I was able to avoid many of the problems that came up here in the forums. I am still on NC 21.0.3, MariaDB 10.3 and PHP7.4 on my production instance and I run a seperate instance, where I test new versions of Nextcloud and it’s dependencies before I upgrade my main instance.
Why is that nod ideal? As for MariaDB, each major release is supported for 5 years. And Nextcloud itself always supports at least the two or three latest versions of MariaDB. So there is no reason to upgrade immediately just because there is a new number on it.
For whatever reason I even had a wrong charset/collation
MariaDB [nextcloud]> show variables like 'innodb_file_per_table';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | ON |
+-----------------------+-------+
1 row in set (0.004 sec)
MariaDB [nextcloud]> SELECT @@character_set_database, @@collation_database;
+--------------------------+----------------------+
| @@character_set_database | @@collation_database |
+--------------------------+----------------------+
| latin1 | latin1_swedish_ci |
+--------------------------+----------------------+
1 row in set (0.002 sec)
MariaDB [nextcloud]> ALTER DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
Query OK, 1 row affected (0.001 sec)
MariaDB [nextcloud]> SELECT @@character_set_database, @@collation_database;
+--------------------------+----------------------+
| @@character_set_database | @@collation_database |
+--------------------------+----------------------+
| utf8mb4 | utf8mb4_general_ci |
+--------------------------+----------------------+
1 row in set (0.001 sec)
Without dowgrading to image: mariadb:10.5 or running with command --skip-innodb-read-only-compressed I run also into, when reprairing docker-compose exec --user www-data app php occ maintenance:repair --include-expensive into:
- ERROR: An exception occurred while executing a query: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect string value: '\xF0\x9F\x8E\x82 V...' for column `nextcloud`.`oc_calendarobjects_props`.`value` at row 29
Add --innodb_read_only_compressed=OFF after the run command or add command: ['--innodb_read_only_compressed=OFF'] to your docker-compose file. Thanks to @tardar for finding this!
Thanks @bb77 , @Derkades
adding command: ['--innodb_read_only_compressed=OFF'] solved it and i will definitely specify major versions in docker-compose from now on!
From MariaDB 10.6.0, tables that are of the COMPRESSED row format are read-only by default. This is the first step towards removing write support and deprecating the feature. Set the innodb_read_only_compressed variable to OFF to make the tables writable.
If you have access to /etc/my.cnf.d/server.cnf, you may temporarily mitigate the issue by adding a line innodb_read_only_compressed=OFF to the section [mysqld].
However, this is a workaround rather that a solution. Tables MUST be migrated, should be migrated automatically by Nextcloud and hopefully will by a NC update soon. I think it is wise NOT to touch the table’s definition in order not to thwart the NC migration that hopefully comes prior to MariaDB’s next step against innodb-compressed-row-format.
Also note that there already is a bug report for this. A quote from a NC dev there: Nextcloud does NOT support MariaDB 10.6. The reason is the compressed row format. Either stick with MariaDB 10.5 or add --innodb-read-only-compressed=OFF to make compressed tables writeable. #25436 is the issue to track progress. It’s on the roadmap. A solution requires a migration of the row format to something different. Don’t expect this for Nextcloud 22 / 23.
I ran into the same issue in my homelab running nextcloud with latest and MariaDB with latest. I know its stupid to use latest and just upgrade blindly but its not a critical system for me. I have now defined versions in the docker-compose file.
I went back to 10.5.11 for MariaDB. Ran the repair command, added the phone region setting and then turned of maintenance mode. Seems to work fine for me now.
Will have to use my good friend google and try to figure out how one should upgrade containers. Preferrably in way where you can easily revert everything. I feel like everytime I do it sometime can break and never work properly again. If it were a VM I could easily snapshot, but with docker containers im not sure how it should be done.
I have updated to nextcloud 21 and all worked well,
but some time later i cannot login and do anything,
i looked in my logs and see the same error as in this post,
but for me there was a very simple fix
you must convert the database tables to dynamic tables because otherwise nextcloud cannot write because the are read only,
and because nextcloud has very much tables (that’s my opinion)
there is a bash script for it, you can find it below