ownCloudのバージョンアップグレード後に「整合性チェック失敗」が発生する問題を修正する

アップグレード後にownCloudで「整合性チェックに失敗しました」と表示される場合は、ファイルを変更する前に、無効ファイルレポートを使用して何が失敗したかを特定してください。再スキャンは検証を繰り返すだけで、欠落したファイルの復元、カスタム編集の取り消し、修正されたアプリリリースのインストールは行いません。コアファイルについては、アップグレードしたownCloudのリリースと完全に一致するものと比較してください。アプリの署名に問題がある場合は、互換性があり、正しく署名されたアプリのアップデートを探すか、開発者に問い合わせてください。

適切な修復方法は、警告の範囲によって異なります。部分的なアップグレードやバージョンが混在するアップグレードの後に​​は、インストール全体を置き換える方が安全な場合もありますが、ダウンタイムが長くなり、構成データやユーザーデータの慎重な保存が必要になります。確認済みのコアファイルを1つだけ置き換える方が速いですが、これはそのファイルがインストールされているリリースに属していることを確認できる場合に限ります。署名検証を無効にすると特定のアプリが使用可能になる場合もありますが、保護機能が低下するため、日常的な修正ではなく、例外的な対応として文書化しておくべきです。

まず、何が失敗したのかを突き止める

管理者としてサインインし、管理ページを開きます。整合性警告に従って、無効なファイルの一覧を確認してください。現在のownCloudドキュメントでは、レポートはコアファイルやアプリなどのコンポーネントごとに問題をグループ化し、、、、などのラベルを使用しますINVALID_HASH。これらのラベルは異なる原因を示しているため、変更を加える前にコンポーネント、パス、およびエラーを記録してください。FILE_MISSINGEXTRA_FILEEXCEPTION

• INVALID_HASHこれは、ファイルの現在の内容が署名データのハッシュ値と一致しないことを意味します。一般的な原因としては、部分的なアップグレード、古いファイルが残っている、またはローカルでの編集などが挙げられます。
• FILE_MISSING署名付きファイルが存在しないことを意味します。アーカイブの抽出または展開が不完全な場合に発生する可能性があります。
• EXTRA_FILEこれは、インストールに署名に記載されていないファイルが含まれていることを意味します。これは、誤って残されたファイル、カスタムファイル、またはレビューが必要な正当なローカル追加ファイルである可能性があります。
• EXCEPTIONownCloudが署名を検証できなかったことを意味します。レポートには、署名データが欠落している、証明書が無効または失効している、あるいは検証が完了しなかった、といった内容が表示される場合があります。

余分なファイルだからといって、安易に削除しないでください。そのファイルの機能と追加したユーザーを確認してください。特に、signature.json警告を消すためにアプリのコードを編集することは絶対にしないでください。ownCloudのコード署名に関するガイドラインには、コードを編集しないようにと明記されています。

証拠に基づいて修理方法を選択してください。

ownCloud 11では、バージョン固有の考慮事項が追加されました。サードパーティ製アプリは、インストール、更新、または有効化するには有効な署名が必要であり、無効なアプリは単に警告されるだけでなくブロックされる可能性があります。2026年10月6日現在、ownCloud 11.0のドキュメントによると、以前の署名方式を使用するアプリは、2026年12月31日まで警告付きで受け入れられますが、それ以降は新しいPKIに基づく署名のみが信頼されます。ownCloud 10.xを使用している場合は、11.0の適用ルールが適用されると考えるのではなく、ご使用のリリースのドキュメントを参照してください。

インストールを変更する前に準備してください

1. 実行中のサーバーバージョンと、アップグレードプロセスで表示されるターゲットバージョンを確認してください。対応するリリースノートとシステム要件（サポートされているPHPバージョンを含む）を確認してください。
2. データベース、設定ファイル、およびデータディレクトリの最新のバックアップを作成してください。デプロイ方法が対応している場合は、現在のコードツリーまたはファイルシステムのスナップショットを保持してください。
3. 修復作業中にコードを交換する前に、サーバーをメンテナンスモードにしてください。ご使用の環境に対応した手順書に記載されている方法に従い、操作中はユーザーがファイルを書き込まないようにしてください。
4. ownCloudのインストール方法（アーカイブ/手動、オペレーティングシステムパッケージ、またはDocker）を特定してください。インストール方法に応じたアップグレード手順に従ってください。tarballから取得したファイルをパッケージ管理されたインストール環境に混入させないでください。
5. 元のレポートは保管し、移動または置換したファイルはすべて記録しておいてください。これにより、ロールバックや後々の診断がはるかに容易になります。

これらの予防措置が重要なのは、整合性警告は実行可能なアプリケーションコードに関するものであり、データベースとユーザーファイルはインストールの別個の部分であるためです。古いコードディレクトリを新しいパッケージ管理ファイルに上書きすると、それ自体が不一致を引き起こす可能性があります。ownCloudのアップグレードガイドでは、アップグレード前に最新のバックアップを作成し、リリースノートと要件を確認し、サードパーティ製アプリとの互換性を確認することを推奨しています。

部分的なアップグレード後にコアファイルを修復する

レポートに、コアツリー内のindex.php、version.php、またはファイルなどの公式コアパスが指定されている場合は、現在実行しようとしている正確なバージョンの公式アーカイブを入手してください。新しいアーカイブが利用可能だからといって、それより新しいアーカイブを使用しないでください。整合性ハッシュは特定のリリースに対応しています。

軽微で原因が特定できる不一致の場合は、報告されたパスをアーカイブ内の同じパスと比較してください。変更されていない公式ファイルであることを確認したら、Webサーバーが必要とする所有権と権限を保持したまま、影響を受けるファイルのみを置き換えてください。複数のファイルが欠落または不一致している場合、あるいはライブファイルを提供したバージョンを特定できない場合は、通常、新しいリリースディレクトリからのクリーンアップグレードの方が確実な方法です。

手動アーカイブインストールの場合、安全な手順は、リリースを個別にステージングし、configとを保持しdataてから、公式のアップグレード手順に従ってコードを所定の場所に移動することです。アーカイブの内容でユーザーデータディレクトリを上書きしないでください。パッケージおよびコンテナのデプロイメントには独自の更新手順があります。手動アーカイブ方式を適用するのではなく、それらの手順を使用してください。FTP を使用して個々のファイルを転送する場合は、ownCloud の整合性に関するドキュメントでバイナリ転送モードが指定されています。

アプリの警告は個別に処理する

レポートでコアではなくアプリ名が挙げられている場合は、まずそのアプリがownCloudのバージョンに対応しているかどうかを確認してください。サーバーと互換性があり、有効な署名を持つ公式リリースまたはメンテナー提供のリリースをインストールしてください。互換性のあるリリースが存在しない場合は、アプリを無効にして、必要なワークフローが中断されないことを確認してください。アプリの削除はより恒久的な操作となるため、アプリの削除手順に従ってください。

ownCloud 11では、特定のアプリの検証を無効にすることは、管理者が制御する例外であり、ログに記録され、そのアプリの整合性と失効保護が失われます。アプリの発生源と影響を評価した上で、例外を承認した人物とその理由を文書化してから使用してください。これは、破損または改ざんされたコアインストールを修復する方法ではありません。以前のリリースでは、利用可能な強制動作が異なるため、インストールされているバージョンのドキュメントを確認してください。

再度チェックを実行し、結果を確認してください。

基となるファイルを修正した後、管理ページの再スキャン機能が利用可能であれば、それを使用してください。また、ドキュメントに記載されているoccチェックを実行することもできます。Docker Compose の場合、ownCloud の最新のコード署名ガイドには、以下の例が示されています。

docker compose exec owncloud occ integrity:check-core
docker compose exec owncloud occ integrity:check-app calendar

calendarレポートに記載されているアプリ ID に置き換えてください。コンテナ以外のインストールの場合、 occweb server ユーザーとして ownCloud ディレクトリからファイルを実行してください。正確なパスとユーザーは、オペレーティングシステムとインストール方法によって異なります。ドキュメントに記載されているコマンドは、コアまたは指定されたアプリをチェックします。現在のガイドでは、すべてのアプリを手動で再スキャンするための単一のコマンドは記載されていません。

修復が完了したかどうかは、新しいレポートに修正されたファイルが表示されなくなり、関連する機能が正常に動作するかどうかで確認できます。同じハッシュエラーが再び発生する場合は、自動デプロイ、ローカルパッチ、同期ジョブ、またはセキュリティインシデントによってファイルが再度変更されていないか確認してください。レポートが失効した証明書、アプリ署名の欠落、または公式リリースから解決できないバージョンの不一致を示している場合は、スキャンを繰り返すのを中止し、レポートと正確なサーバーバージョンを添えてアプリのメンテナーまたはownCloudサポートにお問い合わせください。

どちらのアプローチを採用すべきでしょうか？

レポートで公式コアファイルが 1 つ特定され、正確なリリースがわかっており、対応するオリジナルを入手できる場合は、対象を絞ったファイル置換を選択してください。多数のコアファイルが失敗した場合、アップグレードが中断された場合、またはインストールに複数のリリースのファイルが含まれている場合は、クリーンアップグレードを繰り返してください。アプリのみのエラーの場合は、メンテナーによる更新または未使用アプリの無効化を優先してください。これにより、無関係なコアファイルを置き換えることなく、影響を受けるコンポーネントに対処できます。署名済みの代替品がなく、運用上の必要性が整合性保護の損失を上回る場合に限り、特定の評価済みアプリに対して検証例外を設定してください。

次回のアップグレードに先立ち、まずリリースノートと要件を確認し、ownCloudの推奨に従って互換性のないサードパーティ製アプリを無効にし、最新のバックアップを作成してください。これらの手順には計画に時間がかかりますが、アップグレード後のデータ整合性に関する警告の診断が容易になり、復旧もより安全になります。

公式資料

• ownCloud 11.0: コード署名と無効なコード整合性メッセージの修正
• ownCloud 10.15: コード署名エラー
• ownCloud 10.16: ownCloud Classicをアップグレードする方法
• ownCloud 10.15: ownCloudのバックアップ
• ownCloud 10.15: ownCloudの復元