NAS SETUP, MAINTENANCE & RECOVERY
A Mover run that clashes with evening streaming or fills the wrong pool needs a controlled stop and a review of its next trigger. This UK guide explains the built-in stop command, why disk activity may continue briefly, and what to check before running Mover again. Keep the current operation separate from the schedule that launched it.
Quick answer
For the built-in Unraid Mover, open the server terminal and run mover stop. Allow the current file operation to finish, then confirm that Mover is no longer active. Avoid force-killing copy processes or switching off the server. Check the share's storage direction and the scheduler before restarting; a third-party Mover plugin can add its own triggers and behaviour.
Steps to follow
-
Identify which operation is actually running
Open Main and inspect the current array operation. A parity check, rebuild, scrub and Mover run are different jobs, even though all can produce sustained disk activity. Do not issue a Mover command to solve a parity operation. Record the running Unraid version and whether a Mover-related plugin is installed before interpreting controls shown in an online screenshot.
Check the relevant share's primary and secondary storage destinations. Recent Unraid releases describe these explicitly, while older guides may use cache settings such as Yes or Prefer. Read the help for your installed version instead of translating old labels by instinct. If data is travelling towards a nearly full pool, knowing that direction matters more than making the activity light stop immediately.
-
Request a controlled stop
Use the terminal available from the trusted local administration interface and enter
mover stop. This command is documented by Unraid's maintainers for stopping the built-in Mover. A stop request is not necessarily instant: the current file operation may still need to finish. Do not repeatedly issue increasingly forceful process-kill commands because a large file takes time to complete.If your installed release exposes an explicit Stop Mover control, check its help and use the supported control for that release. Do not assume a proposed interface feature exists in every version. Likewise, a plugin can wrap the built-in process, so consult that plugin's maintained documentation when its status or scheduling differs from the core interface.
-
Confirm the stop before changing storage
Check the Mover state again and observe whether new file transfers have stopped. Disk activity can continue for other reasons, including a virtual machine, application database or client backup. Separate those workloads rather than treating every read or write as proof that the stop failed. Review the log for a blocked file, connection fault or full destination if the task cannot finish normally.
Avoid powering off to make an inconvenient process disappear. If Mover remains stuck, save diagnostics and get version-specific advice before a forced shutdown. A storage problem can make both the stop request and ordinary file access appear frozen. Preserving the log and original paths gives you a better chance of distinguishing that fault from a scheduler issue.
-
Correct the next trigger before restarting
Review Settings and Scheduler for the installed release and inspect any plugin schedule separately. Choose an appropriate disabled or rescheduled state where supported, then save it. A manual stop concerns the current run; an automated trigger can start a later run again. Write down which scheduler owns the task so a future administrator does not edit the wrong one.
For an incorrect direction, adjust the affected share deliberately after confirming the intended final location and available capacity. Test with a small, replaceable set of files first. Restart Mover only when the destination and free-space policy make sense. Check that the test files remain readable through the normal share before relying on the same settings for a large library.
Detailed guidance
Stopping a move does not roll back completed moves
Files already moved stay at their completed destination; files not yet processed remain where they were. The user share can combine those locations into one view, so that split is not automatically a fault. Do not start a bulk manual copy simply to make the physical paths look uniform while you are still diagnosing the original job.
If an application expects a direct pool path rather than the merged user share, check its mount configuration separately. It might see a different location from a desktop client browsing the share. Record the path used by the application before altering storage settings, then validate through that same application when the placement change is finished.
Open files and full destinations need different remedies
A busy application can keep files in use, while inadequate free space prevents a destination from accepting them. Stopping Mover does not resolve either condition by itself. For application data or virtual-machine disks, plan a maintenance window that stops the relevant writer cleanly and preserves its backup. Do not force a live database into a copy procedure designed for ordinary closed files.
For a full destination, first identify what consumes the space and whether that data has an independent copy. Increasing capacity, adjusting the placement policy or reducing incoming work may be appropriate. Deleting unfamiliar appdata folders to make room is not a safe general solution. A folder with a small-looking name can contain the only persistent state for a service.
Avoid the user-share and disk-share copy trap
An Unraid user share and a physical disk share can expose the same underlying files. Copying between those views without understanding the overlap can make a source and destination refer to the same data. Keep emergency file moves simple: use a clearly separate backup destination, or follow the documented method for the exact migration you intend.
A useful incident note records why you stopped Mover, its original direction, the remaining free space and the setting that will govern the next run. That is more valuable than a screenshot showing only that the process has stopped. The next scheduled job should behave predictably, not recreate the same capacity or placement problem overnight.
Compare the options
| Situation | Recommended action | Check before continuing |
|---|---|---|
| Mover running at an inconvenient time | Request mover stop and wait for the current file operation |
Confirm it is Mover rather than parity or a rebuild |
| Mover restarts later | Review core and plugin schedules | Stopping a run does not remove its next trigger |
| Files move towards the wrong pool | Check share storage direction before a small test | Do not rely on labels from an older Unraid release |
| Persistent I/O fault or frozen transfer | Save diagnostics and seek targeted advice | Avoid force-killing processes or cutting power |
Frequently asked questions
Can I reboot instead of stopping Mover?
A normal shutdown should be managed through Unraid, but rebooting is a poor first response to an unexplained active transfer. Request a stop, allow it to settle and investigate any persistent fault before choosing a shutdown. Cutting power can add an unclean-shutdown problem.
Will stopping Mover delete the remaining files?
The supported stop request is intended to end the run without a blanket deletion of files waiting to move. Completed moves are not reversed. Verify the relevant files through their normal share and investigate logged errors rather than assuming that every file reached its intended destination.
Official documentation
This guide combines current official documentation with practical recovery checks. It does not claim hands-on testing of your installation. Menu labels and supported procedures can vary by release; follow the documentation for your installed version.