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 override에서 참조하세요. `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. 덤프를 대상 서버로 전송합니다. `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

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트