Scheduled task failed: Tabellen, Logdaten und Dateien für Sicherungen bereinigen (core\task\backup_cleanup_task),error/error_opening_file Backtrace: * line ? of unknownfile: call to file_logger->__wakeup() * line 97 of /backup/util/dbops/restore_controller_dbops.class.php: call to unserialize() * line 499 of /backup/controller/restore_controller.class.php: call to restore_controller_dbops::load_controller() * line 244 of /backup/util/helper/copy_helper.class.php: call to restore_controller::load_controller() * line ? of unknownfile: call to copy_helper::{closure}() * line 247 of /backup/util/helper/copy_helper.class.php: call to array_map() * line 263 of /backup/util/helper/copy_helper.class.php: call to copy_helper::map_backupids_to_restore_controller() * line 54 of /lib/classes/task/backup_cleanup_task.php: call to copy_helper::cleanup_orphaned_copy_controllers() * line 163 of /admin/tool/task/cli/schedule_task.php: call to core\task\backup_cleanup_task->execute()I did not get further information on the error_opening_file issue, it does not state which file could not be openened. I doublechecked the moodledata folder and the access rights seem to be right. I also ran the task via the webinterface as well as the cli version via:
What version of Moodle do you have?
http://www.syndrega.ch/blog/#php-and-dbms-compatibility-of-major-moodle-releases
I don't think that maximum version for MariaDB is correct. That table is invaluable – I frequently refer to it myself – but it's not official.
There was a compatibility issue in MariaDB 10.6.0, see MDL-72131 for details. This has been resolved in 10.6.7 so if you have at least this version there should be no problems.
I have corrected the chart. See "From 10.6.7" between Moodle 3.9 and 4.0.

What I think is happening is:
- The task is trying to remove a failed course copy operation so it retrieves that operation's settings from the database.
- One of these settings is the location and name of the log file.
- There's a check to see if it can write to this log file. But it cannot so the error_opening_file occurs.
By default course copy operations – which does a backup and restore under the hood – writes log files to moodledata/temp/backup with names like a753a2492b5449b4affab1ef4659e716.log.
However it's possible to use a different location with $CFG->backuptempdir.
So what may have caused this issue is:
- The operation was started on a server with one backup temp dir location which was writeable.
- But the clean-up for this operation is being performed on a server where this backup temp dir isn't writeable.
To resolve this try running the SQL query:
SELECT REGEXP_SUBSTR(FROM_BASE64(controller), 'fullpath\";[^;]+')
FROM mdl_backup_controllers WHERE purpose = 80 AND status <> 1000;
This should show the log file location for incomplete copy operations. Do the directories exist? Are they writeable by the user that PHP scripts are being run as?
Is there a possibility to remove this incomplete copy operation manually?
You say "it should not happen when actually migrating after stopping Moodle and the cronjob" but this problem arises with new functionality in Moodle 3.11.8 and 4.0.2 (from MDL-74548). So if you migrated a site older than these versions then this problem could still occur. This is because the "orphaned" copy controllers may exist on the Moodle site being migrated to a later Moodle version but having different Moodledata paths. When the newly-implemented clean-up of orphaned copy controllers is attempted it would then fail as in your original issue. It's possibly a Moodle bug that should be fixed.
I think you could probably just set all incomplete course copy operations to "failed" with (back up your database before making changes such as these!):
UPDATE mdl_backup_controllers
SET status = 900 -- 900: STATUS_FINISHED_ERR
WHERE purpose = 80 -- 80: MODE_COPY
AND status <> 1000; -- 1000: STATUS_FINISHED_OK
If you wanted to do it exactly as the scheduled task would I think the SQL statements would be:
UPDATE mdl_backup_controllers
SET status = 900 -- 900: STATUS_FINISHED_ERR
WHERE purpose = 80 -- 80: MODE_COPY
AND status <> 1000 -- 1000: STATUS_FINISHED_OK
AND operation = 'restore'
AND backupid IN
(SELECT
SUBSTRING(REGEXP_SUBSTR(FROM_BASE64(controller), '\".\\*.tempdir\";[^;]+'), 20, 32)
FROM mdl_backup_controllers
WHERE purpose = 80 -- 80: MODE_COPY
AND status = 900 -- 900: STATUS_FINISHED_ERR
AND operation = 'backup'
);
UPDATE mdl_backup_controllers
SET status = 900 -- 900: STATUS_FINISHED_ERR
WHERE purpose = 80 -- 80: MODE_COPY
AND status <> 1000 -- 1000: STATUS_FINISHED_OK
AND operation = 'restore'
AND SUBSTRING(REGEXP_SUBSTR(FROM_BASE64(controller), '\".\\*.tempdir\";[^;]+'), 20, 32) IN
(SELECT
backupid
FROM mdl_backup_controllers
WHERE purpose = 80 -- 80: MODE_COPY
AND status = 900 -- 900: STATUS_FINISHED_ERR
AND operation = 'backup'
);
A possible alternative workaround could be to temporarily recreate the path structure of the old server (with appropriate permissions) to allow the task to complete. Once this is done the temporary path structure can be removed. The problem should not occur again while the backup paths in Moodledata remain constant.
Hello.
I'm impacted too with this error
and followed Rachid proposal didn't help.
I'm still stock with:
Execute scheduled task: Nettoyage des tables, journaux et fichiers de sauvegarde (core\task\backup_cleanup_task)
... started 11:19:04. Current memory use 1.8 Mo.
Debugging increased temporarily due to faildelay of 86400
... used 2 dbqueries
... used 0.0051310062408447 seconds
Scheduled task failed: Nettoyage des tables, journaux et fichiers de sauvegarde (core\task\backup_cleanup_task),error/error_opening_file
Backtrace:
* line ? of unknownfile: call to file_logger->__wakeup()
* line 97 of /backup/util/dbops/restore_controller_dbops.class.php: call to unserialize()
* line 502 of /backup/controller/restore_controller.class.php: call to restore_controller_dbops::load_controller()
* line 243 of /backup/util/helper/copy_helper.class.php: call to restore_controller::load_controller()
* line ? of unknownfile: call to copy_helper::{closure}()
* line 246 of /backup/util/helper/copy_helper.class.php: call to array_map()
* line 262 of /backup/util/helper/copy_helper.class.php: call to copy_helper::map_backupids_to_restore_controller()
* line 54 of /lib/classes/task/backup_cleanup_task.php: call to copy_helper::cleanup_orphaned_copy_controllers()
* line 410 of /lib/classes/cron.php: call to core\task\backup_cleanup_task->execute()
* line 208 of /lib/classes/cron.php: call to core\cron::run_inner_scheduled_task()
* line 125 of /lib/classes/cron.php: call to core\cron::run_scheduled_tasks()
* line 80 of /admin/cron.php: call to core\cron::run_main_process()
we are with Version Moodle : 4.4
Theme Moodle used : adaptable
Version PHP : 8.2
Database MariaDB 10.6
using a public cloud host @ infomaniak we can't recreate the full old path for temp folder structure.
and followed Rachid proposal didn't help.
But did you try the suggestion I posted? Because this does look like MDL-76288, which Moodle HQ have decided they won't fix (silently closing the bug report).
Yes I tried the SQL query but the code is not accepted, Maria respons is :
#1064 - Erreur de syntaxe près de ''\".\\*.tempdir\" AND (status <> 900 -- 900: STATUS_FINISHED_ERR)' à la ligne 6
I even tried to set $CFG->backuptempdir and choose/create a folder placed into MoodleData and be sure he is with 777 rights properties.
I've tried the syntax and it should work with MariaDB.
#1064 - Erreur de syntaxe près de ''\".\\*.tempdir\" AND (status <> 900 -- 900: STATUS_FINISHED_ERR)' à la ligne 6
This seems to be missing a lot of text from the suggested UPDATE statement. Please can you include a screenshot showing both the SQL statement you are running and this error message.
tried with CLI
but still
Execute scheduled task: Nettoyage des tables, journaux et fichiers de sauvegarde (core\task\backup_cleanup_task) ... started 17:13:45. Current memory use 36.5 Mo. Debugging increased temporarily due to faildelay of 960 ... used 2 dbqueries ... used 0.006817102432251 seconds Scheduled task failed: Nettoyage des tables, journaux et fichiers de sauvegarde (core\task\backup_cleanup_task),error/error_opening_file Backtrace: * line ? of unknownfile: call to file_logger->__wakeup() * line 97 of /backup/util/dbops/restore_controller_dbops.class.php: call to unserialize() * line 502 of /backup/controller/restore_controller.class.php: call to restore_controller_dbops::load_controller() * line 243 of /backup/util/helper/copy_helper.class.php: call to restore_controller::load_controller() * line ? of unknownfile: call to copy_helper::{closure}() * line 246 of /backup/util/helper/copy_helper.class.php: call to array_map() * line 262 of /backup/util/helper/copy_helper.class.php: call to copy_helper::map_backupids_to_restore_controller() * line 54 of /lib/classes/task/backup_cleanup_task.php: call to copy_helper::cleanup_orphaned_copy_controllers() * line 410 of /lib/classes/cron.php: call to core\task\backup_cleanup_task->execute() * line 194 of /admin/cli/scheduled_task.php: call to core\cron::run_inner_scheduled_task()
Hi Pascal,
Thanks for the screenshots and further information. You're correct: those UPDATE statements don't fix this (I can't see how they ever did). If you cannot make the old backup temp dir accessible by the task then the affected records must simply be deleted.
When this task cancels a course copy it writes to a log file in backup temp dir, the error/error_opening_file means it can't and the task fails. The backup temp dir for operations in mdl_backup_controllers
can be viewed with (change mdl_ to your $CFG->prefix
):
SELECT id, REGEXP_SUBSTR(FROM_BASE64(controller), 'fullpath\";[^;]+')
FROM mdl_backup_controllers WHERE purpose = 80 AND status <> 1000;
Example output:
+-----+-------------------------------------------------------------------------+
| id | REGEXP_SUBSTR(FROM_BASE64(controller), 'fullpath\";[^;]+') |
+-----+-------------------------------------------------------------------------+
| 101 | fullpath";s:70:"/var/www/backups//803f1c4c7511fedbbf63e9ecbdd2ee81.log" |
| 102 | fullpath";s:70:"/var/www/backups//2d3384d6dc0b56c35c2b3f3a2604bee3.log" |
+-----+-------------------------------------------------------------------------+
In this example the backup temp dir for all records is /var/www/backups
. You may have some records with the current valid location, you don't need to delete those as the task should clean them when this problem is resolved.
Use the id
field to specify which records to delete. For the above example this would be:
DELETE FROM mdl_backup_controllers WHERE id IN (101, 102);
Yes I tried the SQL query but the code is not accepted, Maria respons is :
#1064 - Erreur de syntaxe près de ''\".\\*.tempdir\" AND (status <> 900 -- 900: STATUS_FINISHED_ERR)' à la ligne 6
Thanks for the screenshot. This error was due to a bug in phpMyAdmin: #19187 Simulate query reports syntax error but the statement works.
The error Appear only with the main administrator (the first moodle admin) created during Moodle installation.
If you create new administrator and suspend the old one, the error disappear!!!
Until the MDL-76288 is fixed, create new admin and suspend the old one is the best solution for this issue!!!
Thanks
Admin swap didn't work for me, but deleted problematic records from mdl_backup_controllers did. Thanks to Leon Stringer for the help!