この2026年5月のスレッドは、ZimaOSを一晩使った後の苛立ち混じりの第一印象から始まりました。AdGuard HomeとPi-holeはユーザーの192.168.60.0/24 LANではなく、分離されたDockerネットワーク内で動作しているように見え、Jellyfinは何度か試してようやく動作し、MacBook ProからのTime Machineバックアップは失敗しました。しかし、さらにテストを行った結果、当初の結論のうち2つが変わりました。AdGuard Homeは動作するようになり、Time Machineの問題はMacBookからTrueNASの共有先へ移行しても再現したため、原因はZimaOSではない可能性が高まりました。
したがって、このスレッドはOSへの評価というより、トラブルシューティングの事例として役立ちます。NASプラットフォーム自体を原因と判断する前に、Dockerネットワーク、アプリテンプレート、クライアント側のバックアップ動作を切り分ける必要があることを示しています。
AdGuardのセットアップウィザードにLAN IPではなくDockerのアドレスが表示された
標準インストール後、ユーザーのAdGuard Homeセットアップ画面には、127.0.0.1や172.17.0.2などのアドレスが表示されました。ユーザーは、ZimaOSホストの固定LANアドレスである192.168.60.241が表示されると考えていました。
ホストネットワークへの切り替えは、単純な解決策ではなかった
ユーザーは、Composeのネットワークモードをhostに変更する、コミュニティで紹介されていた回避策を見つけました。さらにアプリの設定も変更したところ、インストールしたアプリにアクセスできなくなりました。この結果は重要です。ホストネットワークを使用すると、ポートの所有関係だけでなく、App Storeテンプレートが前提としている構成も変わるためです。
DNSコンテナに対してnetwork_mode: hostを万能な解決策として扱わないでください。アプリが本当にホストレベルのネットワーク可視性を必要とする場合には便利ですが、ZimaOSダッシュボード、別のDNSリゾルバー、または別のコンテナとポートが競合する可能性もあります。
最終的にユーザーは別のアプリバリアントでAdGuardを動作させた
元の投稿者は後日、標準パッケージではなくAdGuardアプリのNetworkバージョンを使い、必要なWebインターフェースのポートマッピングを追加する手順を見つけたとスレッドを更新しました。セットアップアシスタントには期待していた192.168.60.xアドレスが表示されなかったものの、AdGuardは動作したと説明しています。
これは重要な診断原則を示しています。LANクライアントからのDNSリクエストに応答するために、コンテナのセットアップウィザードへホストのLANアドレスが表示される必要はありません。重要なのは、公開されたDNSポートとWebポートにネットワークからアクセスできるかどうかです。
ZimaOSホスト自体には有効な固定ネットワーク設定があった
DNSコンテナで重要なのは、ウィザードに表示される見栄えのよいアドレスより正しいポート
AdGuard HomeやPi-holeは、一般的なWebアプリよりもネットワーク設定の影響を受けやすいアプリです。クライアントは通常、UDPとTCPの両方でポート53のDNSにアクセスする必要があります。管理UIには別のWebポートが使用されます。
DNSアプリが正常と表示されているのにLANクライアントから利用できない場合は、ホストの固定IPを変更する前に、実際に公開されているポートと、別のサービスがすでにポート53を使用していないかを確認してください。
Jellyfinが動作したことで、Docker全体やストレージの完全な障害ではないことが分かった
ユーザーによると、Jellyfinは最終的に動作しました。これはAdGuardのネットワーク設定が正しいことを証明するものではありませんが、同じインストール環境でZimaOSがDockerアプリを実行し、メディアストレージにアクセスできることを示しています。したがって、トラブルシューティングの焦点は、コンテナスタック全体を使用不能とみなすのではなく、アプリ固有のネットワーク設定に絞ることができました。
Time Machineの問題はMacBookからTrueNASにも引き継がれた
スレッドで最も大きな修正となったのは翌日のことでした。ユーザーはZimaOSを消去して再インストールし、Time Machineを再度テストしました。Montereyを搭載した古いMac miniではバックアップに成功しましたが、新しいMacBookでは引き続き失敗しました。
その後、TrueNASのTime Machine共有も試しましたが、MacBookはそこでも失敗しました。この比較テストにより、考えられる原因はZimaOSからMacBook、またはそのmacOS/SMBの動作へと移りました。
別のNASでクロステストすることが非常に有効な理由
同じクライアントが独立した2つのNASプラットフォームに対して失敗し、一方で別のMacがZimaOSのターゲットに対して正常に動作するなら、「ZimaOSのTime Machineが壊れている」という説明は、もはや最も単純な結論ではありません。
これはNASのトラブルシューティングにおける有用な一般則です。接続の片側だけを一度に変更してください。2台目のサーバーまたは2台目のクライアントを使うことで、問題がサーバー、クライアント、または特定の組み合わせのどれに追従するのかをすばやく確認できます。
現在のZimaOSは、現在のストレージ設定とアプリ設定で評価する
元のスレッドは2026年5月時点のZimaOSを扱っています。それ以降も、アプリ設定、YAML編集、ストレージ管理、バックアップ動作など、プラットフォームは変化し続けています。新規インストールでは、2026年時点のApp Storeテンプレートが変わっていないと決めつけるのではなく、現在のZimaOSの機能とストレージモデルを基準にしてください。
新規インストール時の、よりよいテスト手順
- 多くのアプリをインストールする前に、ストレージとアプリデータの保存場所を設定する。
- Jellyfinなどの単純なアプリ、または別のWebサービスを1つ動作確認する。
- DNSアプリでは、WebUIとは別にポート53を確認する。
- 既存のブリッジやポートマッピングを理解するまで、ホストネットワークへ切り替えない。
- 可能であれば、Time Machineで別のMac、または別のSMB Time Machineターゲットをテストする。
- 問題がどのコンポーネントに追従するのかが分かってから、そのコンポーネントを根本原因の候補として扱う。
ZimaOSの新規インストールに関するトラブルシューティングFAQ
元のユーザーの環境では、最終的にAdGuard Homeは動作しましたか？
はい。ユーザーは、Networkアプリのバリアントと追加のポート設定で動作したと説明しています。
AdGuardのセットアップウィザードには、期待していた192.168.60.xアドレスが表示されましたか？
いいえ。ただし、アプリケーション自体は動作しました。ウィザードには、コンテナから見えるインターフェースが表示されていました。
Time Machineの問題の原因がZimaOSだと証明されましたか？
いいえ。MacBookはTrueNASのTime Machine共有に対しても失敗しましたが、古いMac miniはZimaOSに対して正常に動作しました。
