Clear an ownCloud Integrity Warning After an Upgrade

If ownCloud shows “Integrity check failed” after an upgrade, first open the admin warning and inspect the invalid-file report; do not edit signature.json, disable the check, or rerun the upgrade blindly. The report identifies whether the problem is a core file mismatch, a missing or extra file, or an app signature issue. Restore only the affected code from the exact official release or install a compatible signed app, then rescan. This approach applies to ownCloud Server (Classic); Infinite Scale uses a different architecture and does not use this PHP occ integrity workflow.

For example, if an upgrade from one 10.x point release to another leaves index.php and version.php flagged as INVALID_HASH, the likely issue is that some core files still belong to a different release or were altered. If only a manually installed app is flagged for missing signature data, replacing core files will not solve it. The error details determine which fix is appropriate.

Read the report before changing files

Sign in as an administrator and open the yellow code integrity warning, then choose the link to list invalid files. The ownCloud 10.16 documentation describes this report and the admin-page rescan option. If the web page is unavailable, run checks from the ownCloud installation directory as the web server user:

sudo -u www-data ./occ integrity:check-core
sudo -u www-data ./occ integrity:check-app <appid>

Replace www-data with the account used by your web server, and replace <appid> with the app ID shown in the report. On Docker, execute the same occ command inside the ownCloud container using the deployment’s normal method. The commands inspect core files and a named app; the ownCloud manual notes that there is not a single manual command to scan every app.

Use the error type to choose the next action:

• INVALID_HASH: a file differs from the hash in its signature. It may be a partial or mixed-version upgrade, a local edit, or an unexpected modification. Compare the file with the exact official release before replacing it.
• FILE_MISSING: a signed file is absent. Restore it from the matching release package; first check that deployment, packaging, or permissions did not omit it.
• EXTRA_FILE: a file exists in a signed directory but is not part of that signature. It may be a leftover from an older version or a locally added file. Identify its owner and purpose before removal.
• EXCEPTION: signature data may be absent, invalid, out of scope, or tied to a revoked certificate. For an app, check its source and release status and ask its maintainer for a compatible signed build.

A manually installed third-party app can legitimately trigger a warning if it is unsigned; ownCloud documents that unsigned apps installed outside the Marketplace may remain flagged. That does not explain an invalid core hash. Keep the app and core results separate while diagnosing.

Repair a core mismatch from the matching release

1. Make a recoverable backup. Before replacing server files, preserve the database, configuration, and data according to the backup procedure for your deployment. If the upgrade is incomplete or the service is unstable, enable maintenance mode and stop web traffic before repair. Do not treat a file copy as a substitute for a database backup.
2. Confirm the version ownCloud is actually running. Check the admin overview and the version information on disk. Make sure the upgrade process completed and all cluster nodes or containers run the same target release. Review upgrade logs for interrupted extraction, permission errors, or a command that stopped early.
3. Obtain the official archive for that exact version. Do not use a “latest” archive if the instance is on an earlier point release. Extract it to a separate temporary directory and compare only the flagged paths. If a file is customized by your distribution or deployment tooling, understand that customization before replacing it.
4. Replace affected core files carefully. For confirmed core files, copy the official versions from the matching archive while preserving the instance’s configuration, data, and compatible app directories. Avoid overlaying a new server archive across an old tree without following the upgrade instructions: leftover files from prior releases can themselves cause EXTRA_FILE results. Restore normal ownership and permissions using the documented method for your installation.
5. Run the relevant check again. Use integrity:check-core for core findings or integrity:check-app <appid> for one app. You can also use the admin page’s rescan action. Do not hand-edit or delete signature.json; it is the signature data the verifier needs.

ownCloud’s code-signing guidance gives examples such as restoring the correct index.php and version.php from the release archive, removing an identified unneeded extra file, and restoring a missing .htaccess from the official server tarball. Those are examples, not a universal replacement list: act on the exact paths in your own report.

Handle an app warning without masking it

For an app flagged after the server upgrade, first confirm that the app supports the target ownCloud release. Disable an incompatible app through the supported admin or command-line procedure, then install an official compatible release from the Marketplace or the app maintainer. If a previously signed app is now unsigned or its certificate is reported revoked, contact the maintainer for a properly signed replacement. Do not copy signature data from a different app or version; signatures are tied to the app content and certificate scope.

If the flagged app is a custom app your organization maintains, the app’s authorized maintainer must build and sign the release using the appropriate process and trusted signing credentials. Administrators should not create a replacement signature to make unknown or modified code pass. If you cannot establish the source and integrity of a file, preserve the report and investigate it as a potential security issue instead of suppressing the warning.

Verify the repair

Run the relevant integrity check again and refresh the admin overview. Confirm that the same paths no longer appear, the warning is gone for the repaired component, and ownCloud logs show no new upgrade or permission errors. Test login, file listing, upload, and the affected app. In a multi-node deployment, check every node; a clean result on one server does not prove that all nodes use matching code.

If the report persists, stop replacing files and compare the running tree with the exact package, deployment image, or mounted volume for that version. Check for a second copy of the code, stale bind mounts, a deployment script that restores old files, or local patches. Consult the version-matched ownCloud 10.16 code-signing and integrity guidance, ownCloud upgrade instructions, and restore documentation. The page is for ownCloud Server 10.16; earlier versions may differ, so choose documentation that matches the installed release.