Upgraded to v7 without issue but ran into an issue trying to use mover.

 

I have a traditional array as well as a ZFS pool (Primus) that I have been moving data to slowly. I have previously moved two or my shares using this method but either I am missing something or this is broken now.

 

I am attempting to move data from Array > Primus, I have Primus set as the primary storage and the Array set as secondary, mover action is set to move from secondary to primary.

 

The log shows:

Jan 10 08:01:00 Orientis emhttpd: shcmd (49582): /usr/local/sbin/mover start |& logger -t move &
Jan 10 08:01:00 Orientis move: mover: started
Jan 10 08:01:00 Orientis move: mover: finished

 

I am not using the "mover tuner" plugin nor can I remember ever using it.

 

Edit: forgot to mention the share name: TV Series

orientis-diagnostics-20250110-1002.zip

Edited January 10, 20251 yr by tojoski
Forgot details

I'm not seeing why it's not working, but if I set a share the same way the mover works, try creating a new test share, with the same settings, then just create a file on a disk, e.g.:

mkdir /mnt/disk1/test
touch /mnt/disk1/test/a

then run the mover

Same thing here.
Since i updated today to 7, mover stopped doing anything.
I mean, it looks like it's starting but it doesn't do anything (eg: files stay in cache, no disks movement, nothing).

 

an 10 23:02:55 Incubus webgui: Successful login user root from 10.0.1.254
Jan 10 23:03:05 Incubus emhttpd: shcmd (4003): /usr/local/sbin/mover start &> /dev/null &
Jan 10 23:03:05 Incubus root: Starting Mover
Jan 10 23:03:05 Incubus root: Forcing turbo write on
Jan 10 23:03:05 Incubus kernel: mdcmd (43): set md_write_method 1
Jan 10 23:03:05 Incubus kernel: 
Jan 10 23:03:05 Incubus root: ionice -c 2 -n 0 nice -n 0 /usr/local/sbin/mover.old 
Jan 10 23:03:05 Incubus root: Restoring original turbo write mode
Jan 10 23:03:06 Incubus kernel: mdcmd (44): set md_write_method auto
Jan 10 23:03:06 Incubus kernel: 

:-/

EDIT: (seems solved).

So, it was the TurboWrite plugin.
Disabled, a run of mover, enabled again, and now it works.

Weird.

 

Edited January 10, 20251 yr by dhstsw

5 hours ago, dhstsw said:

EDIT: (seems solved).

So, it was the TurboWrite plugin.
Disabled, a run of mover, enabled again, and now it works.

Weird.

 

I have been unable to find a solution as of yet; I don't have any plugins installed that affect the mover to my knowledge.

I did some more testing and it seems this only affects moving data to the zfs dataset. 

 

I copied some data to my cache drive, then invoked the mover and it copied it to the array fine.

 

Jan 10 20:35:22 Orientis emhttpd: shcmd (55124): /usr/local/sbin/mover start |& logger -t move &
Jan 10 20:35:22 Orientis move: mover: started
Jan 10 20:35:22 Orientis move: move: /mnt/cache/Company/Shares.PNG Success
Jan 10 20:35:22 Orientis move: move: /mnt/cache/Company/Shares2.PNG Success
Jan 10 20:35:22 Orientis move: mover: finished

Same issue here, moving from btrfs pool to array. TurboWrite should be enabled for mover via mover tuning plugin, I didn't see a separate plugin, here's the relevant bit of log:

 

Jan 11 00:35:01 UNRAID root: Forcing turbo write on
Jan 11 00:35:01 UNRAID kernel: mdcmd (36): set md_write_method 1
Jan 11 00:35:01 UNRAID kernel: 
Jan 11 00:35:01 UNRAID root: ionice -c 2 -n 0 nice -n 0 /usr/local/emhttp/plugins/ca.mover.tuning/age_mover start 0 0 0 '' '' "/tmp/mover_start" "/tmp/mover_stop" '' '' '' '' 0
Jan 11 00:35:09 UNRAID root: Restoring original turbo write mode
Jan 11 00:35:09 UNRAID kernel: mdcmd (37): set md_write_method 1
Jan 11 00:35:09 UNRAID kernel: 

 

Next time around I'll try turning "Force turbo write on during mover" in mover tuning off. Also Disks settings has "reconstruct write" set as default, and in the log it returns to "1", so I guess that mover settings is not needed.

Getting a similar issue , mover not moving any files, once I removed the mover tuning plugin its worked as expected

 

2 hours ago, MightyT said:

TurboWrite should be enabled for mover via mover tuning plugin, I

Uninstall the plugin and retest.

7 hours ago, tojoski said:

I did some more testing and it seems this only affects moving data to the zfs dataset. 

I tried with a dataset and don't see any issues, did you try with a test share as mentioned? Using the same pools.

11 hours ago, JorgeB said:

I tried with a dataset and don't see any issues, did you try with a test share as mentioned? Using the same pools.

Ok so we may be getting somewhere. 

 

I made a share called "test" on the array, copied some data to it, then went in and set it to my zfs array (primus) and ran the mover. 

 

It ran fine, created the dataset and copied the data. The only thing I can guess is the mover in v7 has an issue with spaces in the share names?

 

As far as I can see that's the only difference between the "TV Series" share and the "test" share.

Confirmed above is the issue: I made a share called "test share" and the mover doesn't work

11 hours ago, tojoski said:

Confirmed above is the issue: I made a share called "test share" and the mover doesn't work

Thanks, I can duplicate that.

12 hours ago, tojoski said:

Confirmed above is the issue: I made a share called "test share" and the mover doesn't work

Haven't had time yet to do more tests but all my shares, and pool names, don't have any spaces in them.

 

I did try invoking '/usr/local/sbin/mover start' manually, that worked. The "move now" button does not, same as the scheduled run. Still need to test removing the plugin.

On 1/11/2025 at 11:05 PM, tojoski said:

I made a share called "test share" and the mover doesn't work

This issue should be resolved if you install the patch update (it will also be fixed for 7.0.1).

 

https://forums.unraid.net/topic/184435-unraid-os-version-700-available/page/10/#findComment-1519235

 

On 1/31/2025 at 5:08 AM, JorgeB said:

This issue should be resolved if you install the patch update (it will also be fixed for 7.0.1).

 

https://forums.unraid.net/topic/184435-unraid-os-version-700-available/page/10/#findComment-1519235

 

Can confirm this is fixed after applying the patch.

 

Thanks!

I have this issue recently as well. Strangely enough the automatic mover did work fine for me for my ‘Movies’ share, but does not work for my ‘backup’ share.

Primary storage for both is ‘Cache’ and secondary storage is ‘Array’. Mover action is Cache to Array. Nothing fancy there. I don’t have any plugins regarding the mover installed.

Using the automatic mover does nothing. Clicking the ‘Move Now’ in the GUI does invoke the mover in the log, but the files don’t move. When calling mover manually via CLI it starts and finishes immediately.

root@unRAIDTower:~# /usr/local/sbin/mover start

mover: started

mover: finished

The only error I have is from the Fix Common Problems plugin:

Jun 18 11:00:00 unRAIDTower root: Fix Common Problems: Error: Default docker appdata location is not a cache-only share

Though this should be ‘ok’ for now, as I currently don’t run any containers or VMs on the unRAID machine.

I did try to put a new folder in the Movies share and it was created in Cache, as expected and then when calling the mover via CLI the folder was moved to array. So this works fine. The only difference it seems between these two shares are the security settings. The Movies share is set to ’Secure’ and backup is set to ‘Private’. Though this should not influence the mover.

Now I’m quite confused.. this happens to me with the current 7.1.3

Any ideas?

Edited June 18, 20251 yr by Sono

2 hours ago, Sono said:

Any ideas?

Post the diagnostics and the name of the share(s) you expect to be moved.

Here you go. Sorry, could have thought of this beforehand.

As some shares have similar names, here are the configs of my examples:

Movies:

# Share exists on disk1, disk2, disk3

# Generated settings:

shareComment=""

shareInclude=""

shareExclude=""

shareUseCache="yes"

shareCachePool="cache"

shareCachePool2=""

shareCOW="auto"

shareAllocator="highwater"

shareSplitLevel="1"

shareFloor="50000000"

shareExport="e"

shareCaseSensitive="auto"

shareSecurity="secure"

shareReadList="..."

shareWriteList="..."

shareVolsizelimit=""

shareExportNFS="-"

shareExportNFSFsid="0"

shareSecurityNFS="private"

shareHostListNFS=""

For the backup share it says

# This share has default settings.

# Share exists on cache, disk1, disk2, disk3

I also saw in shareDisks.txt that I have a double entry for the backup. But in the GUI I have only ‘backup’ (lower case), which also matches the name in /mnt/user. Not sure where the capital letter Backup comes from.

B----p shareUseCache="yes" # Share does not exist

b----p shareUseCache="no" # Share exists on cache, disk1, disk2, disk3

unraidtower-diagnostics-20250618-1718.zip

8 minutes ago, Sono said:

shareDisks.txt that I have a double entry for the backup

You need to fix this. There are no settings for your actual share so it gets default settings. The cfg file that has the settings is for the non-existent share.

1 hour ago, Sono said:

Not sure where the capital letter Backup comes from.

Delete Backup.cfg from the flash drive, then reapply the setting for the backup share so that the correct cfg gets created, and the mover should then work for that one.

For the Movies share, there's nothing currently on the pool to be moved.

Look good so far. I did as JorgeB said. Mover is currently running. Thanks everyone.