Immichはファイルの所有権を取得せずに外部ライブラリを使用できますか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Can Immich Use an External Library Without Taking Ownership of the Files?

はい。Immichは、元のファイルをImmichの外部で管理したまま、外部ライブラリのインデックスを作成できます。Immichが元データの名前変更や削除を行ってはならない場合は、読み取り専用でマウントしてください。

家族写真がすでに整理されたNASツリーに保存されており、Immichにはファイルの正式な管理者ではなく、検索と閲覧の機能だけを追加したい場合、これは実際の互換性に関する問題になります。まずは使い捨て可能なパスまたはアカウントで始め、以前の動作状態を利用できるようにしておき、一度きりの接続テストではなく、元のワークロードに基づいて設計を判断してください。

サポート対象のアーキテクチャとリスクの高い構成を分ける

サポート対象の構成は、書き込み可能なアップロード領域とアプリケーション状態を分離した、読み取り専用の外部ライブラリです。対照的に、リスクの高い構成は、書き込み可能なソースマウントをImmichが管理するアップロードストレージと混同するものです。どちらの構成を変更する場合も、変更前にバージョン、ID、アドレス、マウントパス、権限、現在観測できる状態を記録してください。

関連するImmich外部ライブラリの定義が、最初の互換性の境界を示します。これを使って主張の範囲を限定し、文書化された機能が設計全体の動作を証明すると考えず、この正確なホームサーバー上で同じ動作を確認してください。

テスト前に判断基準を書いておきます。成功とは、元のファイルが元のパス、ハッシュ、所有権、削除保護を維持したまま、アセットのインデックス作成と表示が行われることです。スキャンで権限が見つからない、編集によって元データへの書き込みが発生する、または操作によって元ファイルを削除・名前変更できる場合は失敗です。これにより、部分的な接続やコマンドの正常終了を、エンドツーエンドの互換性と誤認せずに済みます。

正確なストレージとネットワーク経路を再現する

管理対象を1つに絞って検証します。代表的な小さなフォルダーを読み取り専用でマウントし、外部ライブラリを作成してスキャンし、Immichでメタデータを編集し、削除とファイルシステム上の名前変更を試します。クライアント、ワークロード、ファイルセット、アカウント、タイミングを一定に保ち、変更したコンポーネントだけが原因として考えられるようにしてください。

読み取り専用ボリュームマウントを使い、この経路で重要となる2番目の観測対象を選びます。トランザクションの両側を記録してください。リゾルバーまたはルート、ネゴシエートされたプロトコル、プロセスID、終了ステータス、レイテンシ、転送バイト数、リカバリーイベントを含めます。

タイトルに示されたライフサイクルイベント（再作成、再接続、再マウント、再起動、フェイルオーバー、またはクライアント変更）の後にテストを繰り返します。古いソケット、キャッシュ、または認証情報が有効な間だけ動作する設計は、合格とはいえません。

mount /photos:/external:ro -> パイロットフォルダーをスキャン -> ハッシュを比較 -> メタデータ編集と削除の動作をテスト

永続性、タイムアウト、リカバリーの結果を解釈する

合格：元のファイルが元のパス、ハッシュ、所有権、削除保護を維持したまま、アセットのインデックス作成と表示が行われる。この状態を生み出した正確なバージョンとトポロジーを保存してください。この結論が適用されるのは、その条件下であり、プロトコルのすべての実装に対してではありません。

不合格：スキャンで権限が見つからない、編集によって元データへの書き込みが発生する、または操作によって元ファイルを削除・名前変更できる。どちらの主要な分岐に原因があると判断する前に、DNS、MTU、ID、ファイアウォールの状態、ストレージのレイテンシ、キャッシュされたセッションなど、共有依存関係を確認してください。

例外：ファイルを削除せずにライブラリ定義を削除し、以前のマウントを復元して、読み取り専用パスとIDマッピングを修正します。再現可能な観測によってどの境界が失敗したか特定できるまで、権限を拡大したり、元データを削除したり、通信セキュリティを弱めたり、動作中のストレージを置き換えたりしないでください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

復元レベルの確認後にのみ設計を維持する

観測された分岐に対応する措置だけを適用し、その後に元のワークロードを再実行します。想定される同時負荷の下で、関連する2回のライフサイクルサイクルを通じて、元のファイルが元のパス、ハッシュ、所有権、削除保護を維持したままアセットのインデックス作成と表示が行われる場合にのみ、設計を維持してください。

Immichの読み取り専用ソースを使って、最も近い依存ワークフローを確認します。新しい設計が有効な間も、そのアクセス、タイミング、リカバリーの動作が変わらないことが必要です。

スキャンで権限が見つからない、編集によって元データへの書き込みが発生する、または操作によって元ファイルを削除・名前変更できる場合は、停止して保存済みの状態に戻してください。別の回避策を追加するのではなく、タイムスタンプ、正確なバージョン、ルートまたはマウントの証拠、最小限の再現手順を添えてエスカレーションしてください。

写真アカウントの分離と結果を照合し、リスクが別のネットワーク、ID、バックアップ、またはストレージ層に移っただけにならないようにしてください。

したがって、Immichの外部ライブラリにおける所有権についての条件付きの回答は、冒頭の判断であり、無条件の「はい」ではありません。観測可能な合格状態が受け入れ基準であり、不合格状態がロールバック基準です。