2026 年 1 月のこの Nextcloud/MariaDB スレッドは、コンテナネットワークをレイヤーごとに診断すべき理由を示す、最も分かりやすい例の一つです。質問者は Nextcloud と MariaDB を別々のアプリとしてインストールし、MariaDB は正常な「接続を受け付ける準備ができました」状態に達していましたが、Nextcloud は初回セットアップ中に失敗しました。 mariadb の getaddrinfo に失敗しました両方のアプリを再インストールし、各アプリのフォルダーを削除してもエラーは変わりませんでした。
転機となったのは、コミュニティが MariaDB コンテナの実際の Docker IP を使ってテストしたことでした。Nextcloud のインストールがすぐに始まりました。これにより、データベースサーバー、認証情報、TCP 経路は基本的に機能しており、ホスト名だけが問題だったことが証明されました。 mariadb Nextcloud コンテナから名前解決できませんでした。
質問者は Nextcloud 用に独立した MariaDB データベースを求めていた
初期の返信では、PostgreSQL を内蔵したオールインワンの Nextcloud イメージや、phpMyAdmin を使って MariaDB のデータベースとユーザーを手動で作成する方法などの代替案が提案されていました。しかし、それらは最終的な問題ではありませんでした。質問者はすでに MariaDB を稼働させており、Nextcloud から MariaDB に接続する必要がありました。
MariaDB のログからデータベースが正常であることが分かった
コミュニティでは、データベースの初期化と環境変数の設定が完了した後に、MariaDB のパスワードや環境変数を何度も変更しないよう適切に助言していました。多くのデータベースイメージでは、初期化用の環境変数が適用されるのはデータディレクトリを最初に作成したときだけです。
データベースホストは Nextcloud 内部から到達可能である必要があります
Nextcloud の初回セットアップでは、データベースホスト欄に次のようなホスト名とポートを入力できます。
mariadb:3306これは、Docker のネットワーク機能によって名前解決が提供される場合にのみ機能します。 mariadb Nextcloud コンテナから発生したエラーです。
mariadb の getaddrinfo に失敗しました これは DNS 形式のコンテナエラーです
重要なエラーは次のとおりです。
php_network_getaddresses: mariadb の getaddrinfo に失敗しましたこれは、MariaDB がユーザー名とパスワードを受け入れるか拒否するかを判断する前の段階で発生しています。名前を IP アドレスに解決できなければ、データベースの認証情報はまだ評価されていません。
両方のアプリが「Bridge」と表示されていても名前解決は解決しなかった
質問者は、ZimaOS 上で両方のアプリが Bridge ネットワークを使用していると表示されていたことを確認しましたが、 mariadb まだ解決していません。これは Docker に関する重要な注意点です。Docker のデフォルトのブリッジに個別に接続されたコンテナでは、ユーザー定義のブリッジネットワークに接続されたサービスと同じサービス名による DNS 解決が自動的に機能するわけではありません。
したがって、「両方ともbridgeと表示される」ことは、一方のコンテナがもう一方のコンテナ名を解決できることの十分な証拠にはなりません。
クリーンインストールではネットワークの挙動は直らなかった
ユーザーはNextcloudとMariaDBの両方をアンインストールし、フォルダーを削除して、最初から再インストールしました。同じホスト名エラーが再発しました。この否定テストは、問題が単に古いMariaDBデータや一時的なパスワードの誤りではなかったことを示すため、有用です。
Nextcloudのローカルアクセス警告は別の問題だった
ユーザーはオンラインで、次の設定を有効にするよう提案する情報を見つけました。 allow_local_remote_servers。初回セットアップ時にその設定を適用すると、Nextcloudが正常に起動しなくなりました。コミュニティは、このオプションはNextcloudの別のセキュリティルールに対処するものであり、Dockerの名前解決は修正しないと説明しました。
コミュニティはその後、Dockerネットワークの直接テストに切り替えました
回答者は次の確認を求めました。
- 両方のコンテナが実行中かどうか。
- Dockerが報告した実際のネットワークモード。
- Nextcloudが解決またはpingできるかどうか
mariadb; - MariaDBコンテナの現在のDocker IPアドレス。
これは、設定画面のスクリーンショットでは挙動を説明できなくなった後に行うべき、正しい切り分けです。Nextcloudが実行されているのと同じネットワーク名前空間から接続をテストします。
MariaDBコンテナのIPアドレスを使うとNextcloudをインストールできた
決定的なテストは、次の置き換えでした。 mariadb:3306 MariaDBコンテナのDocker IPアドレスとポートを一時的に使う方法です。元の投稿者は、これでNextcloudのインストールが進んだと返信しました。
回答者は結果を明確にまとめました。
-
mariadb:3306失敗しました。 - Dockerの直接IPアドレスをポート3306で指定すると、すぐに動作しました。
これは、コンテナ名の解決に問題があることを強く示しています。
コンテナの直接IPアドレスは有効な診断用回避策です
IPアドレスを使うことでデータベースに到達できることが証明され、インストールを続行できます。今回のケースでは、これは有効な回避策でした。
ただし、コンテナを再作成・削除したり、別のネットワークに接続したりすると、自動割り当てのコンテナIPは変わる可能性があります。恒久的に依存する構成は 172.17.x.x 後で、NextcloudやMariaDBの設定を変更しなくても、問題が発生する可能性があります。
ユーザー定義Dockerネットワークは、長期的にはより優れた設計です
より堅牢なアーキテクチャは、NextcloudとMariaDBを同じユーザー定義Dockerネットワークに接続し、データベースホストに安定したサービス名またはコンテナ名を使用することです。Dockerは、まさにこの目的のためにユーザー定義ネットワーク上で組み込みDNSを提供しています。
現在のZimaOSのネイティブYAML編集では、この種のネットワーク定義が、元のスレッド作成時より簡単になっています。共有Nextcloud・MariaDBネットワークを構築する際は、現在のZimaOS Compose設定モデルを使用してください。
MariaDBのデータを意図的に保持する
MariaDBにすでに動作中のNextcloudデータベースが含まれている場合、Dockerネットワークを変更するだけのために永続データディレクトリを削除しないでください。データベースの内容を再作成せずに、ネットワークの所属先を変更できます。
移行の前に、データベースをバックアップし、現在のユーザー、データベース名、ボリュームのマッピングを記録してください。
Docker DNSを修復するためにNextcloudのセキュリティ制御を無効にしないでください
信頼済みドメイン、ローカルからリモートサーバーへのアクセス、リバースプロキシの設定などは、HTTP／アプリケーション層でNextcloudを保護します。これらは、対応するNextcloudのエラーが発生した場合にのみ変更してください。
A getaddrinfo データベースのホスト名に関するエラーは、Dockerネットワーク層に起因します。
より適切な診断ツリー
- MariaDBが実行中で、3306番ポートで待ち受けていることを確認します。
- 意図したデータベースが存在し、認証情報がわかっていることを確認します。
- Nextcloudがデータベースのホスト名を解決できるかテストします。
- ホスト名の解決に失敗する場合は、データベースコンテナのIPをテストしてください。
- IPで接続できる場合は、データベースのパスワードを変更するのではなく、Dockerネットワークを修正してください。
- 両方のコンテナを安定したユーザー定義ネットワークに移し、永続的なホスト名を使用します。
NextcloudとMariaDBに関するFAQ
MariaDB自体に問題があったのですか？
いいえ。ログには接続を受け付ける準備ができていると表示されていました。
「getaddrinfo for mariadb failed」は何を意味していましたか？
Nextcloudは、認証段階に到達する前にデータベースのホスト名を解決できませんでした。
何によって診断が確定しましたか？
MariaDBコンテナのDocker上の直接IPを使用すると、Nextcloudのインストールを開始できました。
コンテナの直接IPを恒久的なデータベースホストにすべきですか？
動作する可能性はありますが、安定した名前解決が可能な共有ユーザー定義Dockerネットワークのほうが堅牢です。
両方のアプリを再インストールすると問題は解決しましたか？
いいえ。元のユーザーはクリーンな再インストールを実行しましたが、同じホスト名解決エラーが再発しました。
