Question 1

为什么SOGo容器会报错“您是否试图将目录挂载到文件上（反之亦然）？”？

Accepted Answer

当 `/opt/mailcow-dockerized/data/conf/sogo/custom-fulllogo.png` 是一个目录而非有效的 PNG 文件时，会发生此错误。Docker 尝试将主机路径作为文件绑定挂载到容器内部，从而导致失败。要修复此问题，请删除该目录并替换为正确的 PNG 文件，或者如果您不需要自定义完整 logo，则直接将其删除。更正文件后，重新运行 `docker compose up -d`。

Question 2

如何修复 Mailcow 中的 Unbound CVE-2026-33278？

Accepted Answer

将 Mailcow 升级到包含 Unbound 1.25.1 或更新版本的发行版。作为临时解决方案，仅从 Alpine edge 安装修复后的 `unbound` 软件包，而不是将整个镜像切换到 `alpine:edge`（这会破坏 `syslog-ng`）。在 Dockerfile 中，从常规的 `apk add` 命令中移除 `unbound`，并添加：

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

构建生成的本地镜像并为其打上标签，然后在你的 Docker Compose 覆盖文件中引用该镜像。使用 `unbound -V` 验证版本；它应显示 1.25.1 或更高版本。PR #7252 跟踪此更改。

Question 3

如何在 mailcow-dockerized 中修补 nginx CVE-2026-9256 “poolslip” 漏洞？

Accepted Answer

升级到包含 nginx 1.30.2 或更新版本的 mailcow 版本。作为手动解决方法,可使用 nginx 1.30.2-alpine 重新构建 nginx 镜像:

```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
```

如果 Dockerfile 中的内容不完全是 `FROM nginx:1.30.1-alpine`,请在运行构建和 compose 命令之前,手动将其编辑为使用 `nginx:1.30.2-alpine`。

Question 4

如何修复 mailcow 中的 NGINX CVE-2026-42945？

Accepted Answer

将 NGINX 升级到 1.30.1 或 1.31.0。在 mailcow 中，于本地重新构建 NGINX 镜像，并将容器切换到该镜像：

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

将 `docker-compose.yml` 中的 `nginx-mailcow` 镜像标签更新为：

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

然后重新创建容器：

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

使用 `docker exec $(docker compose ps -q nginx-mailcow) nginx -v` 验证正在运行的 NGINX 版本。待包含修复后 NGINX 版本的 mailcow 官方更新发布后，移除所有临时的镜像标签覆盖设置，并恢复使用官方镜像。

Question 5

如何修复跨服务器迁移期间出现的 Mailcow 恢复错误 "InnoDB: File './ibdata1' is corrupted"？

Accepted Answer

由 `helper-scripts/backup_and_restore.sh` 创建的物理 MariaDB/mariabackup 归档在全新服务器上可能无法恢复。请改用逻辑 SQL 转储：

1. 在源服务器上，转储所有数据库：
```bash
MYSQL_CTR=$(docker ps -qf name=mysql-mailcow)
docker exec "$MYSQL_CTR" mysqldump --all-databases --single-transaction --routines --triggers --events > mailcow.sql
```

2. 将转储文件传输到目标服务器。如果 `scp` 无法处理 `mailcow.conf` 等权限受限的文件，请使用 `tar` 搭配 `sudo`，而不要更改权限：
```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. 在目标服务器上，确保新部署的 Mailcow 堆栈正在运行，然后恢复转储：
```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
```

不要重复使用已损坏的 `ibdata1`/mariabackup 文件。目前没有内置的 `--sql-dump` 选项；手动执行 `mysqldump` 流程是可移植的迁移变通方案。

mailcow-dockerized

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐