trurl

That shows container: /incomplete-downloads is mapped to host: /mnt/user/Downloads/SAB/incomplete and container: /downloads is mapped to host: /mnt/user/Downloads/SAB/Completed So, SAB downloads to SAB/incomplete subfolder of the Downloads user share and moves the completed downloads to SAB/Completed subfolder of the Downloads user share. Nothing about SAB moving anything to any user share except Downloads. Do you have any 'arrs that might be involved?

Have you done memtest yet? You must never attempt to run any computer unless memory is working perfectly. Everything goes through RAM. The OS and other executable code. Your DATA! EVERYTHING! The CPU can't do anything with anything until it is loaded into RAM.

What are you using to transfer the file?

successfully transfer a file delete the file successfully transfer it again At which of those 3 steps did it fail?

Because it doesn't seem like you know how it works.

I would be more confident if you would

That's possible, but whether it would actually work like that would depend entirely on your mappings. If /incomplete-downloads was mapped to /mnt/user/Downloads, and /downloads was mapped to /mnt/user/Mediastorage, then when SAB moves the incompletes to completed, they will go from /mnt/user/Downloads to /mnt/user/Mediastorage.

Post docker run for SAB

I'm not talking about any settings within the SAB application. I am talking about the mappings where you setup how the container /downloads path is mapped to the host.

It does. Without Secondary storage, there is no Mover action.

If you have SAB configured with a mapping to /mnt/cache/Downloads, it will see only cache. If you have SAB configured with a mapping to /mnt/user/Downloads, then it is going to see the whole user share, cache + array.

Downloads share in those diagnostics is configured to move to array, so array is included. Did you have it cache-only before? Also, Downloads share has some files on disk18, so making it cache-only now won't get anything moved off the array.

Just a nit to pick in your README webpages typically don't have a right-click action, and Unraid webUI doesn't. right-click is under the control of the browser, not the page. I assume you mean the popup you get from left-clicking a container icon.

Since you were able to repair emulated disk1, that is exactly what rebuild would give you. But we don't know how successful that repair really was since we haven't seen your filesystems since that repair. When you are ready, start the array in normal (not maintenance) mode with nothing assigned as disk1, and post new diagnostics.

Is media a public share?

appdata, domains, system have all files on cache. Not a lot of difference between freespace of /mnt/user0 (array) and freespace of /mnt/user (all user shares). 120G free on cache is sort of a rounding error when compared with 25T total free. Do you have anything specific that would show what you mean?

That is just one of the shares I mentioned. And arguably not as important as system share. Attach Diagnostics ZIP to your NEXT post in this thread.

There are several possible ways to proceed, depending on test results and other things we might do to get more information about possible ways to proceed. For example, what more can we learn about the contents of repaired emulated disk1? Can we find out anything about the contents of physical disk1? Maybe try different approaches and see which give best results. Do you have backups of anything important and irreplaceable?

Just delete the trial key and then you don't have to worry about it.

What is taking up the space? Do you already have your Docker/VM related shares - appdata, domains, system - all on your existing cache mirror? Make the 2TB another pool, maybe call it download. I have 2 pools. 2x256G nvme "fast" pool for Docker/VM related shares, they aren't moved. 2x1TB nvme "cache" pool for caching user share writes.

You should check for lost+found folder at the top of disk1, to see what repair had to put there.

It's not technically valid, since it missed at least one write, the write that disabled it. If there were additional writes to the array after that, those are also out-of-sync. Just rebuild it. https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

Not necessarily related, but your system share is all over the array. It is the most important share to have on a pool outside the array, like your appdata is. Why do you have 100G docker.img? We can work on those things after you have good RAM.

Your syslog has btrfs csum errors on cache. This is almost certainly bad RAM. Don't use your server any further until you have tested and fixed RAM.

That doesn't look bad. What about disk5?