Hoping someone can help as I'm out of ideas.   I noticed after upgrading to 7.0 that mover stopped moving.   I don't use the CA Mover Tuning plugin.   I did see that some of my shares settings were changed so I tried to return them to the way they were before but still didn't work.   Mover log was showing duplicate file exists (for all kinds of files)... I believe I have resolved that..   I'm guessing I have something wrong still...

stormwatch-diagnostics-20250126-1020.zip

Names for the share(s) you expect to be moved please.

MEDIA and tempmedia are the shares that should get moved from cache to the array.

It looks like I may have got it working, things seem to be moving now.   For anyone else, I stopped my array and then I had to go into the \\<SERVER>\flash\config\shares directory and make sure the capitalization on the share .cfg files matched.  After that I started the array again.  Not sure if there is an easier way to resolve but my "Clean Up" button was grayed out in the shares gui.   

Edited January 26, 20251 yr by Ryanagon

Can confirm I had the same issue, and the solved the same way.

I could not rename them directly from "movies.cfg" to "Movies.cfg", had to make it a temp name first, and then rename to the correct capitalization.

Similar issue, Unraid 7.0. My \<SERVER>\flash\config\shares directory *.cfg files were all named correctly.  No issues. But after installing OpenFile Plugin, I saw that Fuser wasn't being shutdown. Killing the PID worked, assuming temporarily. 

Thanks @Ryanagon !!!

My main share is named "data", the config file name was "Data.cfg" (\flash\config\shares). Got the mover to work again after first renaming the file to "xData.cfg" then to "data.cfg". The sytem did not allow me to rename directly from "Data.cfg" to "data.cfg".

Thanks all, had the same thing. Discovered it due to cache almost full, and mover unable to run. Had to rename a .cfg file on flash to correctly match with share name. Was just one share/cfg with this issue.

Had the exact same issue, mover had not picked up several files and my cache was filling up. There were no errors in the logs even after turning them on for Mover, it just acted like it couldn't see the files at all (I assume because it didn't know where they should go as the .cfg was named wrong). 

 

I stopped the array

Edited the .cfg in \flash\config\shares to a temporary name (i.e. Sharex)

Edited the .cfg again to it's proper name (i.e. Share)

Started the array

Force ran Mover and it picked everything up as expected.

 

For those of us that troubleshot through this, don't forget to turn mover's logging back off if you enabled it or it will fill up your logs if you have a lot of files that transfer.

On 1/26/2025 at 4:26 PM, Ryanagon said:

It looks like I may have got it working, things seem to be moving now.   For anyone else, I stopped my array and then I had to go into the \\<SERVER>\flash\config\shares directory and make sure the capitalization on the share .cfg files matched.  After that I started the array again.  Not sure if there is an easier way to resolve but my "Clean Up" button was grayed out in the shares gui.   

Holy crap. THANK YOU. I was tearing my hair out trying to figure out why Mover seemingly just wasn't doing anything. I was freaking out when my Cache Drive was filling up and not moving anything to my data share on the array even when i manually invoke the Mover command. 

 

my "data" share had inexplicably been renamed to "Data".

 

Do you think this is some bug upgrading to Unraid 7.x ?

I feel like there should be a PSA about this. Because nothing in the Unraid Gui gives any indication that there is anything different/wrong. 

 

 

For anyone who finds this post. If you have a Cache Pool, and the you are sure that the share settings are correct try this fix.  

For me i have a "data" share where I store all my media. But I use the Cache Pool as the original location for faster writes. 

Primary Storage -> Cache

Secondary Storage -> Array

 

Here is the Fix. 

-Take note all your shares. (Capitalization matters)

-Stop Array

-Open terminal and cd /boot/config/shares

-ls command to review all [share].cfg files you noted previously. 

-If you find one that doesn't EXACTLY match you can use the mv command to rename. 

-My example: mv /boot/config/shares/data /boot/config/shares/data1

    -Then : mv /boot/config/shares/data1 /boot/config/shares/data

-I rebooted the Server then started the Array

Optional:

-Unraid Settings > Scheduler > Mover Settings > Mover Logging: Enabled

-Move Now

-Unraid Tools > System Log > Scroll all the way down. You should see your files being moved. 

-Make sure you Disable Mover Logging afterwards. 

Edited April 12, 20251 yr by foxythefoxer
Fixed my Grammer

I'd just recently noticed my cache was pretty full, and I don't think it has been moving since upgrading to v7.  I took a look in my /boot/config/shares directory and saw a file in there for a share that I haven't had in probably two years.  The share no longer exists, as it was just a temporary one created to troubleshoot something.  After the troubleshooting had been completed I got rid of that share.  But for whatever reason the config file remained in that directory.  I stopped the array and deleted that file, restarted the array and tried starting the mover again.  No dice.  *grumble*  "Alright, maybe I'll reboot, too."  Did that, and when everything was back up I tried starting the mover.  Worked again.  Strange that the config file remained after deleting the temporary troubleshooting share.  Nuking that did the trick, at least it did after rebooting, too.

 

edit: Well, crap.  Spoke too soon.  It did move something around, as the cache drive now contains about 24 GB more data than before.  But the mover finished and exited and all of my share files and directories are still there.  All that stuff should've been moved to the hard drives.  Now I *really* don't get what's going on.

 

edit2: Hmm, strange.  So, after removing that erroneous file and rebooting, when I came back to have another look a little while later there were some notifications from the Fix Common Problems plugin.  It stated that there are some shares set to not use the cache but there are files on the cache that should belong to those shares.  So I start looking at my shares settings page, and NONE of them are set to use the cache anymore.  So it would seem something in the v7 upgrade process (or maybe even one of the earlier version upgrade processes) somehow changed my share settings.  I turned the cache back on for all of them and now the mover is finally doing what it should be doing again.  Yay!

Edited April 18, 20251 yr by _Shorty

1 hour ago, _Shorty said:

and NONE of them are set to use the cache anymore

If you set a share to this and there happened to be any files on the cache at the time you make the change then they get left there.   Could that be what happened?

7 minutes ago, itimpi said:

If you set a share to this and there happened to be any files on the cache at the time you make the change then they get left there.   Could that be what happened?

Nope, I haven't touched my share settings since adding the cache years ago.  All shares were set to use the cache and move to the array, and that's how I left it for years.  And until what seems to me to be around the time I updated to v7 the cache had been used all the time.  Every single share had cache usage turned off when I looked into this today.

 

edit: Well, to be more accurate, yes, what you describe does indeed seem to be what happened.  But the problem is that *I* didn't turn off cache usage for any shares.  Now it makes more sense as to why my backup script from another machine seemed to be taking longer than usual lately.  Cache was no longer in use.

Edited April 18, 20251 yr by _Shorty

I've been experiencing the same issue. I couldn't figure out why mover wasn't doing anything - share was set to "downloads" in UI, but upon checking the config/shares directory on the flash drive it was listed as "Downloads.cfg". I didn't want to stop the array, so I renamed the share to "Downloads" in the UI, and then back to "downloads" and that updated the cfg file to the correct name - mover is now moving again 🙂 Thanks @Ryanagon !