JorgeB

Type reboot in the CLI, if it doesn't reboot after 5 minutes you will need to force it, then see if it comes back normally.

By default it will create a mirror.

It's logged as a disk error, even if SMART looks good, run another extended test, but even if it passes, if there are any more errors I would consider replacing it.

@Frank1940Since there's some interesting and still relevant info in that thread I've created a copy here:
 
 

Stop the array, click on the pool and set "Enable user share assignment" to Yes.

Emulated disk1 is mounting, if contents look correct you can rebuild on top and sync parity at the same time:
 
https://docs.unraid.net/unraid-os/manual/storage-management#rebuilding-a-drive-onto-itself

It's not logged as a disk problem and SMART looks fine, most likely a power/connection issue.

Device was busy, reboot and try to format again, that should do it.

You can do a new config: Tools - New config - Preserve all
 
Then assign disk3 and check "parity is already valid" before array start, still a good idea to run a parity check after, and if you started the array without disk3 there will be some sync errors.

The filesystem should be fixed now, reboot to clear the logs.
 
Don't recommend using -L unless xfs_repair asks for it.

You can use this:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=511923
 

That suggests the updated was not the problem, it may have just been a coincidence, with all those different apps segfaulting I would start by running memtest.

If the SMART test passed the disk is OK for now, you can click on the thumbs down to acknowledge the current errors, it will then only change if more appear.
 
 
 

The XML is missing from the diags, but looks like the SATA controller (and a USB controller) are bound to the opensense VM, so Unraid lost connection with all disks when it tried to start..

The NIC is detecting a link change/drop:
 
 
Try a different NIC if possible.

Check filesystem on the unmountable disks, run it without -n

Since parity is invalid it won't be able to emulated the disabled disk, if you think disk3 is healthy, and the rebuild was being done on the old disk, you can do a new config to re-enable that disk and then re-sync parity, but note that any data written to that disk after it got disabled would be lost.
 
 

Make sure this has been taken care of:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173
 
But the server rebooting on its own usually means a more serious hardware issue.

If the docker image is the only corrupt file you can recreate it:
 
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
Also see below if you have any custom docker networks:
https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks
 
Then run another scrub to confirm no more errors.

AFAIK nothing changed with that, you should still have 30 days initially plus two 14 day extensions.

Check/replace cables for disks 13 and 14, also a good idea to run a SMART long test on 13 at least, 14 is not giving a full SMART report.

There are constant disk errors for both, try connecting them to the onboard SATA controller instead.

Docker image is corrupt, delete and re-create:
 
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
Also see below if you have any custom docker networks:
https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks

Server rebooting on its own is almost always a hardware issue, but can be caused by different components, start by running memtest, but note that memtest is only definitive if it finds errors, if you have multiple sticks you can also try with just one, if the same try with a different one, that will basically rule out bad RAM, next suspects after that would be PSU, board, CPU.

If you can return that one I would try using a controller with a different chip, like a JMB585, in case it's some compatibility issue with your board.