Persistent hash_hkdf() Fatal Error from Federation/OCM, Even With App Disabled on NC 31

[Everton_Diego_Silva]

Hello everyone,

I’m facing a very persistent and unusual fatal error and I’ve exhausted all possible troubleshooting steps, including a full re-installation. I’m hoping someone in the community has seen this before.

Environment:

• Nextcloud Version: 31.0.8.1 (Reported by logs)
• PHP Version: 8.3.24
• Database: MariaDB 10.6
• Installation Method: Official Docker Image (nextcloud:latest-apache)
• Setup: Running behind Nginx Proxy Manager

The Problem: My log is being spammed with a fatal error every few seconds: Exception: hash_hkdf(): Argument #2 ($key) cannot be empty in file '/var/www/html/lib/private/Security/Crypto.php' line 147.

Key Symptoms & Diagnosis:

• The log trace clearly shows the error is triggered by the Federation / Open Cloud Mesh (OCM) feature when the /ocm-provider/ endpoint is hit by the Nextcloud Server Crawler.
• The error also happens manually when I open the “Files” app.
• Server-Side Encryption is, and always has been, disabled.
• Crucially, the error continues to happen even after I disable the federation and cloud_federation_api apps via the occ command. The system seems to be ignoring the fact that the app is disabled and continues to run its code.

What I Have Already Tried (Unsuccessfully):

1. Verified that secret and passwordsalt are correctly set in config.php.
2. Corrected all file permissions with chown -R www-data:www-data.
3. Ran occ integrity:check-core (passed with no errors).
4. Ran occ files:scan --all.
5. Manually deleted all federation-related entries from oc_appconfig and oc_preferences in the database.
6. Flushed the Redis cache with FLUSHALL.
7. Restarted the containers multiple times.
8. Performed a full re-installation: I backed up my data folder, config.php, custom_apps, and the database. I then completely destroyed the Docker environment (containers and volumes). I set up a fresh, clean installation and restored my backups. The error returned immediately after restoring the database.

This confirms the corruption is within my database backup. However, the system’s behavior of running code from a disabled app seems like a deeper issue.

Has anyone encountered a situation where a disabled app’s controllers and routes continue to run, leading to a fatal error? Is there any known bug in the 31.0.8.1 release related to this?

Thank you for any insights you can provide.

[jtr]

@Everton_Diego_Silva

This confirms the corruption is within my database backup. However, the system’s behavior of running code from a disabled app seems like a deeper issue.

It’s not typically possible to disable the cloud_federation_api app via occ app:disable as it is a shipped+alwaysEnabled app. It looks like you overrode Nextcloud’s internal app management code by modifying the database directly.

[Everton_Diego_Silva]

Hi @jtr, thank you for your insight. You are absolutely correct that we modified the database directly to remove the federation app configs.

However, I need to clarify that this was a late-stage troubleshooting step. The fatal hash_hkdf error was already happening constantly before we attempted any direct database modifications.

The sequence of events was:

1. We observed the persistent hash_hkdf error.
2. We tried disabling the main federation app via occ. This was successful, but the error continued.
3. Only after those attempts failed did we manually delete the entries from oc_appconfig as a last resort. The error still persisted even after this.

So, the fundamental issue remains: the Federation API triggers a fatal error, and it seems impossible to stop this code from running. I have also documented this entire process in a GitHub issue here: https://github.com/nextcloud/server/issues/54597

Thanks again for your help.