The issue with moosh is probably a matter of setting up an alias for moosh.php script so you can type/use just 'moosh'.
That aside, however, appearing to hang, but there is a course shell restored ... or screen shot suggest that's the case ... I see 'weeks' with a link to turn down each week. Looks like Collapsed Topics addon as turning down weeks/or topics is not part of core code.
So do you have Collapsed Topics addon installed?
Also, the very last thing a restore would do is to cleanup /moodledata/temp/backup/[somecontenthashdirectorybylettersandnumbers]/
Do you have any directories in /moodledata/temp/backup/ with long names? If so what's in them?
Ownerships/permissions on /moodledata/temp/ are rwx (globale all) recursively?
There is also a scheduled task to clean up ... by chance is that executing at a time where the restore process is getting romped upon?
'SoS', Ken
Exception - Call to undefined function lti_get_instance_type()
More information about this error
×Debug info:
Error code: generalexceptionmessage
×Stack trace:
line 224 of /mod/lti/service/gradebookservices/backup/moodle2/restore_ltiservice_gradebookservices_subplugin.class.php: Error thrown
line 103 of /backup/moodle2/restore_subplugin.class.php: call to restore_ltiservice_gradebookservices_subplugin->after_restore_lti()
line 445 of /backup/util/plan/restore_structure_step.class.php: call to restore_subplugin->launch_after_restore_methods()
line 106 of /backup/util/plan/restore_task.class.php: call to restore_structure_step->launch_after_restore_methods()
line 205 of /backup/util/plan/restore_plan.class.php: call to restore_task->execute_after_restore()
line 135 of /backup/moodle2/restore_final_task.class.php: call to restore_plan->execute_after_restore()
line 818 of /backup/moodle2/restore_stepslib.php: call to restore_final_task->launch_execute_after_restore()
line 34 of /backup/util/plan/restore_execution_step.class.php: call to restore_execute_after_restore->define_execution()
line 181 of /backup/util/plan/base_task.class.php: call to restore_execution_step->execute()
line 178 of /backup/util/plan/base_plan.class.php: call to base_task->execute()
line 168 of /backup/util/plan/restore_plan.class.php: call to base_plan->execute()
line 385 of /backup/controller/restore_controller.class.php: call to restore_plan->execute()
line 219 of /backup/util/ui/restore_ui.class.php: call to restore_controller->execute_plan()
line 143 of /backup/restore.php: call to restore_ui->execute()
Here are the files that are in the temp/Backup
Here are the permissions for the folders
Your site must have multiple folks restoring courses ... or backing them up!
In moodledata/temp/backup/ successfull restores leave only a 0 byte .log file. Any log file larger than 0 bytes has some info in it that might be worth a gander ... IF you can tell what restore attempt is associated with the log file.
Do you have automated backups turned on and running?
Anything/everything in moodledata/temp/backup/ can be manually erased via command line, but if you do that when another admin or autobackups or something else is making a backup that will be disrupted.
Debug shows a hint:
restore_ltiservice_gradebookservices_subplugin
So does this problem course backup have an LTI resource in it?
Is this course still viewable in site? If so, make another backup but this time de-select any LTI resource contained therein. Then try to restore that backup. When doing this, change the name of the backup file slightly by adding a -nlti- in it's name so you know that backup contains no LTI resources/links in it.
'SoS', Ken
So the error is:
Exception - Call to undefined function lti_get_instance_type()
and the line at the top of the stack trace is:
line 224 of /mod/lti/service/gradebookservices/backup/moodle2/restore_ltiservice_gradebookservices_subplugin.class.php: Error thrown
On the above line of that file there is the call as expected to the function the error says is missing:
224 if ($tool = lti_get_instance_type($instance)) {Line 29 of the same file loads the file containing this function:
29 require_once($CFG->dirroot.'/mod/lti/locallib.php');
And as expected this function is defined in that file, mod/lti/locallib.php:
512 function lti_get_instance_type(object $instance) : ?object {Is the file mod/lti/locallib.php present on your Moodle server and does it contain the above line?
That indicates that mod/lti/locallib.php isn't the correct version for Moodle 3.9. Function lti_get_instance_type() wasn't present in Moodle 3.7 so maybe it's still the old file.
So you should ensure this file is the correct one for your Moodle version. But if one file is wrong there may be others too so I'd recommend ensuring all the Moodle source code files are correct, following steps such as:
'copied files over from git...' Hmmm ... why not just use git on the true code directory. No moving parts (missing files) and a heck of a lot easier to update or upgrade.
Please see:
https://docs.moodle.org/310/en/Git_for_Administrators
'SoS', Ken