修復版本升級後 ownCloud “完整性檢查失敗” 的問題

如果升級後 ownCloud 顯示“完整性檢查失敗”，請在修改文件之前使用無效文件報告來確定失敗的原因。重新掃描只會重複驗證，不會恢復遺失的檔案、撤銷自訂編輯或安裝已修復的應用程式版本。對於核心文件，請與您升級到的 ownCloud 版本進行比較。如果遇到應用程式簽章問題，請尋找相容且簽署正確的應用程式更新，或聯絡其維護者。

正確的修復方法取決於警告的範圍。在部分升級或混合版本升級後，替換整個系統可能更安全，但這需要更長的停機時間，並且需要仔細保護配置和使用者資料。替換單一已確認的核心檔案速度更快，但前提是您可以確認該檔案屬於已安裝的版本。停用簽名驗證可能使特定應用程式可用，但這會降低安全性，應該作為例外情況記錄在案，而不是常規修復。

首先，找出失敗的原因。

以管理員身分登入並開啟管理頁面。依照完整性警告進入無效文件清單。在目前的 ownCloud 文件中，該報告按元件（例如核心文件或應用程式）對問題進行分組，並使用包括 ` INVALID_HASH<component> FILE_MISSING`、 `<path>`、`<error> EXTRA_FILE` 和`<error>` 在內的標籤EXCEPTION。這些標籤指向不同的原因，因此在進行任何變更之前，請記錄元件、路徑和錯誤訊息。

• INVALID_HASH這表示檔案的當前內容與其簽署資料中的雜湊值不符。常見原因包括文件部分升級、殘留舊文件或本地編輯。
• FILE_MISSING表示缺少簽名檔。不完整的歸檔提取或部署可能會導致這種情況。
• EXTRA_FILE這意味著安裝包中包含簽名中未列出的檔案。這可能是意外遺留的文件、自訂文件，或是需要審核的合法本地添加文件。
• EXCEPTION這意味著 ownCloud 無法驗證簽章。報告可能顯示簽名資料缺失、憑證無效或已被撤銷，或驗證無法完成。

不要僅僅因為某個文件顯示為多餘文件就將其刪除。請確認該文件的用途以及新增者。尤其需要注意的是，切勿signature.json為了消除警告而編輯應用程式的設定檔；ownCloud 的程式碼簽署指南明確指出，禁止修改此類檔案。

根據證據選擇維修方案

ownCloud 11 新增了一個版本特定的注意事項：第三方應用程式必須擁有有效的簽章才能安裝、更新或啟用，無效的應用程式將直接被阻止，而不僅僅是被標記。 ownCloud 11.0 的文檔指出，截至 2026 年 10 月 6 日，使用舊簽章方案的應用程式將被接受，但會收到警告，有效期至 2026 年 12 月 31 日；此日期之後，只有使用新 PKI 簽署的應用程式才會被信任。如果您運行的是 ownCloud 10.x 版本，請查閱您具體版本的文檔，不要想當然地認為 11.0 的強制規則同樣適用。

更改安裝前請做好準備

1. 確認目前伺服器版本和升級過程中顯示的目標版本。檢查符合的版本說明和系統需求，包括支援的 PHP 版本。
2. 對資料庫、配置和資料目錄進行全新備份。如果您的部署方法支持，請保留目前程式碼樹或檔案系統快照。
3. 在維修過程中替換代碼之前，請將伺服器置於維護模式。請使用適用於您安裝環境的文件中記錄的方法，並確保使用者在操作期間沒有寫入檔案。
4. 確定 ownCloud 的安裝方式：歸檔/手動安裝、作業系統軟體包安裝或 Docker 安裝。請依照該安裝方式的升級步驟進行操作。不要將 tar 包中的檔案混入到軟體包管理的安裝中。
5. 請保留原始報告，並記錄您移動或替換的每個文件。這能大大簡化回滾操作和後續診斷。

這些預防措施至關重要，因為完整性警告涉及可執行應用程式程式碼，而資料庫和使用者檔案是安裝過程中的獨立部分。將舊程式碼目錄還原到較新的軟體包管理檔案上本身就可能導致不符。 ownCloud 的升級指南建議在升級前進行全新備份、查看發行說明和要求，並檢查第三方應用程式的相容性。

部分升級後修復核心文件

如果報告中提及了官方核心路徑（例如`<core_path>` index.php、version.php`<core_dir>` 或核心樹下的檔案），請取得目前目標運行版本的官方歸檔檔案。不要因為有更新的歸檔檔案可用就使用它：完整性雜湊值對應於特定的版本。

對於較小的、容易理解的不匹配，請將報告的路徑與該歸檔文件中的相同路徑進行比較。確認它是未修改的官方文件後，僅替換受影響的文件，同時保留 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。對於非容器安裝，請occ以 Web 伺服器使用者身分從 ownCloud 目錄呼叫該檔案；具體路徑和使用者因作業系統和安裝方法而異。文件中記錄的命令會檢查核心或指定的應用程式；目前的指南指出，沒有用於手動重新掃描每個應用程式的命令。

當新的報告不再列出已更正的檔案且相關功能正常運作時，即表示修復已成功。如果再次出現相同的雜湊錯誤，請檢查是否有自動部署、本機修補程式、同步作業或安全事件導致檔案再次被變更。如果報告指出存在憑證撤銷、應用程式簽章或版本不符等問題（您無法從官方版本中解決），請停止重複掃描，並將報告和確切的伺服器版本號提供給應用程式維護者或 ownCloud 支援團隊。

你該採用哪一種方法？

如果報告僅識別出一個官方核心文件，且已知確切版本，並能找到匹配的原始文件，則選擇目標文件替換。如果多個核心文件發生故障、升級中斷或安裝包含來自多個版本的文件，則重複執行乾淨升級。對於僅涉及應用程式的錯誤，請優先考慮由維護者進行更新或停用未使用的應用程式；這樣可以解決受影響的元件，而不會取代無關的核心檔案。當沒有已簽署的替換檔案且執行需求大於完整性保護損失時，才對特定的、經過評估的應用程式保留驗證例外。

下次升級前，請先查看版本說明和系統需求，按照 ownCloud 的建議停用不相容的第三方應用，並進行全新備份。這些步驟需要一些規劃時間，但有助於更輕鬆地診斷升級後的完整性警告，並使恢復過程更加安全。

官方參考資料

• ownCloud 11.0：程式碼簽署和修復無效的程式碼完整性訊息
• ownCloud 10.15：程式碼簽章錯誤
• ownCloud 10.16：如何升級您的 ownCloud Classic
• ownCloud 10.15：備份 ownCloud
• ownCloud 10.15：恢復 ownCloud