If ownCloud shows “Integrity check failed” after an upgrade, use the invalid-file report to identify what failed before changing files. A rescan only repeats verification; it does not restore missing files, undo custom edits, or install a corrected app release. For core files, compare against the exact ownCloud release you upgraded to. For an app signature problem, look for a compatible, correctly signed app update or contact its maintainer.
The right repair depends on the scope of the warning. Replacing an entire installation can be safer after a partial or mixed-version upgrade, but it takes more downtime and careful preservation of configuration and user data. Replacing one confirmed core file is faster, but only when you can verify the file belongs to the installed release. Disabling signature validation may make a specific app usable, but it reduces protection and should be a documented exception, not a routine fix.
Sign in as an administrator and open the Admin page. Follow the integrity warning to the invalid-file list. In current ownCloud documentation, the report groups issues by component, such as core files or an app, and uses labels including INVALID_HASH, FILE_MISSING, EXTRA_FILE, and EXCEPTION. These labels point to different causes, so record the component, path, and error before making changes.
INVALID_HASH means a file’s current contents do not match the hash in its signature data. Common explanations include a partial upgrade, an old file left in place, or a local edit.FILE_MISSING means a signed file is absent. An incomplete archive extraction or deployment can cause this.EXTRA_FILE means the installation contains a file not listed in the signature. It may be an accidental leftover, a custom file, or a legitimate local addition that needs review.EXCEPTION means ownCloud could not verify the signature. The report may say signature data is missing, the certificate is invalid or revoked, or verification could not complete.Do not delete a file just because it appears as extra. Confirm what it does and who added it. In particular, never edit an app’s signature.json to silence the warning; ownCloud’s code-signing guidance explicitly says not to modify it.
| Finding | Preferred next step | Trade-off |
|---|---|---|
| Several core files have invalid hashes or are missing after a manual upgrade | Stage a fresh copy of the exact target release and restore the affected official files, or repeat the manual upgrade cleanly | A clean upgrade is more work and may require downtime, but reduces the risk of leaving a mixed-version code tree |
| One core file is invalid and you know it was locally edited | Compare the edit with the matching release file; preserve the custom change outside the signed core tree and reapply it only if supported | Keeping the change may preserve local behavior, while editing signed core files will continue to fail integrity checks |
| An app reports missing or invalid signature data | Install a compatible release from the app’s maintainer or disable/remove the app if it is no longer needed | An update preserves functionality; disabling avoids the app’s code but can remove features users depend on |
| An app certificate is revoked or invalid | Ask the app maintainer for a newly signed compatible release; do not reuse or alter signature files | This may take time, but keeps signature validation intact |
| An extra file is identified | Check its owner, purpose, and whether it is part of a customization before moving it out of the installation directory | Removing an unknown file can break a local integration or delete something important |
ownCloud 11 adds a version-specific consideration: third-party apps must have valid signatures to be installed, updated, or enabled, and an invalid app can be blocked rather than merely flagged. As of October 6, 2026, ownCloud’s 11.0 documentation says apps using the previous signing scheme are accepted with a warning through December 31, 2026; after that date only signatures under the new PKI are trusted. If you run ownCloud 10.x, consult documentation for your exact release instead of assuming the 11.0 enforcement rules apply.
These precautions matter because an integrity warning concerns executable application code, while the database and user files are separate parts of the installation. Restoring an old code directory over newer package-managed files can itself create mismatches. ownCloud’s upgrade guidance recommends a fresh backup, reviewing release notes and requirements, and checking third-party app compatibility before an upgrade.
If the report names official core paths such as index.php, version.php, or files under the core tree, obtain the official archive for the exact version currently intended to run. Do not use a newer archive merely because it is available: the integrity hashes correspond to a specific release.
For a small, well-understood mismatch, compare the reported path with the same path in that archive. After confirming it is an unmodified official file, replace only the affected file while preserving ownership and permissions required by your web server. If several files are missing or mismatched, or you cannot determine which version supplied the live files, a clean upgrade from a fresh release directory is usually the more reliable option.
For a manual archive installation, the safe pattern is to stage the release separately, preserve config and data, then follow the official upgrade steps for moving code into place. Do not overwrite the user data directory with archive contents. Package and container deployments have their own update procedures; use those rather than applying the manual archive method to them. If transferring individual files with FTP, ownCloud’s integrity documentation specifies binary transfer mode.
If the report names an app rather than core, first check whether that app supports your ownCloud version. Install an official or maintainer-provided release that matches the server and carries a valid signature. If no compatible release exists, disable the app and confirm that doing so will not interrupt a required workflow. Removing an app is a more permanent choice and should follow the app’s own removal guidance.
For ownCloud 11, disabling validation for a particular app is an administrator-controlled exception that is logged and forfeits integrity and revocation protection for that app. Use it only after assessing the source and impact of the app, and document who approved the exception and why. It is not a way to repair a corrupted or tampered core installation. For older releases, the available enforcement behavior differs, so check the documentation for your installed version.
After correcting the underlying files, use the Admin page’s rescan action if it is available. You can also run the documented occ checks. For Docker Compose, the current ownCloud code-signing guide gives these examples:
docker compose exec owncloud occ integrity:check-core
docker compose exec owncloud occ integrity:check-app calendarReplace calendar with the app ID named in your report. For non-container installations, invoke the occ file from your ownCloud directory as the web-server user; the precise path and user vary by operating system and installation method. The documented command checks core or a named app; the current guide says there is not a single command there for manually rescanning every app.
A repair is verified when a new report no longer lists the corrected files and the relevant feature works normally. If the same hash error returns, look for an automated deployment, local patch, synchronization job, or security incident that is changing the file again. If the report points to a revoked certificate, missing app signature, or a version mismatch you cannot resolve from an official release, stop repeating the scan and contact the app maintainer or ownCloud support with the report and exact server version.
Choose a targeted file replacement when the report identifies one official core file, the exact release is known, and you can source the matching original. Repeat the clean upgrade when many core files fail, the upgrade was interrupted, or the installation contains files from more than one release. For app-only errors, favor a maintainer update or disabling an unused app; this addresses the affected component without replacing unrelated core files. Reserve validation exceptions for a specific, assessed app when there is no signed replacement and the operational need outweighs the loss of integrity protection.
For the next upgrade, review the release notes and requirements first, disable incompatible third-party apps as recommended by ownCloud, and take a fresh backup. Those steps take planning time, but they make a post-upgrade integrity warning easier to diagnose and recovery safer.
Compare seven tools that support or complement WSUS, from Microsoft’s native console and diagnostics to third-party patch publishing and remote deployment.
Compare six Windows system monitoring tools for server health, application visibility, and alerting, with current notes on deployment and licensing.
Compare seven Wake-on-LAN tools by features and availability, including free utilities, network-admin suites, and 2021 picks that have since been retired.
Compare nine ping tools for quick reachability checks, subnet discovery, TCP tests, and latency monitoring, with guidance on which one fits your network task.
Compare the best TFTP servers for Windows, Linux, and macOS, including SolarWinds, Tftpd64, tftpd-hpa, atftpd, haneWIN, and dnsmasq.
Compare five Microsoft Access alternatives for desktop, SQLite, no-code, and browser-based database work, with strengths, limits, and best-fit use cases.
Compare open-source and closed-source monitoring tools by cost, support, customization, security, and current options including Zabbix, Nagios, PRTG, and more.
Understand how ingress and egress describe incoming and outgoing traffic, why direction depends on the network boundary, and how to monitor bandwidth and spot risky data transfers.
Compare six free syslog servers and collectors for Windows and Linux, including GUI tools, open-source options, search, alerting, and secure transport.
See what Microsoft IIS does, how its request pipeline and application pools work, and when Apache, NGINX, or Caddy may fit your web server needs better.
