JorgeB

Multiple apps segfaulting like that suggests to me that there's still an hardware issue, if it's not RAM it could be a board or CPU issue.

Post new diags, notifications are known to sometimes be wrong.

Yes.

Alternatively you can contact support so that they can extend your trial.

The flies in the diags are all blanc, you may have flash drive issues, post the output of: df -f

Could be 3.3v SATA issue:

Filesystem went read-only, this suggests that it still has other issues, rebooting should make it read/write again, then suggest backing up and re-creating the filesystem to make sure it doesn't happen again.

If you added a new parity device you must do a parity sync first.

You can still use macvlan if you need it, but in that case need to disable bridging, see the 6.12.4 release notes for more info.

Yes, you could boot of the USB drive when you want to use Unraid, and leave the device where the other OS is installed unassigned, and Unraid won't touch it.

Unraid requires that all devices have a unique serial number, the OOS2000G devices both have the same serial, so you only be able to use one at a time with Unraid.

Apr 18 20:57:30 VALIS kernel: sd 1:0:6:0: [sdi] tag#2963 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s Apr 18 20:57:30 VALIS kernel: sd 1:0:6:0: [sdi] tag#2963 Sense Key : 0x2 [current] Apr 18 20:57:30 VALIS kernel: sd 1:0:6:0: [sdi] tag#2963 ASC=0x4 ASCQ=0x0 Apr 18 20:57:30 VALIS kernel: sd 1:0:6:0: [sdi] tag#2963 CDB: opcode=0x88 88 00 00 00 00 00 22 e3 fa b8 00 00 03 f8 00 00 Apr 18 20:57:30 VALIS kernel: I/O error, dev sdi, sector 585366200 op 0x0:(READ) flags 0x0 phys_seg 127 prio class 2 This part specifically, it's not logged as a disk problem, it's also not logged on the disk SMART report, and the attributes look OK, so both point to not being a disk problem.

Errors with the docker image, try recreating it: https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file Also see below if you have any custom docker networks: https://docs.unraid.net/unraid-os/manual/docker-management/#docker-custom-networks If there are more issues after that, reboot first to clear the logs, since there's a lot of spam, and post new diags after array start.

Unfortunately there's nothing relevant logged, this usually points to a hardware issue, one thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

Not sure what caused it, but the pool cfg file was not showing the correct config, probably it came from earlier.

Diags show errors with disk7, don't see any with parity, disk7 errors look more like a power connection problem, replace cables (also do it for parity) and run a parity check.

Try this: https://forums.unraid.net/topic/123369-ssh-errors-operation-not-permitted-when-attempting-to-ssh-into-another-unraid-server/?do=findComment&comment=1126266

Please post the diagnostics.

Try using an exclusive share (or disk share), both will bypass FUSE, which is known to impact performance a lot with small files.

If the disks are not detected in the BIOS they also won't be detected by Unraid, swap both cables from a non working disk and see if it's detected.

Apr 19 16:18:52 iPlex kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Apr 19 16:18:52 iPlex kernel: ? _raw_spin_unlock+0x14/0x29 Apr 19 16:18:52 iPlex kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan] Macvlan call traces 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 19 08:19:57 TUX kernel: nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10 Apr 19 08:19:57 TUX kernel: nvme nvme0: Does your device have a faulty power saving mode enabled? Apr 19 08:19:57 TUX kernel: nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off" and report a bug NVMe device dropped offline, try adding those options to syslinu.cfg

You can use for example rsync over SSH.

Looks like the OOM is being causes by Prowlarr, it was using a lot of RAM, I assume the RAM usage is already limited for that container?

Does the disk mount now? Looks like xfs_repair didn't finish successfully, if it doesn't mount try running it again, also update to v6.12.10 before running.