JorgeB

Check if there are multiple apps still segfaulting, if yes, that's not normal

The pool has some single profile chunks, see if you can convert all to raid1: If you can still start the array with the old device, assign it back; if not, reimport the pool with sdc and sdb on main click on the first device for that pool and then "remove pool" back on main, create a new pool with the same name and 2 slots assign the two existing pool devices; leave the filesystem set to auto start the array to import the pool Then click the first pool device and balance the pool to RAID1. Post new diags when done or if there are errors during the balance.

Cache cfg is in single mode, post the output from btrfs fi show

Yep, you are using the btrfs native driver with a folder, hence my suggestion to try with an XFS docker image

Wasn't this when connecting to the server?

You don't need to change anything. If the server has TPM 2.0, and is enabled, you have the option to transfer the license to it.

If the contents from the actual disk look better than the emulated disk, instead of rebuilding, you can do a new config and re-sync parity: -Tools -> New Config -> Preserve current assignments: All -> Apply Then go to main, reassign disk1, make sure all the other assignments are correct, check "parity is already valid," start the array, and run a correcting parity check; some sync errors are expected.

This appears to be related to the Docker engine upgrade, but it only affects a very small number of users, and AFAIK, the issue was resolved for all after changing the Docker storage driver.

It should still work after rebooting, but any issues you can downgrade in Tools - Downgrade OS.

Try recreating the Docker folder as a Docker image, and with a different storage driver, XFS https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#re-creating-the-docker-image-file Then: https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#reinstalling-docker-applications Also see below if you have any custom docker networks: https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#restoring-docker-custom-networks

May 21 16:03:41 MEDIA-SERVER rc.samba: Samba server daemon... Started. May 21 16:37:44 MEDIA-SERVER shutdown[404305]: shutting down for system reboot I assume this is one of the times? If yes, there's nothing logged on the Unraid side, suggesting it's an external issue.

Weren't you able to access the server in the screenshot before that?

7.2.7 is mostly for users who don't have a license that allows updating to 7.3. Anyone on 7.3.0 should wait for 7.3.1, which should be out very soon.

I thought you meant the normal shares. Can you access the other data on disk1, the one outside lost+found? Lost+found are lost files that xfs_reapir could not correctly fix.

Looks more like a different tissue, not network related, possibly even hardware, but enable the syslog server, set it to save the persistent syslog to a share, and post that after the next time it happens.

Static is typically more reliable; post the diagnostics or persistent syslog after you lose access.

That suggests there's still a filesystem issue, reboot, try accessing via shares again, and post new diags.

If it's just with a specific container, look for its support thread, in case it's a config issue with it or a known issue

Hardware is fine, could be a problem with the client NIC (or its driver or the OS), cables, etc.

Would be very surprised, considering there are multiple unrelated apps crashing, but you can try downgrading and retesting.

I see an i5 13600K, this would be my main suspect, lots of users with this and similar CPUs have stability issues due to the Intel 13/14 gen issues; some users are on the 3rd and 4th CPUs.

Check the emulated disk contents, and the lost+found folder like trurl mentioned, and if you are happy with the contents, you can rebuild: https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

Scrub the pool and post the output from the GUI

The used/free on main will be correct, cpacity is incorrectly reported in this case, this is a btrfs issue.

There's a controller with SATA port multipliers; these are not working correctly with the latest kernels, and they are never recommended anyway. Recommend replacing it Recommended controllers for Unraid - Storage Devices and Controllers - Unraid