JorgeB

No.
 
No.

Delete/rename /boot/config/network.cfg to go back to default DHCP and reboot.

I think it was because of this:
 
Apr 8 08:53:34 Tower7 root: Creating new GPT entries in memory. Apr 8 08:53:34 Tower7 root: Warning: The kernel is still using the old partition table. Apr 8 08:53:34 Tower7 root: The new table will be used at the next reboot or after you Apr 8 08:53:34 Tower7 root: run partprobe(8) or kpartx(8) Apr 8 08:53:34 Tower7 root: The operation has completed successfully. Apr 8 08:53:34 Tower7 emhttpd: re-reading (sdj) partition table Apr 8 08:53:34 Tower7 emhttpd: error: mkmbr, 2196: Device or resource busy (16): ioctl BLKRRPART: /dev/sdj  
When the disk was initially partitioned it was busy, so possibly because of that it tried again after the resume, I'm just guessing since it's the first time I see this, the second partitioning attempt, not the disk busy issue, that has been happening for some time, hopefully it won't anymore with v6.13, since there were some changes done to try and prevent that.
 
I would be extremely surprised if parity wasn't valid, just re-partitioning the disk should not cause any changes to the parity info, but you can start a check and let it run for a few minutes, if the no errors are found immediately it should all be fine.

There's a macvlan related call trace, these will usually end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), then reboot.

Apr 8 13:36:40 EmbyServer kernel: XFS (md3p1): Corruption detected. Unmount and run xfs_repair Apr 8 13:36:40 EmbyServer kernel: XFS (md3p1): log has mismatched uuid - can't recover  
Check filesystem on that disk, run it without -n and if it asks for -L use it.

If you want to make some tests, your example works for be if the pool is first created with -O normalization=formC -O utf8only=on, e.g.:
 
zpool create -f -o ashift=12 -O normalization=formC -O utf8only=on cache /dev/sdf1  
Unfortunately this cannot be changed later, so the filesystem would need to be recreated manually, also not sure if it would cause other issue, but don't think so.

See here first:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=972660
 

No AMD GPU is being detected by Linux, this is not a software problem, I see only a Nvidia GPU, try re-seating it or using a different PCIe slot.

Still constant errors, swap cables/slots with two other disks and see where the problem follows.

Constant errors with new parity disk, if they are still showing check/replace cables and post new diags.

That looks more like a network issue, you can try using a new flash drive with a stock Unraid install to see if it /config related, if it's the same it's the network, if it works it's /config

I would leave it for now, if it happens again try disabling it.

SMART looks perfect, nothing suggesting it's a disk problem, so power/connection would be the main suspects, the log snippet you posted also doesn't point to a disk problem.

ATA errors followed the disk, and it's still not giving a valid SMART report, so it should be replaced, emulated disk1 is now mounting so you just need to do a standard rebuild with a new disk.

That's an LSI BIOS error, nothing to do with Unraid, you can try disabling of even erasing the LSI BIOS, it's not needed.

Try this:
 
with the array running type
zfs detach cache 8514342029840584511 then stop the array
unassign the cache pool device
start array
stop array
set cache pool slots to 1
re-assign the nvme device
start array
post new diags.

Check filesystem on both disks, run it without -n, and if it asks for -L use it.

Check/replace cables for disks 9 and 13

https://docs.unraid.net/unraid-os/manual/changing-the-flash-device/

Emulated disk is mounting, you have already replaced cables you can rebuild on top.
 
https://docs.unraid.net/unraid-os/manual/storage-management#rebuilding-a-drive-onto-itself

I believe that if the license is not yet active it won't be a problem, your friend should be able to activate it using his email address.
 
 

This was using a lot of RAM:
 
Killed process 3997 (Plex DLNA Serve)   
Make sure you are not transcoding to RAM, or limit its usage.

For the moment, and between the two, I would recommend btrfs for the array, since there's a known performance issue with zfs writes, this does not affect zfs pools.

It's not logged as a disk problem and SMART looks fine, do the disks share anything? Like a power splitter? If not I would swap cables/slots with other disks and see where the problem follows.

Upgrade to 6.12.10