Old Docker containers have issues after Docker Desktop update

chocolata · October 30, 2025, 8:57pm

Hi everyone,

The following question might not be limited to October CMS, but I’m at my wits end after having spent hours on this. Please bear with me if I might say something stupid, as I’m a novice in Docker.

After updating to Docker Desktop 4.49.0 (208700) on Windows, none of my existing October CMS v3 Docker containers will start correctly anymore.
They all throw the following error:

SQLSTATE[HY000] [2002] Connection refused

Nothing in my configuration has changed. The issue seems related to file permission changes after the Docker update — MariaDB now refuses to start inside those old containers because it no longer has access to the database (\\wsl.localhost\Ubuntu\var\projects\project-name\octobercms-database) in WSL.

Creating new containers via the interactive bash installer works fine, so this appears to be specifically affecting older, pre-existing containers (which still run October v3).

I’ve been trying to reset those permissions, but nothing seems to work…

Upgrading to v4 isn’t an immediate option due to plugin dependencies or project constraints.
It would therefore be ideal if these existing v3 containers could still run as before — otherwise, the entire idea of Docker as a “portable, reproducible environment” is being challenged here.

I’m wondering:

Is there a clean way to fix or reset the permissions of existing database volumes so that MariaDB can start again?
Or are older containers effectively incompatible with the new Docker Desktop version?

When checking the logs inside the container, MariaDB fails to start and outputs the following error:

InnoDB: Upgrade after a crash is not supported. The redo log was created with MariaDB 10.5.19. You must start up and shut down MariaDB 10.7 or earlier.

This suggests that the MariaDB version used in these older containers (10.5) is incompatible with the existing data files when running under the current environment. I was able to recover the data by mounting the same database volume into a temporary mariadb:10.6 container, starting and stopping it once to complete the InnoDB recovery, and then creating a dump from that instance.

The original October CMS containers themselves still don’t start correctly and continue to throw connection errors, but the data could be rescued this way. I’m sharing this in case others run into the same issue, or know a cleaner approach to restore older containers without version or recovery conflicts.

Any insight or recommended recovery path would be greatly appreciated, as my development environment is completely useless at the moment and I am unable to continue developing.

Thanks in advance for anyone who might provide some insight.

daft · November 2, 2025, 8:23am

Oh no! Sorry to hear about this…

I think it may be actually because the docker image has been updated to v4 and it causes the MariaDB to fall over since even across minor versions the database files lose compatibility (and need to be migrated). So perhaps you pulled the latest image.

Secondary, I think the Docker image was initially designed to be a way to test October CMS, rather than be a long term development solution.

Moving forward, I think we may need to version these images which should stop this from happening, since we only have “latest” that forces everyone to upgrade (and breaks MariaDB). However, this still does not result in a viable upgrade path and we’d need to fix the DB migration issue.

Some resources here is the Dockerfile from the installer:

github.com

octobercms/install/blob/master/Dockerfile

#
# October CMS installer
#
# Build: docker build -t myoctober:latest .
# Run:   docker run --rm -p 8080:80 myoctober:latest
# Visit: http://localhost:8080/install.php
#
FROM php:8.3-apache-bullseye
LABEL maintainer="October CMS <hello@octobercms.com> (@octobercms)"

# OS deps
RUN apt-get update && apt-get install -y --no-install-recommends \
    unzip \
    wget \
    curl \
    make \
    autoconf \
    pkg-config \
    libfreetype6-dev \
    libjpeg62-turbo-dev \

This file has been truncated. show original

daft · November 2, 2025, 8:25am

I’m also reading that this environment variable MARIADB_AUTO_UPGRADE can help fix the issue.

services:
  db:
    image: mariadb:10.11
    environment:
      - MARIADB_ROOT_PASSWORD=secret
      - MARIADB_AUTO_UPGRADE=1
    volumes:
      - db_data:/var/lib/mysql
volumes:
  db_data: {}

chocolata · November 2, 2025, 3:30pm

Hi @daft , thanks for taking the time to look into this.

Am I right in assuming that there is no way to retroactively solve this issue and that the only way forward on the short term is to try and salvage the database and reimport it into a new container using the latest image? Or do you have any other ideas how we could salvage this.

As for your comment regarding the Docker image not being optimal for long term development purposes: what would you suggest is a better solution? Please note that I currently use a local development environment in Docker, a staging environment on a webserver, and finally a production environment on a webserver. I’m interested to know about better solutions.

To give more context: I had several Docker containers with V3 installs. I was under the impression I could run a separate container to test V4, but I assume that that action effectively bricked the V3 containers, because it pulled the latest image.

Lastly: thanks for investigating the ENV variable regarding the migration. This isn’t something that I could try in my situation?

Thanks for your insights.