JorgeB

The diagnostics show two separate problems. Samba was still trying to access the old Time Machine share, but its directory under /mnt/user no longer existed. This caused the repeated “No such file or directory” errors. The replacement share exists and appears to be configured correctly. However, the diagnostics were collected before the Mac tried to use it, so they do not show the new failure. Remove the old destination from Time Machine and disconnect the old SMB mount. Then connect to the replacement share and select it again. Confirm that Finder can create and delete a small test file on the share before starting another backup. If it still fails, please provide: - The exact macOS version - The complete Time Machine error - The approximate time of the attempt - New diagnostics collected immediately afterward There is also a separate issue. The cache NVMe is repeatedly reporting critical medium read errors at one fixed location. SMART still reports PASSED, but the drive has recorded a media error. Copy any unique cache data to another device before running a scrub or stress test. I recommend replacing that NVMe. The replacement Time Machine share is stored on disk1, so the NVMe is not currently in its data path.

The diagnostics point to the CPU mode. Every captured Windows attempt uses Emulated (QEMU64). The current test uses a Windows 11 25H2 ISO. qemu64 exposes a limited, older CPU feature set, although your physical Ryzen CPU supports the instructions required by current Windows versions. Stop the VM and change only CPU Mode to Host Passthrough. Keep Q35-9.2, OVMF TPM, the virtual disk, and the same Microsoft ISO unchanged. Then start the VM and press a key at the optical-media prompt. If setup still resets with Host Passthrough, please post new diagnostics collected after that attempt and before Force Stop.

Please post the diagnostics.

Please post the diagnostics.

The diags you posted don't match the screenshot; the cache pool has a single NVMe device. Which one is it?

You should, pool went read only due to filesystem corruption: Sep 6 20:21:16 Selje-Tower kernel: BTRFS critical (device nvme1n1p1 state EA): unable to find ref byte nr 7848738816 parent 0 root 5 owner 2407754 offset 7323648 slot 150 Sep 6 20:21:16 Selje-Tower kernel: BTRFS error (device nvme1n1p1 state EA): failed to run delayed ref for logical 7848738816 num_bytes 8192 type 178 action 2 ref_mod 1: -2 Sep 6 20:21:16 Selje-Tower kernel: BTRFS: error (device nvme1n1p1 state EA) in btrfs_run_delayed_refs:2161: errno=-2 No such entry

Please post the diagnostics after it happens

Let's start with libvirt, the hdd pool is not mounting, so the isos system shgare cannot be create, either resolve the pool issue or set another strgae for the isos share, then post new diags. P.S. zfs is detecting data corruption; recommend running memtest

The likely culprit from the process list appears to be pinepods_backen — ~6.7 GiB used, is its memory usage expected to reach ~7 GB?

Before running the wizard, remove the old boot pool. Click on it and "remove pool." The license will be kept; it's in the config folder.

I would recommend creating a kernel/driver bug report, the HBA is failing to initialize. Nothing much LT can do about that: Jun 2 06:30:49 UnRAID kernel: mpt3sas_cm0: sending port enable !! Jun 2 06:30:49 UnRAID kernel: mpt3sas_cm0: port enable: FAILED with timeout (timeout=300s)

It's possible that the port is going bad.

You should create a report here for any CA apps related issue: https://product.unraid.net/b/community-apps-submission-support

Sounds more like an ISO issue to me, but please post the diagnostics after this happens

It seems very unlikely to me that the server crashes are related to SATA controllers; if there were issues with those, I would expect to see them logged on the syslog, in the form of ATA errors, timeouts, or similar, but if you have a way to retest without them, it may still be worth doing, but would not be my first concern.

You can boot again from a flash drive, after copying the current config, then remove the pool and run the wizard once more to recreate it as a split boot pool.

Start trial should resume your trial if it's still valid, but you can also contact support to verify.

Please post the diagnostics.

Thanks for all your contributions over the years, best of luck for the future!

This recurrence is significant because the system again reports: an uncorrected error caused a data fabric sync flood event It also repeats the same Bank 5 status and other machine-check fields as the earlier crash. This time it was reported by CPU 8/APIC 5 instead of CPU 6/APIC 1. This strongly supports a hardware/platform stability problem and makes a plugin or container the less likely root cause. It does not conclusively prove that the CPU itself is defective, since RAM/IMC instability, motherboard or VRM issues, BIOS settings, and PSU/power instability can all result in a CPU-reported machine check. Safe Mode is still a useful control, but I would not limit the next testing to Safe Mode alone. Recommend first confirming that the BIOS is at defaults, with A-XMP/XMP, PBO, Curve Optimizer, overclocking, undervolting, and manual CPU/RAM voltages disabled, and that the RAM is running at JEDEC speed. Since all four DIMM slots are populated, the most useful hardware test would be to run with one matched pair only in the motherboard-recommended A2/B2 slots. Because the latest failure took approximately six days, the test should run for longer than that before being considered stable. An overnight Memtest pass does not rule out runtime memory-controller or platform instability. If it freezes again with two DIMMs at stock settings, the next steps would be to test with the other two, or use a known-good PSU/power path and then, if possible, testing with a compatible known-good CPU. The motherboard would remain another possibility. You can also test Safe Mode with Docker and VM Manager disabled, and a test on 7.3.2 would remove the beta release as another variable. Ideally, change one variable at a time. Also you shoudl keep the remote syslog enabled and post fresh diagnostics immediately after any further reboot.

You should be able to continue the trial with the same device, but cannot continue the existing configuration, this is a trial limitation; you can keep the data if you assign all the devices as they were. If you are not sure of the assignments, we can help with that.

There are constant ATA errors with disk1, this is typically a power/connection issue. Replace both cables for that disk and post new diags after array start

Stop array, unassign one of the boot pool devices, start array You may then need to change the BIOS boot order depending on which device you remove.

Since guest-ping succeeds, Windows has booted far enough for the Guest Agent to respond. This is therefore not a complete VM hang, despite the missing console. The diagnostics also show QEMU still running and its VNC WebSocket listening. In the previous failure, the nginx-to-QEMU VNC connection was established, so this looks more like the emulated display/framebuffer failing after reboot than a noVNC connection problem. All the VM definitions in your diagnostics use QXL video. As a test, cleanly shut down one VM, change only VNC Video Driver from QXL to VirtIO, then try several restarts. Don’t change the machine type, storage, or network configuration during that test. If it fails again, tell us whether noVNC shows a connection error, a black screen, or a frozen image, and also run: virsh qemu-monitor-command --hmp "<VM name>" "info vnc" virsh qemu-agent-command "<VM name>" '{"execute":"guest-get-osinfo"}' virsh qemu-agent-command "<VM name>" '{"execute":"guest-get-time"}' virsh qemu-agent-command "<VM name>" '{"execute":"guest-network-get-interfaces"}' While the Guest Agent remains responsive, you should also be able to avoid Force Stop by shutting the VM down cleanly with: virsh shutdown "<VM name>" --mode agent The unsuccessful ping/RDP test was from before Guest Tools were installed, so we still need to establish whether networking is working during the current agent-responsive failure.

Please use the existing NVIDIA driver plugin support thread.