コミュニティソリューション

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 では動作していた 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が確認した普遍的な原因ではなく、コミュニティで報告された2件の失敗例を記載しているだけです。

特権モードを最初に試すべきですか?

いいえ。元の投稿者は試しましたが、Apacheの書き込みエラーは解消されませんでした。

AIOはホストのポート80を占有せずにリバースプロキシの背後で動作できますか?

はい。現在のAIOドキュメントには APACHE_PORTリバースプロキシベースのワークフロー。