JorgeB

Make sure it's labeld UNRAID, all caps.

Please use the existing support thread for the plugin you are using

I see multipal apps segfaulting, this typically is a hardware issue, RAM or CPU, in this case I would lean more to the CPU, there are some users on their 3rd and 4th CPUs.

It's easier to do it in Windows for example

When using the CLI you must use the correct md device, but if the result above was from the GUI, the filesystem appears to be damaged beyond repair, best bet is to use a file recovery app like UFS explorer, the free trial should show if it can recover the data.

Please post the diagnostics after tryng to create the new boot pool.

Previous diags are full of spam, post new ones please without the DVD drive (after array start)

How are you running xfs_repair? If from the CLI post the command used.

Please start your own threads, enable the syslog server and post that and the diags after it happens, though the symptoms are similar, there may be different causes, and it gets complicated trying to support multiple users in the same thread.

Don't see those erros logged, there is a container running out of RAM, something related to Bambu. Type reboot in the CLI and see if it reboot after 5 minutes, if not you may need to force it.

This would be my main suspect, since it's one of the more affected models by the Intel 13/14 gen issues, lot of users with stability issues with this and similar CPUs, look for a BIOS updatye, it can sometimes help if the CPU is not too far gone.

You need to delete the extra pool cfg, please post the diagnostics to see their names.

I'm not seeing any issues logged, but it looks like the syslog is missing stuff, since it ends with Jun 19 07:35:07 NAS kernel: If it happesn again, confirm the syslog has the last lines, if not try tailing it.

Yep, only the bz* files and changes.txt are updated.

Make sure to copy the complete /config folder.

Flash drive problem, 7.3.x is more strict witht he flash drive partition layout, easiest way to fix is to backup the flash drive, recreate it with the USB tool and 7.3.1, restore only the config folder from the backup.

This is a normal behavior with the MX500, monitoring that attribute should be disabled for them.

Unraid is limited to runinng LTS kernels becuase of ZFS, next LTS kernel shodul be out at then end of this year.

I don't have that, and I have one that already rotated; it's now on the 2nd countdown with 79% life left.

Maybe this: https://forums.unraid.net/topic/199000-docker-containers-with-netcontainerbinhex-delugevpn-not-starting-after-reboot/#findComment-1624462

I see the attempts to restart nginx, but nothing wrong before that. There's a problem with a long file name preventing a move; resolve that or disable the mover logging to stop the log spam, then post a new syslog next time it happens.

Jun 18 03:11:30 UNRAID kernel: nvme nvme0: Abort status: 0x371 Jun 18 03:11:51 UNRAID kernel: nvme nvme0: Device not ready; aborting reset, CSTS=0x1 Jun 18 03:11:51 UNRAID kernel: nvme nvme0: Disabling device after reset failure: -19 NVMe is still dropping offline; if the kernel options don't help, best bet is to use a different brand/model device (or a different board) This is normal when this happens; a power cycle is required to bring the device back, not just a reboot.

There's something creating /mnt/user/appdata before the array is started; this is not supported; /mnt/user is reserved.

See if you can get the syslog: cp /var/log/syslog /boot/syslog.txt

There's a known issue where sometimes you see "errors" for the boot pool after replacing a device; in these cases just restarting the array (or rebooting) will fix it.