Fix Nextcloud ‘Some Files Have Not Passed Integrity Check’ Warning

After an update or a manual change, you may open Nextcloud’s admin Overview and see “Some files have not passed the integrity check.” The warning can be alarming, but it does not identify one universal fault. Nextcloud checks whether installed server and app code matches its expected signed files. A changed or missing file, an unexpected file, or an app signature problem can trigger the alert. A rescan reports the current state; it does not repair the files.

The official Nextcloud download page lists Server 35.0.0, released September 16, 2026, as the latest release at the time of writing. The current administration documentation still directs admins to inspect the invalid-file report, repair the specific cause, and scan again. The steps below follow that durable process; exact menu wording may vary by release or hosting package.

1. Read the invalid-file report before changing anything

Sign in as an administrator and open Administration settings > Overview. In the integrity warning, choose List of invalid files… (the label may be slightly different). Save or copy the report somewhere private so you can compare it after a repair. It identifies the app or core area and lists conditions such as INVALID_HASH, MISSING_FILE, EXTRA_FILE, and EXCEPTION.

Back up the Nextcloud configuration, database, and any custom app code before replacing server files. Do not edit signature.json, generate a replacement signature to silence the warning, or remove files just because their names appear in the report. The check protects code authenticity and can also reveal an unexpected file that deserves investigation.

2. Match the error type to the right repair

These labels are diagnostic clues, not proof of an attack or proof that the installation is safe. A developer’s local edit, a copied backup file, an incomplete deployment, and unauthorized code can produce different-looking findings. If you cannot explain an unexpected PHP file or a changed core file, preserve the report and investigate before deleting or overwriting it.

3. Restore core files from the exact Nextcloud release

If the report names files under core, such as index.php or version.php, first check whether an upgrade stopped partway through or a deployment process altered the code. Confirm the installed version in the admin Overview or with your normal deployment records. Do not copy a file from a different Nextcloud version: its hash will not match the release installed on the server.

Use the supported updater to complete an interrupted upgrade when possible. If you must restore files manually, download the matching server archive from Nextcloud’s official download page, verify the archive using the published checksum or PGP signature, and replace only the affected application-code files according to Nextcloud’s upgrade instructions. Preserve config/, the data directory, and any locally maintained apps or themes. Follow the backup and maintenance-mode procedure for your installation method; Docker, Snap, appliances, and managed hosting may require their own update process.

Nextcloud’s integrity guide gives the same principle for an invalid core hash: restore the correct files, then rescan. If transferring files through FTP, the guide specifically cautions to use binary transfer mode. Avoid running an update with signature verification disabled as a shortcut. A manually installed archive that has not been verified can introduce a new integrity and security problem.

4. Review extra files and custom changes carefully

An EXTRA_FILE entry can be a leftover temporary file, an editor backup, a custom script, or something you do not recognize. Check its full path, timestamp, owner, and deployment history. If it is a legitimate custom tool, move it outside the served Nextcloud code directory and expose it through a supported app or separate service where appropriate. If it is an obsolete backup, remove it only after preserving anything you need. If an unexplained executable or PHP file appeared recently, treat that as a security investigation: preserve evidence, review access and web-server logs, and follow your incident-response process rather than simply deleting the warning.

For an INVALID_HASH in a core file that you intentionally edited, the sustainable fix is to restore the signed core file and move custom behavior into a supported app, theme, or documented extension point. Do not change the expected hash or alter release metadata to make the check pass. Custom Nextcloud distributions have separate release-branch considerations in the code-signing documentation; changing that setting is for maintainers of a custom distribution, not a routine repair for a standard installation.

5. Repair an app signature or app file

If the report names an app directory, identify its app ID and determine whether the app was updated, copied manually, or modified locally. Use Nextcloud’s Apps interface or your deployment method to update or reinstall a compatible release from a trusted source. Back up app-specific data and configuration first, and check compatibility with your Nextcloud major version. For a custom or internally developed app, ask its maintainer for a signed package or a corrected release. Nextcloud requires code signing for apps published through its app store; signing requirements and enforcement can differ for other app categories, so use the relevant developer documentation rather than inventing a local signature.

Do not overwrite an app directory with a random archive or copy its signature.json from another version. The signature describes particular code; mixing files from separate releases can create additional errors. If you need to remove an app, use the supported app management process and confirm that removal will not discard data your organization needs.

6. Run a fresh integrity check

Once you have repaired the reported files, return to Administration settings > Overview and select Rescan…. Wait for the scan to finish, then reopen the invalid-file list. If you administer the server over SSH, Nextcloud 35 documents these commands from the Nextcloud installation directory:

sudo -E -u www-data php occ integrity:check-core
sudo -E -u www-data php occ integrity:check-app calendar
sudo -E -u www-data php occ integrity:check-app --all

Replace calendar with the app ID shown in your report. The www-data account is common on Debian- or Ubuntu-based installations, but your web-server user and PHP executable may differ. Use the correct account and PHP environment for your system; for container installations, run the equivalent command inside the appropriate container. The current OCC manual says a successful app check may produce no output unless verbose mode is requested, while failures list details.

How to tell whether the warning is fixed

Reopen the admin Overview and confirm the integrity warning has disappeared after the new scan. If it remains, compare the new report with your saved copy: the same path means the underlying file was not restored or the wrong version was used; a different path may reveal a second issue. Run the relevant core or app check again and review the Nextcloud log for a signature error. Also confirm that the instance completes normal sign-in, file browsing, uploads, and downloads.

If the warning returns after a deployment, look for automation, plugins, or manual maintenance scripts that rewrite files inside the signed code tree. If the integrity report is clean but users still see errors, the original problem may have a separate cause and should be troubleshot on its own. For hosted Nextcloud, send the provider the exact report and installed version; avoid including passwords, private keys, or user file contents.

For version-specific details, see the Nextcloud code-signing and integrity documentation, the OCC integrity-check reference, the Nextcloud updater manual, and the official download page.