JorgeB

If no valid backup superblock is found after a few minutes it usually means one won't be found, best bet is to restore from a backup if available or use something like UFS explorer to see if it can recover the data.

Try this:
https://forums.unraid.net/topic/118286-nvme-drives-throwing-errors-filling-logs-instantly-how-to-resolve/?do=findComment&comment=1165009
 

First thing to do is to change from macvlan to ipvlan, then reboot, if more issue post new diags after the problem, there are also some ATA errors.

You can make a feature request but doesn't look to me like an easy thing to implement.

With such low RAM assigned to the ARC not sure you really benefit form an L2ARC, but you can add one, instructions here:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=1256329
 

You pool has a cache vdev, so that device needs to be assigned with the rest of the pool:
 
export the pool first
create a new pool with 6 slots
assign the disks first then the NVMe device in the last slot
leave the pool filesystem set to auto
start array

Try changing to IPv4 only.

Should be, but good idea to read the release notes for the major releases, v6.9.0, v6.10.0, etc.
 
Don't think that's necessary, some of my flash drives are over 15 years old by now, just make a backup before upgrading.

Diags are after rebooting so we can't see what happened, but SMART looks fine so you can rebuild on top, probably a good idea to replace cables before doing it to rule that out.

Looks like there's something creating this mountpoint:
Aug  3 21:30:50 ultramagnus emhttpd: error: malloc_share_locations, 7193: Operation not supported (95): getxattr: /mnt/user/users_kelvin  
Do you know where this is coming from? You cannot have anything external to mounting under /mnt/user
 
 

There are macvlan call traces, those are know to make a server crash, try switching to ipvlan (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)).

System share as some files on disk1, move everything to cache, isos share too if in use.

It's not logged as a disk problem, looks more like a power/connection issue, if it's been happening to multiple disks see if they have something in common, could also be the PSU.

You can use preclear.

Jul 20 08:57:47 UnicornBarfNUC kernel: pcieport 0000:00:1b.0: AER: Uncorrected (Fatal) error received: 0000:02:00.0 Jul 20 08:57:47 UnicornBarfNUC kernel: pcieport 0000:02:00.0: AER: PCIe Bus Error: severity=Uncorrected (Fatal), type=Inaccessible, (Unregistered Agent ID) Jul 20 08:57:47 UnicornBarfNUC kernel: thunderbolt 0000:04:00.0: AER: can't recover (no error_detected callback) Jul 20 08:57:47 UnicornBarfNUC kernel: xhci_hcd 0000:38:00.0: AER: can't recover (no error_detected callback) Jul 20 08:57:47 UnicornBarfNUC kernel: pcieport 0000:03:00.0: Unable to change power state from D3hot to D0, device inaccessible Jul 20 08:57:47 UnicornBarfNUC kernel: pcieport 0000:00:1b.0: AER: Root Port link has been reset (0) Jul 20 08:57:47 UnicornBarfNUC kernel: pcieport 0000:00:1b.0: AER: device recovery failed Jul 20 08:58:17 UnicornBarfNUC kernel: xhci_hcd 0000:38:00.0: xHCI host controller not responding, assume dead Jul 20 08:58:17 UnicornBarfNUC kernel: xhci_hcd 0000:38:00.0: HC died; cleaning up Jul 20 08:58:17 UnicornBarfNUC kernel: usb 4-2: USB disconnect, device number 2 Jul 20 08:58:17 UnicornBarfNUC kernel: usb 4-2.3: USB disconnect, device number 3 Jul 20 08:58:17 UnicornBarfNUC kernel: usb 4-2.3.1: USB disconnect, device number 4  
We don't recommend using USB for array or pool drives, they are prone to disconnects and bad at errors handling in general, and they are the source of your issues.

Docker image is corrupt, delete and re-create.

Pool is in the middle of a balance and it's crashing because the fs is corrupt, see if you can copy the data as is, if not see here for some recovery options, try mounting read-only and then backup the data, then recreate the pool and restore the data.

One of the devices is failing and the pool is raid0 so there's no redundancy, because of the device errors it failed to copy and it went read only, you can reboot and try again, I would recommend copying the data manually, start with the most important stuff, but some data will likely fail to copy.

Yes.

That fact that there's nothing relevant logged and that the server crashes mostly during a parity check suggest more a hardware issue. like for example a weak PSU.

Go to Settings -> VM Manager, stop the service, and make "Libvirt storage location" point to /mnt/user/PBS/system/libvirt/libvirt.img since based on the date that's the more promising one, then restart VM service and see if the VMs are back.

I expect it will always show folder in that view, at least it does for me, with zfs and other filesystem, shares are just top level folders, if you go to Shares they will still all be there.

Disable docker service, reboot, then edit /boot/config/docker.cfg and change DOCKER_IMAGE_SIZE="0" to "5" or another value, as long as it's not 0, then re-start the service.

It was already disabled on boot, so it happened before or on previous shutdown, disk looks OK so you can rebuild on top, probably a good idea to replace/swap cables first to rule that out if it happens again.

Check settings for the parity check plugin (or try uninstalling it to confirm if it's that).