Question 1

Why does SOGo container fail with 'Are you trying to mount a directory onto a file (or vice-versa)?' error?

Accepted Answer

This error occurs when `/opt/mailcow-dockerized/data/conf/sogo/custom-fulllogo.png` is a directory instead of a valid PNG file. Docker attempts to bind-mount the host path as a file inside the container, causing the failure. To fix, delete the directory and replace it with a proper PNG file, or remove it entirely if you don't need a custom full logo. After correcting the file, run `docker compose up -d` again.

Question 2

How to fix Unbound CVE-2026-33278 in Mailcow?

Accepted Answer

Upgrade Mailcow to a release containing Unbound 1.25.1 or newer. As a temporary workaround, install only the fixed `unbound` package from Alpine edge instead of switching the whole image to `alpine:edge` (which breaks `syslog-ng`). In the Dockerfile, remove `unbound` from the regular `apk add` command and add:

```dockerfile
RUN apk add --no-cache --repository=https://dl-cdn.alpinelinux.org/alpine/edge/main unbound
```

Build and tag the resulting local image, then reference it in your Docker Compose override. Verify the version with `unbound -V`; it should report 1.25.1 or later. PR #7252 tracks this change.

Question 3

How do I patch nginx CVE-2026-9256 "poolslip" in mailcow-dockerized?

Accepted Answer

Upgrade to a mailcow release containing nginx 1.30.2 or newer. As a manual workaround, rebuild the nginx image with nginx 1.30.2-alpine:

```bash
sudo -i
cd /opt/mailcow-dockerized
sed -i '1 s/^FROM nginx:1.30.1-alpine$/FROM nginx:1.30.2-alpine/' data/Dockerfiles/nginx/Dockerfile
docker build -t ghcr.io/mailcow/nginx:1.08 data/Dockerfiles/nginx
docker compose up -d
```

If the Dockerfile does not contain exactly `FROM nginx:1.30.1-alpine`, edit it manually to use `nginx:1.30.2-alpine` before running the build and compose commands.

Question 4

How do I fix NGINX CVE-2026-42945 in mailcow?

Accepted Answer

Upgrade NGINX to 1.30.1 or 1.31.0. In mailcow, rebuild the NGINX image locally and switch the container to it:

```bash
cd /opt/mailcow-dockerized
docker build -t ghcr.io/mailcow/nginx:1.06 data/Dockerfiles/nginx
```

Update the `nginx-mailcow` image tag in `docker-compose.yml` to:

```yaml
image: ghcr.io/mailcow/nginx:1.06
```

Then recreate the container:

```bash
docker compose up -d
```

Verify the running NGINX version with `docker exec $(docker compose ps -q nginx-mailcow) nginx -v`. After an official mailcow update containing the fixed NGINX version is released, remove any temporary image-tag override and return to the official image.

Question 5

How to fix Mailcow restore error "InnoDB: File './ibdata1' is corrupted" during cross-server migration?

Accepted Answer

The physical MariaDB/mariabackup archive created by `helper-scripts/backup_and_restore.sh` can fail to restore on a fresh server. Use a logical SQL dump instead:

1. On the source server, dump all databases:
```bash
MYSQL_CTR=$(docker ps -qf name=mysql-mailcow)
docker exec "$MYSQL_CTR" mysqldump --all-databases --single-transaction --routines --triggers --events > mailcow.sql
```

2. Transfer the dump to the target server. If `scp` fails on restrictive files such as `mailcow.conf`, use `tar` with `sudo` instead of changing permissions:
```bash
sudo tar -C /path/to -czf - backup | ssh user@new-server 'sudo tar -C /tmp -xzf -'
scp mailcow.sql user@new-server:/tmp/
```

3. On the target server, with the fresh Mailcow stack running, restore the dump:
```bash
cd /opt/mailcow-dockerized
MYSQL_CTR=$(docker ps -qf name=mysql-mailcow)
docker exec -i "$MYSQL_CTR" mysql < /tmp/mailcow.sql
docker compose restart
```

Do not reuse the corrupted `ibdata1`/mariabackup files. There is currently no built-in `--sql-dump` option; the manual `mysqldump` procedure is the portable migration workaround.

mailcow-dockerized

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects