trurl

Have you done memtest recently?

Can you get diagnostics from command line? What do you get from command line with this? df -h /

Does everyone experiencing these problems have extremely large media libraries? Maybe something is running out of memory.

Was anyone or anything accessing your server while you were away? Do you know whether or not disk3 was already disabled before you left? Setup Notifications to alert you by email or other agent as soon as a problem is detected. Don't let one unnoticed problem become multiple problems and data loss.

Attach Diagnostics ZIP to your NEXT post in this thread.

So do you mean you don't have any backups? You must always have another copy of anything important and irreplaceable no matter which system you use. I guess we could New Config disk3 back into the array and see if it will allow disk1 emulation, something we have done many times. It will require following several steps exactly so wait for those instructions. Since disk3 SMART is so bad it might be better to clone it first with ddrescue. You need a spare disk at least as large as disk1, but not larger than parity. And if we are going to clone disk3 first, you also need a spare disk at least as large as disk3, but not larger than parity.

Just a reminder for @vedadechiee and many other recent posters to this thread. If you have an actual problem to report about the Fix Common Problems plugin itself, this is the correct thread. If instead, Fix Common Problems is telling you about a problem you need to fix, you should post a new thread in General Support with the problem FCP is telling you about along with your diagnostics. Before posting to any existing docker or plugin support thread, it is always a good idea to at least read the first post in the thread:

There needs to be separate SAS/SATA connections for each drive. There are things like that but it would probably be cheaper to just give up on your mini PC idea and build a NAS with the motherboard and drives in the same case.

Did you rebuild after you made that change? Parity will remain disabled until it is successfully rebuilt.

If you rebuild an unmountable filesystem the result will be an unmountable filesystem. Check filesystem on disk5 from the webUI and post the output.

Like the rest of the OS files, logs are kept in RAM unless you setup a place for them to be stored. They can be accessed from the webUI but are lost on reboot since they are in RAM. Since there is no "default" storage for all configurations, the user has to specify where they should go.

Ideally no more than 4 disks per PSU cable.

I never do rebuild in Maintenance mode. It does have the advantage of not allowing access during rebuild, but that is also a disadvantage since a small amount of access won't make much difference and rebuild will still be valid. More importantly, you can't tell if any disks are unmountable in Maintenance mode.

USB NOT recommended for assigned disks for many reasons.

Can you boot a different flash drive with memtest86.com on it?

Let memtest run for several hours

Setup Syslog Server

Main - Array Operation

Did you let it completely rebuild the whole 8TB when you did this?

Go to the Docker page and check the UPTIME column of each of your containers and see which have short uptime.

Do you have an attached monitor and keyboard?

Since you have dual parity you can rebuild both at once. https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

Sorry, you are correct about the previous and now. I misread the diagnostics. Or did you perhaps New Config at some point? Any data written to the disk(s) while they were emulated would be lost with New Config.

Don't see any lost+found in user shares. Fortunately the disks needing repair had plenty of free space for repair to work in. A few of your disks are very full and repair might not have been as successful with those. Unrelated, your domains and system shares are on the array. Ideally, Docker/VM related shares - appdata, domains, system - would have all files on a 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. Both of those shares are configured to put new files on cache_ssd, but those shares existing files on the array will not be moved because they have no Mover action because they have no Secondary. And nothing can move open files. You have to disable Docker and VM Manager in Settings before those shares can be moved.

Currently appdata is all on cache. It is configured to write new files to cache. Don't see any evidence that any data was lost. Same amount of data as in your first diagnostics in this thread. And more data than you had in the diagnostics from your thread in December. Those diagnostics do show some appdata on disk2. https://forums.unraid.net/topic/195930-zfs-pool-unmountable-after-reboot/ domains and system are still on the array. They won't be moved because they have no Mover action because they have no Secondary. And as mentioned, nothing can move open files.