サードパーティ製のPaperless-ngxアプリが、Composeファイルで不正なTikaイメージを参照しているために失敗する場合は、同じ壊れたComposeを何度も再インストールするのではなく、アプリ定義を修正するか、保守されているパッケージを使用してください。元のスレッドでは、Coolstoreパッケージがユーザーの認識では誤ったTikaイメージを指定していました。一方、BigBearパッケージは何度か試した後、最終的に正常にインストールされました。
以前のBigBearでの試行が失敗した理由は、スレッドでは明らかにされていません。そのため、IPセクションだけを変更すれば必ず解決する、と述べるのは不正確です。確実な方法は、サードパーティ製Composeを現在のPaperless-ngxのアップストリーム要件と比較することです。
TikaはPaperlessのオプションサービスです
現在のPaperless-ngx設定リファレンスでは、TikaとGotenbergはOffice文書やメールの解析に使用されるオプションサービスだと説明されています。この連携を有効にする場合、Paperlessには到達可能なエンドポイントを設定する必要があります。
つまり、Paperlessの中核となるコンテナ定義がそれ以外の点で有効でも、連携を有効にしていれば、Tikaサービスの不正なイメージによってインストールが壊れる可能性があります。
CoolstoreとBigBearはサードパーティ製パッケージとして扱う
コミュニティからの返信では、Coolstoreがサードパーティ製のアプリソースであることが正しく指摘されていました。そのパッケージ内の壊れたイメージ参照は、ZimaOSの中核的な不具合と解釈するのではなく、メンテナーに報告すべきです。
いずれかのストアパッケージが古い場合は、アップストリームのPaperless Dockerサンプルや、別の保守されているパッケージと比較してください。スタックを変更する前に、既存のデータパスを維持してください。
Composeを慎重に編集または再インポートする
現在のZimaOSでは、カスタムDocker Compose定義をインポートできます。アプリストアの定義に不正なイメージやサポートされていないフィールドが含まれている場合は、カスタムComposeのトラブルシューティングガイドを利用するのが安全です。
ZimaOS 1.7.1では、最新のリリースノートに、YAML保存時の互換性向上も記載されています。ただし、この改善によって、サードパーティリポジトリにある誤ったイメージ参照が自動的に修正されるわけではありません。
Paperlessを再度インストールする前に
- Paperlessのデータ、メディア、データベースの保存先をバックアップします。
- すべてのイメージ参照が存在し、保守されていることを確認します。
- Paperless、データベース、Redis、Tika、Gotenbergが、意図したComposeネットワーク上にあることを確認します。
- 成功した修正を特定できるよう、一度に変更する障害要因は1つだけにします。
スレッドでの事例のように、何度か再試行した後に突然インストールが成功した場合は、原因を推測してはいけません。元の失敗原因は未解決のまま、ユーザーによって成功が確認された結果として記録してください。
