このスレッドでの最終的な解決策は、毎回「.ppstorageを削除する」ことではありませんでした。根本的なボリューム構成がまだ正しくなかったため、ファイルが再び作成されていたのです。ログから有用な診断結果が得られ、長期的な解決策は、どのホストディレクトリをPhotoPrismのOriginalsパスに割り当てるかを修正することでした。
ログメッセージは手がかりであり、解決策のすべてではない
ある返信では、/DATA/Gallery内にある.ppstorageマーカーに気付き、削除するよう提案しました。ユーザーが削除すると、PhotoPrismはファイルを再作成し、起動に失敗し続けました。これにより、修正が必要なのはファイルだけでなく、パスの関係そのものであることが分かりました。
PhotoPrismではOriginalsとStorageを分離する
公式のPhotoPrismのストレージフォルダーの説明によると、Storageフォルダーには設定、キャッシュ、バックアップ、サムネイル、サイドカーデータが保存されます。通常は、PhotoPrismがサポートする隠し名の構成を使用する場合を除き、Originals内に設定すべきではありません。この上流側のルールから、アプリケーションのStorageを写真のOriginalsツリー内にマッピングすると問題が発生する可能性があることが分かります。
最初のDockerアプリでは、ZimaOSにおけるホストパスとコンテナパスの仕組みを説明しています。一方、ZimaOS App Storeの要件では、複数のテンプレートや依存スタックが存在する場合の、現在のパッケージレベルの背景を確認できます。
データベースや権限を変更する前にログを確認する
公式のPhotoPrism Dockerトラブルシューティングでは、Dockerログを確認することが推奨されており、ディスク、権限、ルート、ストレージに関するエラーが特に挙げられています。このケースでは、ログから十分な情報が得られたため、MariaDBを無作為に再構築したり、ポートを変更したり、OS全体を再インストールしたりする必要はありませんでした。
動作したコミュニティでの変更から分かったこと
ユーザーはBigBearのテンプレートとZimaOS App Storeのマッピングを比較し、Originalsのリンクを変更したところ、PhotoPrismが起動しました。これは、この環境ではストレージマッピングが決定的な要因だったことを示しています。ただし、現在のすべてのPhotoPrismパッケージが、まったく同じホストパスを使用するとは限りません。
結論
PhotoPrismのインストールは完了するものの、すぐに終了してしまう場合は、すべてを一度に変更する前にログを確認してください。このコミュニティ事例では、繰り返し現れる.ppstorageの症状から、PhotoPrismのStorageとOriginalsの関係が正しくないことが分かりました。マーカーを何度も削除するのではなく、ボリュームマッピングを修正することで、アプリを起動できました。
