커뮤니티 솔루션

ZimaOS 1.5.0에서 Nextcloud AIO 오류 발생: /mnt/data 권한 분리, Docker 소켓, 포트 80 및 리버스 프록시 설정

An October 2025 thread where a previously working Nextcloud AIO deployment failed after ZimaOS 1.5.0. The mastercontainer progressed but the Apache container could not write /mnt/data; another user reported Docker socket, permission, domain-check, and port-80 conflicts and switched to a standard Nextcloud Compose stack. No IceWhale staff reply confirmed a single root cause.

소스는 “ZimaOS 1.5.0에서 Nextcloud AIO를 실행할 수 없다”는 점을 입증하지 않습니다. 입증하는 내용은 더 좁은 범위의 회귀 사례입니다. 1.4.1에서 작동하던 한 AIO 스택이 1.5.0 이후 작동을 멈췄고, Apache 컨테이너에 쓰기 권한이 없다는 메시지가 반복적으로 보고되었습니다. /mnt/data. 다른 사용자는 추가로 Docker 소켓, 도메인 확인 및 포트 충돌 문제를 겪은 뒤 일반 Nextcloud Compose 스택을 대신 선택했습니다.

현재 Nextcloud AIO 문서에서는 AIO의 내부 Apache를 더 이상 포트 80에 직접 게시하지 않아도 되는 공식 리버스 프록시 경로를 제공합니다. 이 경로는 8080에서 AIO 인터페이스를 사용하며 다음을 허용합니다. APACHE_PORT 예를 들어 11000과 같은 다른 호스트 포트로 이동해야 합니다. 이는 권한을 확대하거나 스택이 우연히 시작될 때까지 수동으로 권한을 변경하는 것보다 현재 상황을 더 잘 반영하는 참고 자료입니다.

소스에서 발생한 장애는 구체적으로 AIO 내부에서 발생했습니다

원 글 작성자는 다음과 같이 말했습니다.

  • AIO는 ZimaOS 1.4.1에서 작동했습니다.
  • 1.5.0 이후에는 스택이 대체로 시작되었습니다.
  • Apache 컨테이너가 지속적으로 쓰기에 실패했습니다 /mnt/data;
  • privileged: true 해결되지 않았습니다.
  • AIO mastercontainer 볼륨을 미리 생성해도 해결되지 않았습니다.

이는 “그냥 권한을 추가하라”는 방법을 지속 가능한 해결책으로 간주해서는 안 된다는 근거입니다.

다른 사용자는 여러 AIO 계층에서 문제를 겪었습니다

gelbuilding은 먼저 Docker 소켓 문제를 보고했고, 그다음에는 /mnt/data 권한 문제 이후 도메인 확인 문제가 발생했습니다. 또한 ZimaOS의 게이트웨이가 포트 80을 사용하는 방식이 해당 AIO 설계와 호환되지 않는다고 의심했습니다.

이는 IceWhale의 근본 원인 분석이 아니라 커뮤니티의 관찰 결과였습니다.

현재 AIO는 전용 리버스 프록시 구성을 지원합니다

현재 Nextcloud AIO 지침에서는 다음을 권장합니다.

  • AIO 관리 인터페이스를 8080에서 게시하고,
  • 다음을 설정하고 APACHE_PORT 예: 11000;
  • 리버스 프록시 또는 터널이 해당 Apache 포트를 가리키도록 하고,
  • Docker 소켓을 읽기 전용으로 mastercontainer에 마운트하고,
  • 필수 항목을 유지하고 nextcloud_aio_mastercontainer 볼륨.

최신 Nextcloud AIO 리버스 프록시 모델을 참조하세요.

Cloudflare Tunnel로도 AIO의 내부 포트 및 권한 요구 사항은 없어지지 않습니다

터널을 사용하면 라우터에서 공용 80/443 포트를 개방하지 않아도 되지만, AIO 컨테이너는 여전히 mastercontainer, Apache, Docker 소켓, 데이터 스토리지, 터널/리버스 프록시 간에 유효한 내부 경로가 필요합니다.

AIO 자체의 도메인 검증 및 프록시 요구 사항이 충족되지 않으면 “Cloudflare가 HTTPS를 처리한다”는 사실만으로 AIO 스택이 정상 작동하지는 않습니다.

어떤 컨테이너가 소유하는지 이해하지 못한 상태에서 AIO 데이터를 재귀적으로 chmod하지 마세요

/mnt/data AIO의 형제 컨테이너에서 이는 AIO의 관리형 스토리지 모델에 포함됩니다. 호스트 권한을 광범위하게 변경하면 오류가 사라질 수 있지만, 소유권이 약화되거나 이후 업그레이드 실패가 발생할 수 있습니다.

실제 AIO 볼륨 및 데이터 디렉터리 구성을 확인하고 먼저 업스트림 AIO 스토리지 지침을 따르세요.

출처의 사용자는 실용적인 대안으로 표준 Nextcloud Compose를 선택했습니다

gelbuilding은 다음 경로 아래에서 일반 Nextcloud 스택이 /DATA/AppData/nextcloud 빈 포트에서 깔끔하게 작동했으며 Cloudflare Tunnel을 통해 계속 게시할 수도 있었습니다.

사용자가 AIO의 마스터 컨테이너가 관리하는 형제 컨테이너 대신 Nextcloud, 데이터베이스 및 Redis 컨테이너를 명시적으로 제어하려 한다면 유효한 아키텍처입니다.

현재 ZimaOS에서 1.5.0 장애가 발생한다고 단정해서는 안 됩니다

현재 ZimaOS는 출처의 2025년 10월 릴리스보다 훨씬 최신 버전입니다. 오래된 우회 방법을 재현하기 전에 최신 ZimaOS에서 현재 Nextcloud/AIO Compose를 테스트하고 정확한 컨테이너 로그를 수집하세요.

AIO의 관리 모델에는 Docker 소켓 액세스가 필요합니다

마스터 컨테이너가 형제 컨테이너를 생성하고 관리합니다. 따라서 현재 업스트림 지침에서는 다음을 마운트합니다. /var/run/docker.sock 마스터 컨테이너에 읽기 전용으로 연결합니다. 소켓이 없거나 접근할 수 없으면 AIO가 나머지 스택을 올바르게 오케스트레이션할 수 없습니다.

소켓에 불필요한 쓰기 모드를 부여하거나 관련 없는 컨테이너에 노출하지 마세요.

AIO 마스터 컨테이너 볼륨의 이름과 용도를 그대로 유지하세요

현재 AIO 예시에서는 다음 명명된 볼륨을 사용합니다. nextcloud_aio_mastercontainer AIO 자체 구성에 사용됩니다. 업스트림은 업데이트 및 관리 로직이 문서화된 구조를 전제로 하므로 필요한 구성 요소의 이름을 함부로 바꾸거나 변경하지 말라고 경고합니다.

리버스 프록시 모드에서는 게시해야 하는 AIO 포트가 달라집니다

현재 AIO Compose 주석에 따르면 Nginx, Caddy, Apache 또는 Cloudflare Tunnel과 같은 리버스 프록시 뒤에서 실행할 때 호스트 포트 80과 8443을 제거할 수 있으며, AIO 인터페이스는 8080에서 계속 유지되고 Apache는 별도로 구성된 포트를 사용할 수 있습니다.

이는 다음 권한을 부여하는 것보다 더 정확합니다. 권한 모드 포트 충돌을 우회하기 위해 작동시키는

AIO와 표준 Nextcloud Compose는 운영 모델이 다릅니다

AIO는 마스터 컨테이너가 스택을 관리하도록 하여 업그레이드, 백업 및 관련 서비스를 간소화합니다. 표준 Compose 배포는 NAS 관리자가 모든 서비스, 경로 및 프록시 결정을 직접 제어할 수 있게 합니다. 출처의 사용자는 AIO를 사용하면서 문제를 겪은 후 두 번째 모델을 선택했습니다.

어느 선택이든 영원히 본질적으로 “더 호환성이 높은” 것은 아닙니다. 유지 관리할 모델을 선택하고 해당 업스트림 문서를 일관되게 따르세요.

Nextcloud AIO FAQ

출처에서 ZimaOS 1.5.0이 전반적으로 Nextcloud AIO를 차단했다는 사실을 입증했나요?

아니요. IceWhale이 확인한 보편적인 원인 없이 두 가지 커뮤니티 장애 사례를 설명합니다.

권한 모드를 사용하는 것이 첫 번째 해결 방법이어야 하나요?

아니요. 원글 작성자가 시도했지만 Apache 쓰기 오류는 계속 발생했습니다.

AIO를 호스트 포트 80을 사용하지 않고 리버스 프록시 뒤에서 실행할 수 있나요?

예. 현재 AIO 문서에는 APACHE_PORT- 기반 리버스 프록시 워크플로.