Symptoms
When restoring or exporting a site, the process suddenly stalls and is unable to continue until you receive a JavaScript dialog error (sometimes not).
In addition, you might be getting runtime errors such as:
Uncaught Codexonics\PrimeMoverFramework\build\splitbrain\PHPArchive\ArchiveIOException: Could not open file for writing
You can also use this guide when encountering other runtime errors, aside from the known symptoms above.
Additionally, where and when it stalls is sporadic or random – when you try to re-run the restore/export, it will get stuck in different steps than before or at a different progress percentage.
Step 1: Check if you have Imunify360 enabled
Imunify360 is a web hosting security solution. Some web hosting companies add this as an extension or module to their cPanel or security suites. This security software runs in real-time to scan files inside your web server. This can cause issues if you are running an export or restore. This is because, while the site is restored, Imunify360 interferes with this process and could stop any running migration processes. The migration processes will then appear stalled once any of their processes are killed/stopped.
To check if you have Imunify360 enabled:
- Log in to your hosting control panel.
- Check if you have the Imunify360 module enabled. This might appear different from some web hosts, but it will look like this:
- Also, you can view this information inside your site’s phpinfo() output to check if the server is using this security module. You will see a section. i360 In the output, such as this:
Solution
Once it’s confirmed you have Imunify360 enabled, you can turn it off as follows (requires access to your cPanel or Hosting panel/console) :
- Log into cPanel (or your hosting manager) -> Imunify360 -> Proactive Defense and check on the “Detected Events” tab.
- Try checking if Imunify360 Proactive defense has detected/flagged a Prime Mover archive processor file –
/wp-content/plugins/prime-mover/build/splitbrain/php-archive/src/Tar.php - Once you see that it’s detected there, move the Prime Mover archive processor file to the “Ignore list”. This will cause Imunify360 Proactive defense to ignore this script during runtime and prevent it from stopping the migration process. Please see the attached screenshot below for an example of adding the Prime Mover archiver processor script to the ignore list.
- Once added to the Ignore list, clear your browser cache and repeat the restore process.
[OPTIONAL] If no Prime Mover script is detected under Detected Events, but you have Imunify Proactive defense enabled. Please try turning this off completely before doing any migration processes with Prime Mover for troubleshooting purposes.
If you don’t have access to your server to turn this off, please request that your web hosting support do so. You can re-enable this module once you are not running any export and restore tasks.
Step 2: Check if the server is using any security module other than Imunify360
Sometimes, the server is not using Imunify360 but instead uses a different security solution. If this is the case, please contact your web hosting support and ask if they use any real-time security file scanning. You should deactivate all of these before proceeding to any restore or export processes.
Step 3: Check if your hosts have some tight resource controls
If your host does not use any real-time security file scanning solutions and you still experience stalled export or restore, most likely this is due to the tight resource controls implemented by your host.
You will know this because Prime Mover will bail out any timeout errors, etc. The only solution in this case is to open a ticket with your hosting company and request the following:
- Temporarily increase timeout controls.
- Temporarily lift any hosting resource controls in your account (e.g., request controls, etc.)
This should happen only to a few hosts. Prime Mover plugin is designed to handle timeouts even in a very restrictive shared hosting environment. Currently, this is how the Prime Mover plugin deals with this:
- By default, the Prime Mover timeout is set to 15 seconds. This is lower than most hosting timeouts, which typically range from 30 seconds to several minutes. The default PHP maximum execution timeout is 30 seconds. Most hosting companies should even use a more conservative timeout, e.g., a minute or more. If a migration process takes more than 15 seconds, Prime Mover times out and exits the process to avoid hitting the server timeout. It will then make another request so that each of the long-running processes will not exceed the hosting timeout limitations.
- Prime Mover progress AJAX interval sends a request every 7 seconds to check the status of the restore or export process. This is very conservative and should not overload any server.
- Prime Mover waits for one second before sending another export or restore AJAX request.
- Only Prime Mover plugin processes are running when doing any export or restore tasks. It won’t execute third-party plugin code or themes. This is to conserve resources, such as CPU and RAM, while performing a restore.
These controls are tested to work even with the cheapest and most restrictive shared hosting environments (including free hosting). Suppose these controls within Prime Mover are still insufficient for your hosts. In that case, you should contact your hosting company and temporarily lift any restrictions inside your account so that you can successfully migrate sites.
Step 4: Escalate to Technical Support
If you have completed all the above steps and are still experiencing this issue, please contact us so we can confirm that you are still having the problem. We will then identify workarounds that best suit your specific case.
Last updated: June 15, 2025