trurl

If you still have files on cache, it may be because you didn't allow them to be moved before you reconfigured the user shares to not use cache. Diagnostics can let us quit guessing and actually give some advice on how to proceed.

If you were transferring to user shares there shouldn't be duplicates.

User shares includes all array disks, plus all pools, such as cache. So if you are looking at user shares, and also looking at cache, you may be seeing the exact same files instead of duplicates.

Attach Diagnostics ZIP to your NEXT post in this thread.

I think you are using the word "pool" to mean what we normally refer to with Unraid as "the array". "cache" is itself a "pool". Not really clear what you have done. Are you transferring directly to individual disks or cache, instead of transferring to user shares?

Attach Diagnostics ZIP to your NEXT post in this thread.

Try refreshing the page

Ideally, Docker/VM related shares - appdata, domains, system - would have all files on cache or other pool with nothing on the array, so Docker/VM will perform better, and so array disks can spin down since these files are always open. All of these shares currently have files on the array. Disable Docker and VM Manager in Setttings. Set each of these shares to Primary:cache; Secondary:array; Mover action:array->cache Run Mover, wait for it to complete, post new diagnostics.

Unclean shutdown not a likely cause of problems. Can you tell us exactly what problems you are facing now?

Post new Diagnostics

Reinstall from your appdata backup like explained in the post just above yours.

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/data-recovery/#cloning-a-failing-disk

I don't see cache SSD in those diagnostics.

First step is cloning disk5. Maybe even ddrescue since it seems to be failing.

Ideally, Docker/VM related shares - appdata, domains, system - would have all files on cache or other pool with nothing on the array, so Docker/VM will perform better, and so array disks can spin down since these files are always open. If you want more specific advice Attach Diagnostics ZIP to your NEXT post in this thread.

Just configure whatever share you want to use it however you want.

You may have to use power button

Actually making this happen isn't difficult, but is a little more complicated than a normal rebuild, and will require following detailed instructions exactly. Might be better if you could take care of this in person.

If we can emulate disk1 with the disk5 clone in the array, it should give a good idea of how disk1 rebuild will go, since the emulated contents are exactly what will be rebuilt, assuming all goes well.

The drive was disabled when a write to it failed. Unraid does not use the disk after that. That failed write, and any subsequent writes to the disabled disk, are still in the array because parity is updated, and that data is emulated from the parity calculation. Rebuild will recover those writes. If you "trust" the disk instead the array is still out-of-sync since parity and the "trusted" disk don't agree. So then you have to rebuild parity, but you would have lost those emulated writes. In some extreme cases, it might make sense to trust the disk, rebuild parity, and accept the losses. But if you can rebuild, that is the whole point of parity, to recover the data. All your disks are mostly full, so any write to user shares has to choose one of those mostly full disks. If you have Minimum Free for the share set, that will help it choose an appropriate mostly full disk.

Post new diagnostics

Thank you!

SMB also isn't case-sensitive. Which means you wouldn't be able to see both Downloads and downloads shares on the network.

The reason flash isn't case sensitive is because it is FAT. FAT is Windows (actually DOS), which isn't case-sensitive. But it can be created and worked with natively on most OS.