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

ZimaOSにカスタムDockerアプリをインストールする:Subsyncarrの例

A June 2026 beginner thread about installing Subsyncarr outside the ZimaOS App Store. A community reply explained how Docker image, volumes, environment variables, and SCAN_PATHS map into the manual installer; current Subsyncarr releases now also expose a Web UI on port 3000.

ZimaOSの「カスタマイズしたアプリをインストール」フォームは、通常のDocker Composeの概念を各フィールドに変換していると理解すれば、はるかに使いやすくなります。2026年6月のソーススレッドは、ユーザーがすでにJellyfinを稼働させており、字幕処理用にSubsyncarrを追加したい一方で、既存のメディアサーバーを壊すことを心配していたため、初心者向けの優れた例です。

コミュニティの回答は、単に「Composeファイルを貼り付けてください」と言ったのではありません。Dockerイメージ、タグ、ネットワーク、ボリューム、環境変数、デバイス、コンテナコマンドの各項目にどの値を入力すべきか、そして何より、SCAN_PATHSなどの環境変数にはコンテナ内部から見えるパスを使用する必要がある理由を説明しました。

ZimaOSフォームをDocker設定として読み取る

Dockerイメージ、タグ、タイトル、Web UI、ネットワーク、ポート、ボリューム、環境変数、デバイス、コマンドを示すZimaOSのカスタムアプリフォーム
手動インストーラーでは、標準的なコンテナ設定が、rawのCompose YAMLではなく個別のフィールドとして表示されます。

ソース例では、コミュニティは基本的なComposeフィールドをおおむね次のように対応付けました。

  • Dockerイメージ → mrorbitman/subsyncarr
  • タグ → 希望するリリースタグ。従来は latest
  • タイトル → などのわかりやすいアプリ名 Subsyncarr
  • ネットワーク → bridge ただし、アプリの最新の手順で別の方法が求められている場合を除きます

アップストリームのCompose例を唯一の正しい情報源として使用する

イメージ、メディアボリューム、cronスケジュール、スキャンパス、除外ディレクトリ、同期エンジンを示すSubsyncarrのDocker Compose例
正しい作業は、コンテナが内部で期待する内容を変更せずに、各Compose設定をZimaOS向けに変換することです。

Subsyncarrは進化を続けているため、インストール前に、古いコミュニティのスクリーンショットと現在のSubsyncarrコンテナ設定を比較してください。

ボリュームは最も重要な部分です

Dockerボリュームには2つの側面があります。

  • コンテナパス:Subsyncarrが自身のファイルシステム内で認識するパス。
  • マッピングは概念的には次のようになります:

ホスト: /DATA/Media/Movies

コンテナ: /movies
正確なホストフォルダーは、Jellyfinのライブラリが実際にどこに保存されているかによって異なります。他のユーザーのパスをそのままコピーしないでください。ZimaOSの「ファイル」アプリを確認するか、Jellyfinに既存のボリュームマッピングを調べて、両方のコンテナが同じメディアを参照するようにしてください。

カスタムメディアアプリケーションを追加する前に、実際のZimaOSストレージフォルダーがコンテナパスになる仕組みについての現在の説明を確認すると役立ちます。

SCAN_PATHSはコンテナ側と一致する必要があります

これは元の返信で伝えた重要なポイントでした。ホストフォルダーが次の場所にマッピングされている場合

その後、Subsyncarrはスキャンします コンテナ内の /movies コンテナ内の.

正しい例:

SCAN_PATHS=/movies,/tv,/anime

それらがホストパスにすぎない場合は不正です:

SCAN_PATHS=/DATA/Media/Movies

明示的にマッピングされていない限り、コンテナから任意のZimaOSホストパスを参照することはできません。

環境変数は1つずつ翻訳する

Composeのソース例には、タイムゾーン、cronスケジュール、スキャンパス、除外ディレクトリ、同期エンジンなどの変数が含まれていました。それぞれを、上流アプリケーションが想定する値の形式と同じ形式で「環境変数」セクションに追加してください。

cron式を「改善」したり、コンテナパスの名前を変更したりしないでください。まず上流の設定を忠実に再現し、その後、アプリケーションが正常に動作することを確認してから変更を加えます。

現在のSubsyncarrリリースにはWeb UIがあります

2026年のコミュニティ返信では、アプリケーションがそのポートを公開しているとドキュメントに記載されていない限り、Web UIとポートは空欄のままにするよう案内していました。未知のアプリケーションについては正しい助言でしたが、現在のSubsyncarrのリリースでは、ポート3000のWeb UIと永続的なアプリケーションデータが提供されています。

ダッシュボードを使用する場合は、ホストポートをコンテナポート3000に公開し、ZimaOS の Web UI フィールドにそのホストアドレスを設定してください。ポートがすでに使用されている場合は、上流から内部サービスのポート自体を変更できると案内されていない限り、ホスト側だけを変更してください。

Subsyncarr 独自のアプリケーションデータを永続化する

重要なのはメディアフォルダーだけではありません。現在の Subsyncarr には専用の永続データもあります。コンテナを更新しても保持されるホストフォルダーにそのアプリケーション状態を保存し、バックアップにも含めてください。

字幕を書き込む必要がある場合は PUID と PGID が重要

字幕処理には、読み取りアクセスだけでは不十分です。メディアと同じ場所にある字幕ファイルの作成、名前変更、変更が必要になる場合があります。現在の Subsyncarr は PUID と PGID に対応しているため、スキャンはできても字幕の書き込みに失敗する場合は、コンテナユーザーをメディアフォルダーの所有者またはグループ権限に合わせてください。

上流で必要とされない限り、Devices と Container Command は空のままにする

コミュニティの回答では、存在するからという理由だけですべての項目を入力しないよう、適切に案内されています。デバイスマッピングは GPU やシリアルデバイスなどのハードウェア用です。コンテナコマンドは、イメージのデフォルト起動コマンドを上書きします。上流の特定の要件がない限り、どちらも追加しないでください。

これで Jellyfin が動作しなくならない理由

別のコンテナを追加しても、両方のアプリケーションが同じメディアフォルダーを読み取るだけで Jellyfin が変更されることはありません。より大きなリスクは権限です。Subsyncarr にファイルの名前変更や書き込みを許可する場合は、意図したメディアパスと字幕パスだけが設定によって処理されるようにしてください。

アプリケーションをコレクション全体に向ける前に、小規模なテスト用ライブラリから始めてください。

ZimaOS カスタムアプリに関するよくある質問

SCAN_PATHS ではホストパスとコンテナパスのどちらを使用しますか?

ボリュームマッピングで作成したコンテナパスを使用してください。

ZimaOS のカスタムアプリフォームのすべての項目を入力する必要がありますか?

いいえ。ポート、デバイス、コマンドなど、アプリケーションが実際に必要とする項目だけを設定してください。

現在の Subsyncarr には Web UI がありますか?

はい。現在のリリースでは、ポート3000でダッシュボードが公開されています。

Subsyncarr は Jellyfin と同じメディアフォルダーを使用できますか?

はい、両方のコンテナが同じ実際のホストフォルダーをマッピングし、適切な権限が設定されている限り可能です。