trurl

Did you disable the Docker and VM Services? Not the individual dockers and VMs but the services in Settings - Docker and Settings - VM Manager

yes

See the Unraid FAQ pinned near the top of this same subforum for Ryzen tweaks.

If you are absolutely sure about parity then it doesn't matter. The way you can lose data in this situation is by assigning a data disk to the parity slot. Please keep your Flash backup current!

appdata, domains, and system are normally kept on cache so your docker and VM performance won't be impacted by the slower parity writes on the array, and so your dockers and VMs won't keep array disks spinning. Of these 3 shares, I would say system is the most important to keep on cache, because it is always in use if you have Docker and/or VM Services enabled. You will have to disable Docker and VM Services since Mover can't move open files, then set system share to cache-prefer and run Mover to get it moved to cache where it belongs. You can check how much of which disks each of your Shares are using by using the Compute All button on the Shares page.

Why is your system share on disk1?

Seems like your problems aren't limited to this docker. You should start a new thread in General Support with your Diagnostics.

That looks fine. Looks like disk3, disk5, and cache are all corrupt. Syslogs are pretty full and dense with these so I may have overlooked others. Also hard resets on ata12 but I can't tell what disk that is since those syslogs have rotated and the initial disk assignments are not included. Have you done memtest recently?

Perhaps you don't need this answer anymore but here it is anyway. No. It doesn't matter if the drive is empty or not. Parity doesn't know or care about files or filesystems. It is going to rebuild the entire disk bit for bit.

Probably not even the same version of Unraid. You will have to give a lot more information if you want help.

You have filesystem corruption on disk3, possibly others but that is mostly what I see in syslog. Looks like some connection or controller issues as well. You have a lot of disks so I haven't looked at SMART for all of them. Do any of them have SMART warnings on the Dashboard?

Not likely This may have invalidated parity

👍

Not related to your issue but your appdata share has files on the array. I don't know if this is intentional or not. Those CRC errors aren't something to be shrugged off. While it's true that they are not indicative of drive issues, if they keep occurring then you have a problem you need to fix. Possibly a problem that is at the root of some of your problems. For example, your syslog has hard resets on ata9 and ata10. These are disk4 and parity1 Your other issues with CA and docker updates seem like network issues.

So it does, I hadn't noticed.

Yes, even with more "standard" rebuilding situations, if you can rebuild to another disk then you will have the original if there are problems during rebuild. Assuming all other drives are OK the most frequent cause of a rebuild problem is disturbed connections during replacement.

Possibly other things will be different than just the identifier so it may not be in sync with parity. Rebuild it.

Tools - New Config will let you assign disks however you want and optionally (by default) rebuild parity. Keep all assignments then unassign that disk and start the array. You must let it rebuild parity since an empty disk is not a clear disk as you have learned, so parity will not be valid without that disk until it is rebuilt.

Doesn't sound much like the OP. If you want help you should start your own thread and post your diagnostics.

Even if the disk passed preclear and SMART is good I wouldn't use it as a permanent member of the array. You should only install as many disks as you need for capacity. Each additional disk is an additional point of failure. That disk doesn't have enough capacity to waste an extra slot and extra port on.

OK temporarily for testing and for experimenting, but not OK for storing data which isn't important. Every disk in the array is important regardless of what data is on it. In order to reliably rebuild every bit of a disk, every bit of parity PLUS every bit of ALL other disks must be reliably read. So even if you don't care about the data on a disk, it is still important to the redundancy of your array.

This particular fix is easily found in the Docker FAQ:

Do you mean you are putting this tiny (and I assume very old) drive in your array? Why?

Could you explain this better? Where were you seeing this 502, and where were you seeing the webgui was up? And where did you see anything about restarting emhttp? Restarting emhttp isn't the usual fix for anything. From your syslog it looks to me more like you were having a network issue of some kind. After your multiple failed attempts at restarting emhttp I think you should just reboot.

Searching docker hub for "expect" turns up a lot of result, and some look relevant.