手動でComposeを編集したため、ZimaOS管理の変数が使われなかった
ZimaOSを使い始めたユーザーが、ストレージパスを変更するためにJellyfinのComposeファイルを手動で編集しました。再起動後、ComposeはPGID、PUID、TZ、AppIDが未設定だと警告し、複数のハードウェアデバイスのマッピングも期待どおりに機能しませんでした。
コミュニティからの回答では、ZimaOSは通常、アプリ管理レイヤーを通じてこれらの値を注入すると説明されました。生成されたYAMLをそのワークフロー外で編集すると、ZimaOSが提供するはずだった環境変数のプレースホルダーだけが残る場合があります。
アプリ設定とボリュームからストレージを変更する
推奨された方法は、Composeファイルを書き換えるのではなく、Jellyfinのアプリ設定を開いてボリュームのマッピングを変更することでした。これにより、ZimaOSはアプリのメタデータ、環境変数、デバイス項目を維持したまま、指定したホスト側のストレージパスを適用できます。
その後、投稿者はこの方法で解決したことを確認しました。アプリ設定で正しいセカンダリドライブのパスを選択すると、手動でComposeを編集することなくJellyfinが正常に動作しました。
再インストールでストア提供の設定を復元できる
生成された設定をすでに大幅に変更している場合、回答では、ダッシュボードからJellyfinを削除し、App Storeから再インストールして元のデフォルト設定に戻す方法が提案されました。削除する前に、正しいホストボリュームのマッピングによって既存のアプリデータを保持する必要があります。コンテナの再インストールは、設定のバックアップの代わりにはなりません。
手動で修復することも可能ですが、その場合は不足しているすべての変数と必要なデバイスパスを正しく定義する必要があります。このスレッドでは、管理対象の値を失う可能性を減らせるため、ZimaOSの設定インターフェースを使う方法が推奨されました。
Proxmoxのディスクマッピングは別の問題だった
投稿者は、Debian 13上のProxmoxでZimaOSを仮想マシンとして実行していました。qm setコマンドで渡したディスクと、古い/etc/fstabのマウント設定が原因で、再起動後にメンテナンスモードの問題が発生しました。また、ZimaOSではユーザーの想定とは異なる名前でデバイスが認識されていました。
この仮想化に関する問題は、Compose変数の不足とは別のものでした。正常に動作させるには、安定したVMディスクマッピングと、ZimaOSのアプリインターフェースで正しく設定したJellyfinのボリュームパスの両方が必要でした。
後から出たNTPの質問はJellyfinの修正とは無関係だった
Jellyfinが動作するようになった後、スレッドでは時刻同期の話題に移りました。ProxmoxホストとゲストのNTP動作はComposeの警告の原因ではないため、別途診断する必要があります。
FAQ
PUID、PGID、TZ、AppIDが空欄になったのはなぜですか？
通常はZimaOSのアプリケーションレイヤーが管理している値を、手動編集によって回避した後に警告が表示されました。
Jellyfinのストレージパスはどこで変更すればよいですか？
確認された解決策は、JellyfinのZimaOSアプリ設定とボリューム設定を使用することでした。
不足していたハードウェアデバイスには新しいドライバーが必要でしたか？
このスレッドでは、ドライバーの障害だったとは確認されていません。管理対象のアプリ設定とボリュームパスを復元することで、投稿者のJellyfin環境は解決しました。
