ImmichとNextcloudは、競合せずに写真ライブラリを共有できる？

ImmichとNextcloudは同じ写真ファイルを共有して運用できますが、信頼性は、ファイルシステム上の変更をどちらのシステムが管理するのか、そしてImmichがその変更をどのように検知するのかを定義できるかどうかに左右されます。

どちらかのアプリケーションがファイルを移動、削除、編集するたびに、独立した2つのデータベースを自動的に同期し続ける魔法のような共有状態レイヤーはありません。一般的な構成では、Nextcloudをファイル管理と同期のレイヤーとして維持し、Immichには閲覧と認識のためにマウントした外部ライブラリを見せます。これにより役割を分離できますが、再スキャンが必要となる境界も明確になります。

共有境界としてファイルシステムを扱う

NextcloudとImmichは、それぞれ異なるアプリケーションデータベースを持ち、自身の状態について異なる前提で動作します。同じ基盤メディアを共有しても、それらのデータベースが統合されるわけではありません。したがって、安全な統合で問われるのは、両方から見えるファイルシステムのツリーと、そこを変更できるアプリケーションをどう定めるかです。

Nextcloudコミュニティの外部ライブラリ統合に関する議論では、2つの製品を自動データベースプロトコルで接続しようとするのではなく、Nextcloudが管理する写真フォルダーをImmichに公開する方法が説明されています。このパターンでは、ファイルシステムが統合の接点になります。

共有契約はシンプルに保ちましょう。オリジナルの正規コピーを1つ、Immich内部の予測可能なマウントパスを1つ、そして名前変更と削除の明確な管理者を定めます。両方のアプリケーションが同じツリーを独自に整理すると、最終的なパスだけからすべての意味や意図をどちらのデータベースも推測できません。

Immichへの読み取り専用アクセスで書き込み競合を減らす

Nextcloudをファイル配置の情報源とする場合、そのツリーをImmichから読み取り専用でマウントすると、写真インターフェースからの削除やメタデータ編集によって、Nextcloudが引き続き管理していると認識しているファイルが変更される可能性を大幅に減らせます。Immichはソースファイルを変更せずに、アセットのインデックス作成と表示を行えます。

Immichをビューアーとして使用する方法に関するユーザーレポートは、この役割分担を示しています。Nextcloudが保存ファイルを管理し、Immichがマウントされたコンテンツに対して、より高機能な写真閲覧と認識を提供します。

読み取り専用アクセスには境界があります。ソース側のメタデータやサイドカーの変更を必要とする編集は、Immichから永続的なファイル編集として扱えません。評価、説明、ファイルレベルの変更をNextcloud、Immichのデータベース、または別のメタデータワークフローのどこで管理するのか、あらかじめ決めておきましょう。

外部ライブラリのスキャンが同期の工程になる

Nextcloudがファイルを追加、削除、整理すると、Immichはファイルシステムと外部ライブラリの表示を突き合わせる必要があります。このスキャンによって、ファイルレベルの変更がImmichのアセット状態に反映されるため、Nextcloudでの操作と写真インターフェースの表示には遅延が生じることがあります。

WaterlooコミュニティWikiのNextcloudライブラリの方法では、NextcloudのユーザーデータをImmichの外部ライブラリとして公開する実用的なパターンが示されています。具体的なスクリプトは環境によって異なりますが、安定したマウントパスと意図的な再スキャンという原則は変わりません。

スキャンが完了する前に、その遅延をデータベース同期の失敗と判断しないでください。逆に、マウントが正常に完了したからといって、変更が即座に反映されると考えてもいけません。ファイルシステムからの可視性、スキャンのスケジュール、後続のサムネイル生成や検索ジョブは、それぞれ別の段階です。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

移動と削除が主な競合境界になる

Nextcloudで行った名前変更やフォルダー移動は、Immichから見ると、元のパスが消えて新しいパスにファイルが現れたように見える場合があります。写真アプリケーションがその移動前後でアセットの同一性を維持できない場合、アルバムや編集内容などのアプリケーション固有の関連付けが、再調整後に同じ論理項目へ紐付かなくなる可能性があります。

整理し直した外部ファイルに関する最近のImmichの議論では、パスの変更によって処理が再実行された事例が報告されています。だからこそ、共有するNextcloudツリーには慎重な整理ルールを設け、大規模なパス移行を行う前に、まず小規模なテスト対象で検証する必要があります。

追加の同期ツールがタイムスタンプを書き換えたり、重複コピーを生成したり、両方のアプリケーションの背後でファイルを変更したりする場合、書き込み担当を1つにするモデルだけでは不十分です。その場合は第三の書き込み元を文書化し、写真アプリケーションやクラウドアプリケーションのどちらか一方だけを責めるのではなく、統合構成の一部として扱ってください。

4つの操作で統合を検証する

使い捨ての写真を4枚入れたテストフォルダーを作成します。指定した管理アプリケーションから、追加、メタデータ側の編集、移動、削除を1回ずつ実行します。各操作の後、想定したスキャンが完了するまで待ち、Immichがアセットをどのように表示するか、アプリケーションのメタデータが維持されるか、Nextcloudとの整合性が保たれるかを記録します。

ZimaSpaceのデータパスのフレームワークを使って、ファイルの所有権、スキャン、生成された派生データ、データベースの状態を切り分けましょう。統合の信頼性は、各操作の後にどのレイヤーが変化すべきかを把握することで生まれます。

4つの操作で予測可能な結果が得られ、復旧担当が文書化されている場合にのみ、その構成を採用してください。移動でアセットが再作成される、削除したファイルが再び表示される、またはメタデータが失われる場合は、全体の家族ライブラリを公開する前に、それらの操作を1つのシステムに限定するか、統合パターンを変更してください。