JorgeB

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.

Most likely, though it doesn't mean that caused the sync errors, but syslog looks fine now, no more ATA errors.

And the attributes should only show as "failing now" when the threshold is hit (1).

Never seen that issue, and I have several, are you looking at the normalized or RAW value? What matters for these SSDs is the normalized value; that value decreases with usage, and the raw value increases inversely.

You should be able to remove it by hovering the mouse on the top-right corner of that server's card, then clicking "customize"

It already comes with Unraid, at least from 7.3.0, don't remeber when it was added.

Some BIOS, mostly recent AMD board, are incompatible with the stock syslinux bootlader, note that if you create an internal boot problem, it should no longer be an issue, since that uses a different bootloader (Grub)

Try the Limine UEFI bootlader, link above.

If I'm understanding what you are asking correctly, that's not possible; parity drives must be the same size or larger than any individual data drives.

Does it boot with a different PC? It amy also be worth trying with the Limine boot loader, in case the BIOS os not cmpatible with the stock one https://forums.unraid.net/topic/196349-black-screen-after-usb-boot-msi-x870e-carbon-ryzen-9950x-rtx-4070-ti-super/?do=findComment&comment=1607672

Assuming that last option is the flash drive, back it up and then try recreatint it this way: Get the Unraid zip from https://docs.unraid.net/unraid-os/download_list/ - Open Rufus and change "Boot selection" to "Freedos" - Set the "Volume label" to UNRAID - set filesystem to FAT32 - click START - once done, unpack the Unraid ZIP to the flash drive If you are booting UEFI nothing else you need to do, if you are booting legacy/CSM, run the make_bootable.bat as administrator first. If that works, you can then restore the config folder from the previous install.

Does it show the Unraid boot menu or not even that? Also, post a photo of the BIOS boot menu

The upgrade should not change anything regarding that, most likely it was the reboot, and it sounds like a hardware/BIOS problem to me. Unraid never supported Secure Boot

You can try using iotop to see which process are causing the io activity.

Don't see any obvious issues, both the array and nginx are started, did you try in safe mode to rule out a plugin issue? Also, are you trying to access the server by name or IP? If the former try the IP http://192.168.1.25

All storage devices count for licensing purposes, except a boot or licensing only flash drive, internal boot pool counts.

It would be similar; basically, you need to back up that pool, then use the wizard to recreate it as a split boot pool, then restore the data to the data partitions.

There's a lot of data corruption being detected on disks 1 and 3, but looks like you are using ECC RAM? Is disk1 the one you were trying to check/repair? I would start by scrubbing disk1 and disk3 and checking the results.