You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since upgrading Nextcloud to 33.0.0 (from 32.0.5), once per day the cron.php process maxes out the CPU (granted, it's a slow 1 CPU core DigitalOcean server) for about an hour before returning to normal. I can't find anything in the logs that would suggest what cron is actually doing or why it's taking up so much resources.
Details
⚠️ This issue respects the following points: ⚠️
This is a bug, not a question or a configuration/webserver/proxy issue.
Since upgrading Nextcloud to 33.0.0 (from 32.0.5), once per day the cron.php process maxes out the CPU (granted, it's a slow 1 CPU core DigitalOcean server) for about an hour before returning to normal. I can't find anything in the logs that would suggest what cron is actually doing or why it's taking up so much resources.
Steps to reproduce
Run cron.php on a Nextcloud 33 installation on a 1-core VM?
Expected behavior
cron.php shouldn't cause so much CPU usage
Nextcloud Server version
33
Operating system
Other
PHP engine version
PHP 8.3
Web server
Apache (supported)
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 31 to 32)
Are you using the Nextcloud Server Encryption module?
Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.
Results
=======
- core
- INVALID_HASH
- .htaccess
Raw output
==========
Array
(
[core] => Array
(
[INVALID_HASH] => Array
(
[.htaccess] => Array
(
[expected] => 418f0babf39f82e537d12028229189633a7941160c27c3410032af498008a65637b8d1ee64abc63a6321c3d1ef8cde31fe58cee00d8b32821480501111977c34
[current] => 11fa1c20bce060406cf3f1dadc2f352fc3366fc1e8f4869c63f14312b14f35637e7823072295f810355527cce160b90463de9108ee9167d439b72a140a858b18
)
)
)
)
Have a Nextcloud instance with a large number of preview entries in oc_filecache (~462k in our case)
Upgrade to Nextcloud 33.0.0
The preview files on disk may have been cleaned up previously (e.g. via preview:cleanup or manual cleanup), but the corresponding oc_filecache entries remain
Wait for the PreviewMigrationJob background job to trigger
Expected behavior
The PreviewMigrationJob should handle the case where oc_filecache entries exist but the actual preview files are missing on disk. It should either clean up the orphaned entries or skip them and move on.
Actual behavior
The job enters an infinite while(true) loop consuming ~55% CPU for exactly 1 hour (the hardcoded timeout), then restarts on the next cron cycle. Zero previews are ever migrated to the new oc_previews table.
Root cause in core/BackgroundJobs/PreviewMigrationJob.php:
The while(true) loop SELECTs 100 paths from oc_filecache
For each batch, migrateFileId() is called in PreviewMigrationService.php
Since the files don't exist on disk, this throws NotFoundException
The catch block returns []without deleting the orphaned oc_filecache entry
The next iteration SELECTs the same 100 rows → infinite loop
The previewMovedDone flag is never set because the loop never breaks (there are always rows to SELECT).
Proposed fix
In PreviewMigrationService::migrateFileId(), when NotFoundException is caught, the orphaned oc_filecache entries for that preview folder should be cleaned up before returning:
} catch (NotFoundException) {
// Clean up orphaned filecache entries for this preview folder$this->deleteFolder($internalPath);
return [];
}
This way the while(true) loop in the job will eventually exhaust all entries and set the previewMovedDone flag.
Workaround
-- Remove orphaned preview entries from filecacheDELETEFROM oc_filecache WHEREpathLIKE'appdata_<instanceid>/preview/%';
Then either wait for the job to set the flag itself (it will find 0 rows and complete), or set it manually:
Note
How to help with this issue
Original report by @z3ntu
Details
Bug description
Since upgrading Nextcloud to 33.0.0 (from 32.0.5), once per day the cron.php process maxes out the CPU (granted, it's a slow 1 CPU core DigitalOcean server) for about an hour before returning to normal. I can't find anything in the logs that would suggest what cron is actually doing or why it's taking up so much resources.
Steps to reproduce
Expected behavior
cron.php shouldn't cause so much CPU usage
Nextcloud Server version
33
Operating system
Other
PHP engine version
PHP 8.3
Web server
Apache (supported)
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 31 to 32)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
{ "system": { "instanceid": "***REMOVED SENSITIVE VALUE***", "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "cloud.lucaweiss.eu" ], "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "pgsql", "version": "33.0.0.16", "logtimezone": "UTC", "installed": true, "theme": "", "loglevel": 2, "logfile": "\/var\/log\/nextcloud\/nextcloud.log", "default_phone_region": "AT", "maintenance": false, "htaccess.RewriteBase": "\/", "overwrite.cli.url": "https:\/\/cloud.lucaweiss.eu", "mail_smtpmode": "smtp", "mail_smtpauthtype": "PLAIN", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_smtpauth": 1, "mail_smtpname": "***REMOVED SENSITIVE VALUE***", "mail_smtppassword": "***REMOVED SENSITIVE VALUE***", "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": "587", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "apps_paths": [ { "path": "\/usr\/share\/webapps\/nextcloud\/apps", "url": "\/apps", "writable": false }, { "path": "\/var\/lib\/nextcloud\/apps", "url": "\/wapps", "writable": true } ], "app_install_overwrite": [ "bruteforcesettings", "news" ], "mail_sendmailmode": "smtp", "updater.release.channel": "stable" } }List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
No response
More details by @UltimateByte
Details
Server configuration
Operating system: Debian 13 (trixie)
Web server: Apache 2.4.66
PHP version: 8.4.19
Nextcloud version: 33.0.0.16
Updated from: 32.x (major upgrade)
Database: MariaDB
Signing status:
System configuration
{ "system": { "trusted_domains": [ "localhost", "cloud.lrob.fr" ], "dbtype": "mysql", "version": "33.0.0.16", "mysql.utf8mb4": true, "memcache.local": "\\OC\\Memcache\\Redis", "memcache.distributed": "\\OC\\Memcache\\Redis", "filelocking.enabled": true, "memcache.locking": "\\OC\\Memcache\\Redis" } }