by Ken Task.
@Doug ...
In a stock moodle installation, moodle has a temp directory it uses for backups and restores.
Check your moodledata directory for a 'temp' directory and inside there a 'backup' directory. So path would be /moodledata/temp/backup/
You shouldn't have to mess with doing anything to an .mbz file to get a restore to work. So whatever you've done to the .mbz file un-do or re-acquire the .mbz from whatever server it was created.
If temp/backup don't exist in moodledata, then wonder how the moodle was installed? And, if hosted with a provider, is the provider 'moodle friendly' or not.
If those directories are not present in moodledata you could try to create them yourself with any tool you might have that works with files and folders. If you do that, make sure the directories you create are readable/writable to the web service user ... or account user in the case of remotely hosted situations setup to run that way.
What moodle does when rstoring ... it un-compresses the .mbz to /moodledata/temp/backup/ using a 'contenthash' type directory ... looks something like 'q230123fqwghiwwlwndhger' Then uses that directory to extract and restore or build the backup. Thus the user under which your moodle is running needs read/write ability to be able to create that directory.
The other possibility has the potential to cause some issues like this (although your version of Moodle shouldn't) ... task/cron job for cleaning up temp areas. Search using site admin search box for 'task' ... find the list of task that will be executed when cron job is run, and see what the scheduling of anything related to 'clean up'. Might have to turn that off as a test to see if that resolves the problem. If that did, turn back on and schedule it for some time when you wouldn't be restoring courses - uhhhh, weee hours of am?
'spirit of sharing', Ken