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 composeto 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 ofdocker-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 culpritMARIADB_HOST), but on the hostname “mariadb“, which failed (reason unknown). - Point in case #1: Preventing auto-upgrading, and later running
mariadb-upgradein 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
healthcheckuser also tried to connect via the hostname (therefore coming from the container’s IP 172.22.0.3), but had only permissions forlocalhostaccess.
- 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 
