[SOLVED] Update from 5.3.12 to 6.0.10 fails because of failed auto upgrade of MariaDB from 11.6-noble to >= 11.7-noble

abaer · November 26, 2025, 2:23pm

Your Setup:

Self-Hosted / Docker on Debian 13 / Proxmox virtual machines
SeaTable Enterprise 5.3.12 (to 6.0.10)

Describe the Problem/Error/Question:

After some very hard debugging sessions, I have finally come to the point where I can point my finger to the cause: The auto-upgrade of the MariaDB database beyond 11.6-noble crashes, and even crash recovery fails. The only way to get back is the recovery of a backup.

Steps to reproduce

Simple version for debugging purposes, happens on live data as well:

Set up fresh Seatable 5.3.12 from scratch
Upgrade to Seatable 6.0.10 in the prescribed way, using MariaDB 11.6-noble image: Works
Upgrade to Seatable 6.0.10 in the prescribed way, using MariaDB 11.7-noble or higher image (Release notes: 11.8.3): Total mess
Upgrade container with upgraded 11.6. database to 11.7-noble with MARIADB_AUTO_UPGRADE=1: Seatable works, but MariaDB health check fails due to missing user “healthcheck“

Error Messages:

Messages for successful upgrade < 11.7

2025-11-26 14:14:06 0 [Note] mariadbd: ready for connections.

Version: '11.6.2-MariaDB-ubu2404'  socket: '/run/mysqld/mysqld.sock'  port: 0  mariadb.org binary distribution

2025-11-26 14:14:07+01:00 [Note] [Entrypoint]: Temporary server started.

2025-11-26 14:14:07+01:00 [Note] [Entrypoint]: Backing up system database to system_mysql_backup_11.4.3-MariaDB.sql.zst

2025-11-26 14:14:07+01:00 [Note] [Entrypoint]: Backing up complete

2025-11-26 14:14:07+01:00 [Note] [Entrypoint]: Starting mariadb-upgrade

The --upgrade-system-tables option was used, user tables won't be touched.

Major version upgrade detected from 11.4.3-MariaDB to 11.6.2-MariaDB. Check required!

Phase 1/8: Checking and upgrading mysql database

Processing databases

mysql

mysql.column_stats                                 OK

mysql.columns_priv                                 OK

mysql.db                                           OK

mysql.event                                        OK

mysql.func                                         OK

mysql.global_priv                                  OK

mysql.gtid_slave_pos                               OK

mysql.help_category                                OK

mysql.help_keyword                                 OK

mysql.help_relation                                OK

mysql.help_topic                                   OK

mysql.index_stats                                  OK

mysql.innodb_index_stats                           OK

mysql.innodb_table_stats                           OK

mysql.plugin                                       OK

mysql.proc                                         OK

mysql.procs_priv                                   OK

mysql.proxies_priv                                 OK

mysql.roles_mapping                                OK

mysql.servers                                      OK

mysql.table_stats                                  OK

mysql.tables_priv                                  OK

mysql.time_zone                                    OK

mysql.time_zone_leap_second                        OK

mysql.time_zone_name                               OK

mysql.time_zone_transition                         OK

mysql.time_zone_transition_type                    OK

mysql.transaction_registry                         OK

Phase 2/8: Installing used storage engines... Skipped

Phase 3/8: Running 'mysql_fix_privilege_tables'

Phase 4/8: Fixing views... Skipped

Phase 5/8: Fixing table and database names ... Skipped

Phase 6/8: Checking and upgrading tables... Skipped

Phase 7/8: uninstalling plugins

Phase 8/8: Running 'FLUSH PRIVILEGES'

OK

2025-11-26 14:14:12+01:00 [Note] [Entrypoint]: Finished mariadb-upgrade

2025-11-26 14:14:12+01:00 [Note] [Entrypoint]: Stopping temporary server

Error for upgrade to MariaDB 11.7 (differences):

2025-11-26 14:19:26 0 [Note] mariadbd: ready for connections.

Version: '11.7.2-MariaDB-ubu2404'  socket: '/run/mysqld/mysqld.sock'  port: 0  mariadb.org binary distribution

2025-11-26 14:19:27+01:00 [Note] [Entrypoint]: Temporary server started.

2025-11-26 14:19:27+01:00 [Note] [Entrypoint]: Backing up system database to system_mysql_backup_11.6.2-MariaDB.sql.zst

mariadb-dump: Got error: 2002: "Can't connect to server on 'mariadb' (115)" when trying to connect

2025-11-26 14:19:27+01:00 [ERROR] [Entrypoint]: Unable backup system database for upgrade from 11.6.2-MariaDB.

So obviously, the backup can’t be created, because the temporary server is not reachable? What has changed from MariaDB 11.6 to 11.7? Has somebody encountered this before? Is there a fix?

Most important: Will Seatable run with MariaDB 11.6 until a fix is found. Is the upgrade to 11.8.3 purely hygienic, or functional?

And, for the MariaDB Experts out there: Is the Backup an integral part of the update procedure, or just in case something goes wrong? Because, as it turns out, I need a separate backup anyway, because the failed upgrade leaves the database in a corrupt state.

So in case I could turn off the backup stage, and thus make the big step from 11.6 to 11.7 and beyond, I would consider it.

cdb · November 26, 2025, 9:10pm

SeaTable does not rely on version specific mariadb features.
Also there is no hard connection between SeaTable and mariadb version.

Consequently we decided only to use LTS versions of mariadb. Our history of used mariadb versions is:

11.8.3-noble (since 30.09.2025)
11.4.3-noble (since 24.10.2024)
10.11.7-jammy

I have updated round about 100 SeaTable Servers in the past. I never had any problems updating mariadb to these versions.

So, why do you use 11.6 or 11.7? There is no need to take every version step.
Where did you get your information from, to update to these versions?
My recommendation is to stick to our promoted versions and you will not face any issues.

SeaTable does not depend on any version-specific MariaDB features.
There is no strict coupling between SeaTable and a particular MariaDB version.

For that reason, we only use MariaDB LTS versions. Here is the list of MariaDB versions we have used so far:

11.8.3-noble (since 2025-09-30)
11.4.3-noble (since 2024-10-24)
10.11.7-jammy

Over the years, I’ve updated around 100 SeaTable servers and never encountered any issues when upgrading to these versions.

So, why are you using 11.6 or 11.7? It’s unnecessary to install every intermediate release.
Where did you find the recommendation to update to those versions?
My advice is to stick with the versions we officially promote — that way, you’ll avoid compatibility problems.

abaer · November 26, 2025, 10:45pm

To see where it breaks. Sorry that I left out the tedious details of my journey and caused confusion. Of course I followed the update instructions and went straight to 11.8.3 LTS … And got the problems mentioned above right from the start. So sticking to the official versions caused the problems.

Next, I left MariaDB at 11.4.3 and upgraded to Seatable 6.0.10 without problems. Then I became curious and upgraded MariaDB step by step, major version by version. This way, I found out that 11.7 breaks my database when it tries to make a backup before the upgrade.

This is certainly due to the fact that I had to tweak a lot of the standard install to fit our corporate standards and infrastructure. Your confirmation that you haven’t seen something like this in a lot of upgrades [ of standard installs? ] just confirms this.

At least I can go ahead and use 6.0.10 with MariaDB 11.6 while I’m looking for the reason, can I? Because yes, I’d certainly like to use all the official versions Seatable supports.

Maybe someone else from the seatable community has encountered something like this while upgrading from MariaDB 11.6 to 11.7?

cdb · November 27, 2025, 9:07am

What tweaks do you have regarding your mariadb database to fit to corporate standards?
You would use mariadb 11.4 with 6.0, simply for the reason that 11.4 is a LTS version of mariadb.

abaer · November 27, 2025, 11:33am

Hi, I have finally figured out what caused the problems. Here is a quick rundown should anyone ever encounter something similar:

We are using Portainer instead of Vanilla docker compose to maintain our docker stacks.
- Actually, this and other incidents point strongly in one direction: To abolish Portainer in favour of a Gitlab-CI/CD-approach to manage our Docker
Anyway, due to the internal workings of Portainer, the whole .env environment has found its way into the containers - not only the variables manually handed down in the environment: section of docker-compose.yml
Surprisingly, this hasn’t caused any problems in the past - up until MariaDB > 11.7
- I haven’t found any positive proof in the documentation or release notes of MariaDB, but looking at the logs with “cannot connect“, here’s my hypothesis:
- One of the various variables must have led to the autoupgrade-procedure not adressing the database on localhost (possible culprit MARIADB_HOST), but on the hostname “mariadb“, which failed (reason unknown).
- Point in case #1: Preventing auto-upgrading, and later running mariadb-upgrade in the container manually worked as intended
- Point in case #2: This would have been my workaround, until I noticed that the healthcheck failed because the healthcheck user also tried to connect via the hostname (therefore coming from the container’s IP 172.22.0.3), but had only permissions for localhost access.
Weird sidenote: None of the variables in MariaDB Server Docker Official Image Environment Variables | Server | MariaDB Documentation seem to be in conflict with Seatable’s .env variables.

Anyway, everything is working now, and I am quite sure I’m back to Seatable’s standards

system · November 29, 2025, 11:33am

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.