Hi guys

I have managed to get into a real state with my cache disk now... for weeks I have had issues after upgrading my cache disk.

I moved the appdata, domains & system shares from the cache disk to the array installed a 2Tb cache disk - but before I removed the original cache disk from the pool, and replaced with new larger disk, I noticed I had left appdata share set to primary storage = Array and secondary storage = Cache (mover action = Cache -> Array).

So today I clicked mover, to move all my files to the array, so I could set appdata to primary storage = Array & secondary storage = None, when everything was off the small cache disk. However I had forgotten to stop all my dockers & disable dockers from settings. So, I stopped them anyway and disabled dockers from settings so no files were being changed while mover is trying to run... I haven't stopped VMs as I am hosting some active websites in an Ubuntu VM which cant be shut off during the working day!!! However since starting the cache disk has been showing 12.2Gb in use and doesn't seem to be doing anything - even though mover says it's tunning;

My appdata share is still showing all over the place...

This is all that is on the cache disk at the moment;

I only realised that this upgrade was incomplete because I have been having massive issues with dockers and today re-created jacketvpn and suddenly it stopped working. When I checked the docker logs said there was no ovpn file... when I delved into this I found that the docker was set to use /mnt/cache/appdata/jacketvpn - but the ovpn file wasnt there, it had moved to a disk on the array, so would only work by changing the location for jacketvpn to use to /mnt/user/appdata/jacketvpn!!

Anyway, my question is why mover is taking so long to move 12.2Gb of files to the array (in about 30 mins it hasn't gone down at all!).

Can anyone offer any thoughts? Thanks

Edited October 7, 2025Oct 7 by SliMat

Mover will take a long time to move many small files, which is normal with appdata, recommend just waiting.

Thanks @JorgeB - just checked and an hour in it is down to 11.6Gb :)

One question - I plan to have appdata on my cache disk (again), so is it better to set dockers location in their settings to /mnt/cache/appdata/xxx or /mnt/user/appdata/xxx? I dont know if there is an accepted standard?

/mnt/cache will typically be better for performance (if the share is not exclusive), but if you do that, make sure to remember that it will need adjusting if you change the pool name. If possible, I would recommend using an exclusive share, and then you can use /mnt/user

3 hours ago, JorgeB said:

Mover will take a long time to move many small files, which is normal with appdata, recommend just waiting.

The mover stopped but there was still files on the cache disk... so I wondered if the problem is because some of the dockers were set to use /mnt/cache/appdata and some files here moved to /mnt/user/cache/appdata and so were not available to the docker/s making them fail. So I recreated some of the dockers and therefore there is a chance that there are duplicate (identical) files in /mnt/cache/appdata/xxx and /mnt/user/cache/appdata/xxx

I noticed that the reads on the cache disk haven't increased in hours!

Would I be better moving files from /mnt/cache/... to /mnt/user/cache/... using Midnight Commander and if there are duplicates selecting the "overwrite if newer" option?

Or should mover work it out?

Note that the mover won't move existing files. Enable mover logging, run the mover, post the diags.

9 minutes ago, JorgeB said:

Note that the mover won't move existing files. Enable mover logging, run the mover, post the diags.

OK, I rebooted the server and re-ran mover. Disk 5 which hosts a lot of /mnt/user/appdata/xxx files is climbing reads rapidly... while reads on the cache disk is only a couple of hundred. It has only been running a few minutes, and is still showing as moving... but here are the diags so far...

phoenix-diagnostics-20251007-2035.zip

I took a look in syslog.txt and there are lots of lines saying;

Phoenix move: move: /mnt/cache/appdata/xxx/xxx File exists

So, it looks like this is the problem - although as I am trying to move off the cache disk, I expected it to say something like;

Phoenix move: move: /mnt/user/appdata/xxx/xxx File exists

So, is the easiest way to solve this (now I have rebuilt most dockers to get them working again), start dockers... make a note of whether they are using /mnt/user/appdata, or /mnt/cache/appdata as their install location and then manually copy (using Midnight Commander) any docker files from /mnt/cache/appdata, where it shows as being the install path, to /mnt/user/appdata - update the dockers path from /mnt/cache/appdata, to /mnt/user/appdata - restart dockers and check they work, then delete everything on the cache disk and start the move to the new cache disk?

Thanks for any help in advance.

Its been running for just over an hour - latest diags attached...

I will leave it running overnight and check again tomorrow during the day!

phoenix-diagnostics-20251007-2136.zip

OK been up for nearly 14 hours and mover is showing as stopped - so attached is the latest diags and cache disk still shows 11.6Gb not moved.... so am wondering whether I can just assume all these files are already on /mnt/cache/appdata/... and switch to the new (empty) cache disk.

Thanks

phoenix-diagnostics-20251008-1009.zip

14 hours ago, SliMat said:

moved to /mnt/user/cache/appdata

I think you really mean they went to /mnt/user/appdata? The path /mnt/user/cache/appdata refers to a user Share called 'cache' that contains a sub-folder called 'appdata'

Once upon a time we always used to recommend using /mnt/cache/appdata as it performed better than using /mnt/user/appdata if the files were actually on the 'cache' pool as it bypassed the Fuse layer in Unraid. . Nowadays with the support for Exclusive shares the /mnt/user/appdata path performs just as well if 'appdata' is an Exclusive share as Exclusive shares also bypass the Fuse layer.

1 minute ago, itimpi said:

I think you really mean they went to /mnt/user/appdata? The path /mnt/user/cache/appdata refers to a user Share called 'cache' that contains a sub-folder called 'appdata'

Apologies yes this was a typo, the two locations are /mnt/user/appdata... and /mnt/cache/appdata

I am currently manually using Midnight Commander to copy any files which needed by dockers and are still on /mnt/cache/appdata... to mnt/user/appdata/... so I can delete the cache drive assignment and assign the new larger cache disk... so, fingers crossed this fixes the mess I am in :)

Thanks

27 minutes ago, SliMat said:

I am currently manually using Midnight Commander to copy any files which needed by dockers and are still on /mnt/cache/appdata... to mnt/user/appdata/

Do NOT do this - it is likely to result in data loss as you are mixing a User Share and a physical device in the same command which can result in files being truncated to 0 size. If you had used something like the Dynamix File Manager that is built into Unraid to do the copy it would not allow this combination of source/target. In this case you need the target to be another physical device such as a specific data drive (e.g. /mnt/disk3/appdata)

4 minutes ago, itimpi said:

Do NOT do this - it is likely to result in data loss as you are mixing a User Share and a physical device in the same command which can result in files being truncated to 0 size. If you had used something like the Dynamix File Manager that is built into Unraid to do the copy it would not allow this combination of source/target. In this case you need the target to be another physical device such as a specific data drive (e.g. /mnt/disk3/appdata)

Thanks @itimpi - I realised this once I started, so have changed to copying to /mnt/diskX/appdata... to avoid this

19 minutes ago, itimpi said:

In this case you need the target to be another physical device such as a specific data drive (e.g. /mnt/disk3/appdata)

One thing which I have just considered... what happens if I copy /mnt/cache/appdata/someapp/file1.abc to /mnt/disk3/appdata/someapp/file1.abc but there is already /mnt/disk1/appdata/someapp/file1.abc ?? How will UnRAID view this? Obviously as my appdata share is spread across multiple disks without checking EVERY file individually it is possible to have the same file in existence on two different physical disks, but in the same share??

Obviously its not practical to check for every file on every disk that /mnt/user/appdata/someapp/ is located on :(

Edited October 8, 2025Oct 8 by SliMat

I am not familiar with Dynamix File Manager - but if this is built in, can I use it for the remaining files as I have only moved Radarr & it seems to be working OK... everything else is still located in /mnt/cache/appdata/... at the moment.

Just looking to see where in UnRAID it is!

Does this look the correct way to do this, I haven't started it till I know its correct...

46 minutes ago, SliMat said:

One thing which I have just considered... what happens if I copy /mnt/cache/appdata/someapp/file1.abc to /mnt/disk3/appdata/someapp/file1.abc but there is already /mnt/disk1/appdata/someapp/file1.abc ?? How will UnRAID view this? Obviously as my appdata share is spread across multiple disks without checking EVERY file individually it is possible to have the same file in existence on two different physical disks, but in the same share??

Yes - you can get duplicate files. Unraid will show the first one it finds which can lead to confusing results as if for instance you delete one it promptly reappears as the other copy now gets uncovered.

Using Mover to handle the move avoids duplicates but can be significantly slower particularily if there are a lot of small files.

47 minutes ago, itimpi said:

Using Mover to handle the move avoids duplicates but can be significantly slower particularily if there are a lot of small files.

Is the screenshot I showed above the correct way to move to avoid duplicates?

56 minutes ago, SliMat said:

Is the screenshot I showed above the correct way to move to avoid duplicates?

Not necessarily. In theory files should not exist on other drives so you do not end up with duplicates. However if by any chance they already exist on other drives then you end up with a duplicate.