7.0.0-beta.1 - Mover Not Running, neither scheduled or manual

Have you tried booting in Safe Mode and seeing if then runs?   If it runs OK in Safe Mode then it would point to you having a plugin causing the problem.

Enable mover logging, run the mover, post new diags, and lets us know from which share(s) do you expect files to be moved.

Same issue here, problem appears to be mover syntax:

 

4 12:14:49 UNRAID root: Starting Mover
Jul  4 12:14:49 UNRAID root: Forcing turbo write on
Jul  4 12:14:49 UNRAID kernel: mdcmd (38): set md_write_method 1
Jul  4 12:14:49 UNRAID kernel: 
Jul  4 12:14:49 UNRAID root: ionice -c 2 -n 0 nice -n 0 /usr/local/sbin/mover.old 
Jul  4 12:14:49 UNRAID move: Usage: /usr/local/sbin/mover.old start [-e] <disk_name>
Jul  4 12:14:49 UNRAID move:        /usr/local/sbin/mover.old stop|status
Jul  4 12:14:49 UNRAID move:        <disk_name> must match pattern 'disk[0-9]*'
Jul  4 12:14:49 UNRAID root: Restoring original turbo write mode

Manually executing "mover start" from a CLI works though.  Here's what the log says if I do that:

Jul  4 12:16:59 UNRAID root: Forcing turbo write on
Jul  4 12:16:59 UNRAID kernel: mdcmd (40): set md_write_method 1
Jul  4 12:16:59 UNRAID kernel: 
Jul  4 12:16:59 UNRAID root: ionice -c 2 -n 0 nice -n 0 /usr/local/sbin/mover.old start

 

After these syslogs, and with mover logging enabled, I see the files being moved successfully.

Anonymised diagnostics attached.

unraid-diagnostics-20240704-1221.zip

Edited July 4 by Kaldek
Added results of manual mover execution

1 hour ago, Kaldek said:

Same issue here, problem appears to be mover syntax:

 

4 12:14:49 UNRAID root: Starting Mover
Jul  4 12:14:49 UNRAID root: Forcing turbo write on
Jul  4 12:14:49 UNRAID kernel: mdcmd (38): set md_write_method 1
Jul  4 12:14:49 UNRAID kernel: 
Jul  4 12:14:49 UNRAID root: ionice -c 2 -n 0 nice -n 0 /usr/local/sbin/mover.old 
Jul  4 12:14:49 UNRAID move: Usage: /usr/local/sbin/mover.old start [-e] <disk_name>
Jul  4 12:14:49 UNRAID move:        /usr/local/sbin/mover.old stop|status
Jul  4 12:14:49 UNRAID move:        <disk_name> must match pattern 'disk[0-9]*'
Jul  4 12:14:49 UNRAID root: Restoring original turbo write mode

Manually executing "mover start" from a CLI works though.  Here's what the log says if I do that:

Jul  4 12:16:59 UNRAID root: Forcing turbo write on
Jul  4 12:16:59 UNRAID kernel: mdcmd (40): set md_write_method 1
Jul  4 12:16:59 UNRAID kernel: 
Jul  4 12:16:59 UNRAID root: ionice -c 2 -n 0 nice -n 0 /usr/local/sbin/mover.old start

 

After these syslogs, and with mover logging enabled, I see the files being moved successfully.

Anonymised diagnostics attached.

unraid-diagnostics-20240704-1221.zip

Are you using the mover tuner plugin?

4 hours ago, Kaldek said:

Same issue here, problem appears to be mover syntax:

You are using the mover plugin, so not the same issue, and you should re-test without it.

14 hours ago, JorgeB said:

Enable mover logging, run the mover, post new diags, and lets us know from which share(s) do you expect files to be moved.

The shares on cache that need to moved to array are: BACKUPS, Movies1, MUSIC

diags attached

tower-diagnostics-20240704-0117.zip



PS. I tried CLI as mentioned above and got this response back immediately:

root@Tower:~# mover start
mover: started
mover: finished
root@Tower:~# 

Edited July 4 by interwebtech
added CLI result

There's no pool defined for those shares, post a screenshot from the Shares page for one of those shares.

2 hours ago, JorgeB said:

You are using the mover plugin, so not the same issue, and you should re-test without it.

Ah.  I seem to have been confused between the old "mover tuner" plugin and the new mover features.

Mover tuner removed, and my mover is now working.  Apologies for adding confusion to this issue folks.

3 hours ago, JorgeB said:

There's no pool defined for those shares, post a screenshot from the Shares page for one of those shares.

Other than the cache pool I have no pools defined. An old school unRaid set up with cache pool of 4 NVMe in RAID1, 18 disk array with dual parity.

@interwebtech  With those settings mover is not meant to take any action (regardless of where existing files/folders are located).    Mover will only act on shares where you have both primary and secondary storage set.

8 minutes ago, itimpi said:

@interwebtech  With those settings mover is not meant to take any action (regardless of where existing files/folders are located).    Mover will only act on shares where you have both primary and secondary storage set.

Walk me through what my settings should be for this share. I want uploads to stay on cache until mover runs at night to put them on the array. 

 

ps. like this?

 

Edited July 4 by interwebtech

Okay Mover now running on that share's files. 

I was unaware that old setups needed to be redefined with new pool feature. I'll update the rest now.

Edited July 4 by interwebtech

12 minutes ago, interwebtech said:

Okay Mover now running on that share's files. 

I was unaware that old setups needed to be redefined with new pool feature. I'll update the rest now.

Nothing that was previously configured correctly would have needed changing.

 

the only ‘new’ feature is that you can now have pools as both primary and secondary storage.   Previously only the array could be secondary storage.

51 minutes ago, itimpi said:

Nothing that was previously configured correctly would have needed changing.

Yep, from which release did you upgrade? And the mover was working for those shares before?

1 hour ago, JorgeB said:

Yep, from which release did you upgrade? And the mover was working for those shares before?

Mover working fine. Upgraded from 6.12.10. I am pretty consistent on staying at the current build whether stable or beta. Something in 7 beta started enforcing some setting that up until then was not required.

 

There just wasn't a primary/secondary location setting before (last time I made changes). The assumption was if you had cache, files went there until mover ran and put them on the array. The new UI with the directional icons is much better.

6 minutes ago, interwebtech said:

There just wasn't a primary/secondary location setting before (last time I made changes).

That exists since v6.12, but you might not have needed to change anything there for some time, still strange because we don't have any other similar reports, possibly related to when the shares were created, not the last version you were running.

this is the closest i could find to the issue im having. i'm on 7.0.0-beta.2. Apparently my mover stopped working before 8/4/24 (oldest files the mover should have moved from cache to array). I dont have the mover tuner plugin. if i try to start the mover, i get the below. if i run "mover start" from the cli, i get the same thing. safe mode with docker stopped, same thing. i think my only option might be to downgrade to v6.12.

 

Aug 21 21:16:17 Cortana move: mover: started
Aug 21 21:16:17 Cortana move: mover: finished
Aug 21 21:16:17 Cortana move: mover: started
Aug 21 21:16:17 Cortana move: mover: finished

--------------------

I figure i should finish this since i figured it out.

I downloaded my diagnostic logs and started going through them before i was getting ready to upload them to here.
In the shares folder\shareDisks.txt, I have 2 entries for a folder that wasnt working for me.

 

Media                             shareUseCache="yes"     # Share does not exist

media                             shareUseCache="no"      # Share exists on cache, disk1, disk2, disk3, disk4, disk5, disk6, disk7, disk8

 

I went into the share and added an 'a' to the name just to have it trigger a rename. started the mover and now its working. it now shows as "Mediaa". I was able to rename the folder to "Media" and start the mover again and its working fine. I have one more share that has the same type of entries.

 

E30Z                              shareUseCache="yes"     # Share does not exist
e30z                              shareUseCache="no"      # Share exists on cache, disk1, disk2, disk3, disk4, disk5, disk6, disk7, disk8, disk9

 

logs attached incase they become useful.
 

 

 

cortana-diagnostics-20240821-2125 (1).zip