JorgeB

No, most likely some hardware issues, digas might help.

Please post the diagnostics: Tools -> Diagnostics

NVMe device dropped offline, this can sometimes help: Some NVMe devices have issues with power states on Linux, try this, on the main GUI page click on flash, scroll down to "Syslinux Configuration", make sure it's set to "menu view" (on the top right) and add this to your default boot option, after "append" and before "initrd=/bzroot" nvme_core.default_ps_max_latency_us=0 Reboot and see if it makes a difference, if it doesn't look for a BIOS update and/or try a different brand/model device.

CRC errors don't reset, but if you're getting more it's likely a cable problem, or those disks don't like that controller, you can swap them with the other model you have an test.

Both diags are just after rebooting, you need to grab ones after the problem and before rebooting.

Yes.

Various call traces, including macvlan, those are usually the result of having dockers with a custom IP address:

Some SMR drives report trim support, and so the plugin expects trim to work, possible solution would be to only trim non rotational devices.

Yes, I would like this, and the starting point ideally could be given as a percentage or sector.

Any unclean shutdown since last check? If not run another one.

Swap both cabes/slot with a different disk and see if problem follows the disk.

You should post in the existing support thread:

Jan 2 15:01:59 JJ-NAS kernel: nvme nvme0: controller is down; will reset: CSTS=0x3, PCI_STATUS=0x10 Jan 2 15:02:30 JJ-NAS kernel: nvme nvme0: Device not ready; aborting reset Jan 2 15:02:30 JJ-NAS kernel: nvme nvme0: Removing after probe failure status: -19 It's unlikely to be related to power states, as that's usually mentioned in the log when related, it appears to be dropping abruptly, but can't say if it's a device or board issue.

Start by running memtest.

GUI is not great for monitoring pools, see here for more info.

Log re-starts after a reboot, it it keeps crashing you can try this, it might catch something.

Checksum errors are usually the result of a hardware problem, like bad RAM.

Probably a general support issue, and unfortunately diags after rebooting are not much help, if it happens again try to get them before doing it, if the GUI option doesn't work type "diagnostics" in the console.

Don't really known much about Sabrent, 980 Pro is probably one of the best NVMe devices around, but likely won't notice much performance different, still worth trying the 980 if those continue to drop.

I snapshot them them send/receive to another pool, that's one option, if you're using btrfs.

It works with Unraid as expected, not as much bandwidth as the JMB585 but sufficient for 4 HDDs, time will tell is it's reliable but I would expect to be similar to the 2 port Asmedia, which is fine.

Both devices having issues suggest there's some connection/power problem or they could have a compatibility problem with the controller, hence why I suggested trying the other one.

Unfortunately due to a logged large rsync transfer the syslog is missing when the device dropped, if you reboot/power cycle the server does the device come back online? If yes this sometimes helps with dropping NVMe devices: Some NVMe devices have issues with power states on Linux, try this, on the main GUI page click on flash, scroll down to "Syslinux Configuration", make sure it's set to "menu view" (on the top right) and add this to your default boot option, after "append" and before "initrd=/bzroot" nvme_core.default_ps_max_latency_us=0 Reboot and see if it makes a difference, also make sure BIOS is up to date.

This is strange, try swapping that disk with one of the 2TB disks on the onboard SATA controller.