Question 1

SOGoコンテナが 'Are you trying to mount a directory onto a file (or vice-versa)?' エラーで失敗するのはなぜですか？

Accepted Answer

このエラーは、`/opt/mailcow-dockerized/data/conf/sogo/custom-fulllogo.png` が有効な PNG ファイルではなくディレクトリになっている場合に発生します。Docker がホストパスをコンテナ内のファイルとして bind-mount しようとするため、失敗します。修正するには、そのディレクトリを削除し、適切な PNG ファイルに置き換えるか、カスタムフルロゴが不要な場合は完全に削除してください。ファイルを修正した後、再度 `docker compose up -d` を実行してください。

Question 2

Mailcow で Unbound CVE-2026-33278 を修正する方法

Accepted Answer

Unbound 1.25.1 以降を含むリリースに Mailcow をアップグレードしてください。一時的な回避策として、イメージ全体を `alpine:edge` に切り替える（これは `syslog-ng` を壊します）のではなく、Alpine edge から修正済みの `unbound` パッケージのみをインストールしてください。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
```

実行中の NGINX のバージョンは `docker exec $(docker compose ps -q nginx-mailcow) nginx -v` で確認してください。修正された 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. ダンプをターゲットサーバーに転送します。`mailcow.conf` のような権限が制限されたファイルで `scp` が失敗する場合は、パーミッションを変更するのではなく、`sudo` を付けて `tar` を使用してください：
```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

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト