ZimaOS上のAutomatic Ripping Machine：Dockerの制限

Automatic Ripping Machine（ARM）はDockerアプリケーションとしてパッケージ化して起動できますが、だからといってZimaOS上で光学ディスクのリッピングが正しく動作するとは限りません。2026年1月のIceWhale Communityスレッドでは、まさにその違いが示されました。ARM自体はコンテナ化されていますが、CD/DVD/Blu-rayを安定してリッピングするには、光学ドライブとホストLinuxのデバイス層への、通常より深いアクセスが必要です。

このスレッドでは、ZimaOS上でARMが完全に動作する構成は確認されませんでした。ある参加者は、ARMが正常に動作せず、別のDockerリッピングツールでは読み取り不能ディスクエラーが発生したと報告しました。実際的なコミュニティの推奨は、2台目のLinuxマシンでリッピングし、完成したファイルをSMBまたはNFS経由でZimaOSに保存することでした。現行のARMドキュメントは技術的な診断を裏付けています。Docker構成では、光学デバイスのパススルー、SCSI汎用デバイス、ホストと一致するUID/GID、さらに構成によっては特権モードとホストのudev統合が必要です。

通常のDockerアプリではディスクのリッピングに不十分な理由

ほとんどのNASアプリに必要なのは、ネットワークポートとデータボリュームだけです。光学ディスクのリッピングは異なり、MakeMKVやARMなどのソフトウェアはドライブハードウェアと直接通信する必要があります。

一般的なLinuxの光学デバイスには、次のようなものがあります。

/dev/sr0
/dev/sg1

その /dev/sr* デバイスは光学ドライブを公開しますが、対応する /dev/sg* 低レベルのコマンドには、SCSI汎用デバイスが必要になる場合があります。コンテナに通常のフォルダーマウントしか渡されていない場合、これらの操作は実行できません。

ZimaOSスレッドで報告された症状

あるコミュニティユーザーは次のように報告しました。

ARMは正常に動作しませんでした。
別のDockerリッピングツールは、制限された構成でのみ起動しました。
syslog-ngではソケットや権限に関する問題が発生しました。
リッピングでは、物理ディスクが正常と考えられていた場合でも、読み取り不能ディスクエラーが発生しました。

別の返信では、これらの症状はアクセス権が不完全な場合と一致すると説明されていました。 /dev/sr0SCSIパススルー、udevイベント、その他のホストレベルの権限。

現行のARMドキュメントがハードウェア要件を確認

現行のARM Dockerドキュメントでは、次のコマンドで光学デバイスを確認するようユーザーに指示しています。

lsscsi -g

ドライブは概念的には次のように表示される場合があります。

CD/DVD ... /dev/sr0 /dev/sg1

ARMは続いて、両方のデバイスをコンテナに渡すことを推奨しています。

--device="/dev/sr0:/dev/sr0"
--device="/dev/sg1:/dev/sg1"

現行のARM Dockerドキュメントを参照してください。

ARMでは特権コンテナアクセスも必要になる場合があります

ARMの現行Dockerソースからのビルドガイドには、次の記載があります。

--privileged

また、そのトラブルシューティング文書では、ディスクの挿入やudevによるリッピングを完全に機能させるには、特権モードが必要なユーザーもいると説明されています。

これは通常のメディアサーバーコンテナとの大きな違いです。特権モードではコンテナにホストデバイスへの広範なアクセス権限が与えられるため、信頼できないイメージに対して安易に有効化すべきではありません。

ディスク挿入の自動化はホストに依存する

ARMは、ディスクが挿入されると自動的に反応するよう設計されています。ARMのDockerドキュメントでは、挿入によってリッピングワークフローを開始できるよう、ホスト側のドライブ設定とudevの動作を想定しています。

ARMのトラブルシューティングガイドでは、ディスク挿入イベントについてホストのログを確認するよう提案しており、ホストのudev統合が機能していない場合、コンテナが正常でも自動リッピングに失敗する可能性があることを確認しています。

現在の参考資料：ARMのDockerトラブルシューティング。

ARMがドライブを認識していてもMakeMKVが失敗する理由

ARMのドキュメントでは、次の項目しか渡されていない場合、MakeMKVがドライブを検出または読み取れない可能性があると明確に警告しています。 /dev/sr0 が渡され、一致するSCSI汎用デバイスが省略されている場合。

そのため、ZimaOSの議論に登場した「ディスクを読み取れない」という症状は特に重要です。ホストで読み取り可能な光学ドライブがあっても、コンテナがMakeMKVに必要なすべてのデバイスインターフェースを持っているとは限りません。

ARMにはホスト権限の一致も必要

現在のARMドキュメントでは、次の項目を作成することを推奨しています。 arm ホスト上のユーザー／グループを作成し、コンテナの次の値を一致させます。

ARM_UID
ARM_GID

そのホストアカウントで。メディア、設定、音楽、ログの各ディレクトリは、そのIDで書き込み可能でなければなりません。

IDが一致しない場合、リッピングのワークフローが光学ドライブに到達する前にARMが失敗する可能性があります。

ZimaOSについて元のスレッドが実際に確認していること

元の議論は、ARMがZimaOS上で永遠に不可能だとは確認していません。確認されているのは、2026年1月時点で、必要な光学ドライブ権限をすべて正常に公開できる検証済みの構成を参加者が持っていなかったということです。

ある返信では、主な制限はコンテナから利用できるハードウェア／デバイスアクセスのレベルにあると考えられていました。元の著者は、リッピングに2台目のマシンを使うという実用的な回避策を受け入れました。

この結果を、Dockerではディスクをリッピングできない、あるいはZimaOSがARMを決してサポートできないという一括した主張に変えてはいけません。

コミュニティによる実用的な回避策

元の著者が受け入れた最終案は次のとおりです。

光学ドライブに直接アクセスできる別のLinuxマシンにARMをインストールします。
そこでディスクをリッピングしてトランスコードします。
完成したファイルをZimaOSのストレージに保存または移動します。

保存先にはマウント済みのSMBまたはNFS共有を指定でき、リッピング後にファイルを転送することもできます。

これにより、ZimaOSはストレージとメディア配信に集中し、もう一方のマシンが光学ハードウェアの低レベル処理を担えます。

ARMがネットワーク経由の出力ワークフローを正式にサポート

ARMのDockerドキュメントでは、出力ボリュームをネットワーク共有に指定できると説明されていますが、パフォーマンスはネットワークとマウントの動作によって異なります。

一般的な構成は次のとおりです。

光学ドライブ
     ↓
ARM Linuxマシン
     ↓
ローカル一時作業ストレージ
     ↓
完成したリップ
     ↓
ZimaOS SMB/NFSメディアライブラリ

リッピング/トランスコードの段階で高速なローカル一時ストレージを使用し、完成した出力のみをNASに移動すると、ネットワークやロックに関する問題を軽減できます。

ZimaOSでARMを直接テストしたい場合

カスタムアプリの構築を試す前に、ホストのデバイス情報を収集します。

lsscsi -g
ls -l /dev/sr*
ls -l /dev/sg*

次に、ZimaOSのカスタムDocker設定で、ARMに文書化されている要件をすべて表現できるか確認します。

光学 /dev/sr* デバイス；
対応する /dev/sg* デバイス；
必要なホスト/コンテナ権限；
永続的な設定、ログ、音楽、メディアのボリューム；
必要に応じた特権モードまたは同等の機能；
自動リッピングで使用されるホスト側のイベント/udevワークフロー。

ZimaOSが現在のアプリケーションモデルを通じて要件のいずれかを公開できない場合、通常のDockerボリュームパスを変更してもリッピングの失敗は解決しません。

セキュリティと信頼性に関する注意事項

特権コンテナはホストへの広範なアクセス権を持ちます。信頼できるイメージのみを使用し、公開範囲を理解してください。
ARMに関係のないホストデバイスを渡さないでください。
ARMには、必要なディレクトリへの書き込みアクセスのみを付与してください。
十分な空き容量のある専用の作業ディレクトリを使用してください。光学ディスクのリッピングとトランスコードでは、一時的にかなりのストレージが必要になる場合があります。
完成したメディアは、リッピングのワークフローとは別にバックアップしてください。

ZimaOSでARMを使用するためのチェックリスト

ZimaOSホストに光学ドライブが表示されることを確認します。
を実行します lsscsi -g および両方を特定します /dev/sr* および /dev/sg*.
ZimaOSのカスタムアプリ機能とARMの現在のDocker要件を比較します。
ARM_UID/ARM_GIDを、書き込み可能なホストディレクトリに合わせます。
特権モードとホストイベント連携が利用可能か確認してください。
ARM WebUIが起動しているからといって、MakeMKVがドライブに正しくアクセスできるとは限りません。
デバイスのパススルーが安定しない場合は、別のリッピング用マシンを使用し、完了した出力をZimaOSに保存してください。

ZimaOSでのAutomatic Ripping Machineに関するFAQ

ARMはZimaOSにインストールできますか？

コンテナ化は可能ですが、元のスレッドでは、光学ドライブのパススルーと権限が障害となっていたため、完全に動作するZimaOSでのリッピング設定は確認されていません。

なぜリッパーはディスクを読み取れないと言うのですか？

考えられる原因の1つは、デバイスのパススルーが不完全なことです。ARMの現在のドキュメントでは、MakeMKVに光学 /dev/sr* デバイスと対応するSCSI汎用デバイス /dev/sg* デバイス。

ARMには特権モードが必要ですか？

現在のARM Dockerドキュメントには、一部の構成に関するセットアップおよびトラブルシューティングの手順として、特権モードが含まれています。すべてのインストールで必要かどうかは、ホストとデバイスのワークフローによって異なります。

元のスレッドで承認された解決策は何でしたか？

元の著者は、2台目のマシンにARMをインストールし、リッピングしたファイルをZimaOSサーバー上のストレージに移す方法を選びました。