trurl

Which plex docker are your using?

https://wiki.unraid.net/Manual/Troubleshooting#Capturing_Diagnostic_Information

Start the array and post new diagnostics

USB not recommended for array or pool disks for several reasons. Port multipliers will impact performance on multidisk operations such as parity check and rebuilds.

Mover won't move duplicates (file already exists at destination), and nothing can move open files.

Can you see the drives in BIOS?

Have you tried booting in SAFE mode?

The page you linked says: which is not what you did. You set them to cache=yes

Also noticed in syslog that you have CA Backup configured to backup /mnt/cache/appdata. But your appdata setting has moved some of appdata to the array so those won't be included in the backup.

Why do you have appdata, domains, system shares set to be moved to the array? If these are on the array, dockers/VMs won't perform as well due to slower parity array, and they will keep array disks spunup since they always have open files.

I seem to recall there might be a bug if you have an empty pool, such as cache, and then another pool after that.

The most common way to lose data is probably user error. And, of course, parity won't help with that either.

Haven't looked at diagnostics yet. My guess is there was never anything wrong with the original disk or this one. Bad connections or controller issues are much more common than bad disks.

Why did you remove cache? I thought the idea was to add another pool for docker/VM. If you only want one pool it might as well be "cache".

It's difficult to make much sense of the shares folder in your diagnostics, because you have a lot of .cfg files that probably don't correspond to any user share. Perhaps you accidentally created some of those shares at some time. Plus, since it appears that user shares are broken, many if not all of them say they don't exist. I haven't checked them all since there are 149 of them. Take a look at the config/shares folder on your flash drive and you will see what I mean. Another thing I noticed is that you seem to be sharing disks on the network. I don't recommend that and it is usually not necessary, though it might be useful for some things if you don't know how to work with files directly on the server instead of over the network. Just be sure you know not to work with disk and user shares at the same time.

https://wiki.unraid.net/Manual/Storage_Management#Parity_Swap

I wouldn't have chosen that name since the word already has a meaning in Unraid, but maybe it will be OK. Your user shares seem broken, no /mnt/user0. Post a screenshot of the User Shares page.

Parity swap copies parity to the new larger disk, then rebuilds the disabled data disk to the old parity disk. After that rebuild completes it won't be disabled anymore, but you could replace it and rebuild to that other new disk if you want.

Syslog is in RAM just like the rest of the OS. You can setup syslog server to get those stored somewhere. Those do look like disk problems though maybe not critical. Since the disk is so old I would consider replacing it.

That seems right but I have never done it. @JorgeB may not be available for several hours if you want to wait.

Actually I do have parity and cache in my backup server. But they are not required by Unraid so nothing preventing you from not having them.

assuming the controller is giving that information correctly. That is one of the reasons RAID controllers and USB connections aren't recommended. Looks like your hardware is good for that.

You can't upgrade disk3 to 4TB until you have a parity disk at least that large. You can't upgrade parity when you already have a disabled data disk. This is exactly the situation the parity swap procedure was designed for.

yes