Jellyfinは、マウントが安定しており、サーバーがネットワーク共有を明示的な外部依存として扱う場合、ネットワーク共有上のメディアを安定して再生できます。
より安全な設計では、Jellyfinのデータベースと設定をローカルの永続ストレージに置き、メディア本体のみをSMBまたはNFSに保存します。これにより、小さな状態書き込みやファイルロックを不要にネットワーク越しで処理せずに済みます。信頼性は、マウントのタイミング、IDマッピング、スループット、レイテンシ、NASが利用できなくなったときの予測可能な動作に左右されます。
Jellyfinのデータベースをローカルに保持する
ファイルベースのアプリケーションデータベースには、大容量の動画ファイルとは異なるアクセス要件と整合性要件があります。ネットワークストレージは容量面で魅力的ですが、Jellyfinのすべてのパスを自動的にネットワークストレージ上に置くべきではありません。
JellyfinのメディアはNFS共有に置き、データベースと設定はローカルに保持できます。これにより、ファイルベースのアプリケーション状態をリモートマウントから切り離せます。
アプリデータはローカルの永続ストレージに保持し、メディアライブラリだけをリモートでマウントしてください。NASメディアセンター構成なら、サーバーの識別情報を共有上に移さずに依存関係を明確にできます。
マウントの利用可能性を起動要件にする
共有がマウントされる前にJellyfinが起動すると、空のディレクトリがライブラリの欠落として認識されることがあります。サービスはマウントを待機するか、誤ったファイルシステムをスキャンするのではなく、明確に失敗するべきです。
堅牢なメディアマウント設計では、systemdの依存関係やマウントチェックを使用し、空のマウントポイントに対してアプリケーションが動作しないようにします。
ホストを再起動し、Jellyfinが通常のスキャンを開始する前に共有の識別情報を確認してください。ディレクトリが存在するかどうかだけでなく、マーカーやマウントポイントのチェックを使用します。
同じサービスIDで権限を確認する
SMBとNFSでは、ローカルディスクとは異なる方法で所有権が変換されることがあります。Jellyfinにはメディアへの予測可能な読み取りアクセスが必要です。また、関連ツールには、全ユーザー書き込み可能な設定を広範囲に適用せず、独自の書き込み権限が必要になる場合があります。
数値UIDとGIDのマッピングをホストとマウントされたファイルシステム全体で文書化しておくと、コンテナからのアクセスを把握しやすくなります。
JellyfinのIDで複数のファイルを読み取り、親ディレクトリを通過して想定どおりアクセスできるかテストしてください。ライブラリ全体を再帰的に変更するのではなく、マウント境界で所有権のマッピングを修正します。
NASのレイテンシと停止に備える
健全なネットワーク共有でも、同時読み取りが発生するとボトルネックになったり、NASのメンテナンス中に一時的に利用できなくなったりします。サーバーは、ライブラリの状態を衝動的に書き換えるのではなく、理解可能な形で機能を低下させるべきです。
JellyfinのキャッシュとメタデータをNFSに移すと、リモート状態への起動時依存が生じます。これは、メディア共有とローカルのアプリケーション状態を異なるストレージ役割として扱うべき理由を改めて示しています。
通常時に想定される最悪の読み取りレイテンシを測定し、共有が制御された形で失われる状況をシミュレーションしてください。放置運用の家庭環境でこの設計に依存する前に、マウントが復旧したときJellyfinが正常に回復することを確認します。
サポートとヒント
もっと読む

ストレージ交換後もNAS共有に古いファイルが表示される場合の確認と対処法
ローカルストレージをアクティブな共有とクリーンなクライアントで比較します。古い状態だと証明されたレイヤーのみを修復し、再接続と再起動後も結果が維持されることを確認します。

ファン、通気口、熱性能の基準値に関するミニPC冷却メンテナンスガイド
再現可能なアイドル時と負荷時の測定値を使用してください。まず外部の通気を清掃し、ファンの動作を確認してください。管理された再テストでも問題の証拠が残る場合にのみ、シャーシを開けてください。

BIOS、起動順序、デバイスのホームサーバーファームウェア更新チェックリスト
バージョン、UEFIエントリ、ストレージ、パススルーの状態を最初に記録します。1度に1つのレイヤーだけを更新し、検証に合格するまでコンソールとロールバックへのアクセスを確保してください。

