JorgeB

The Unraid driver is crashing; this is an extremely common issue with these 13/14 gen K CPUs when they are failing. I would guess 99% it's a bad CPU.

This has been fixed for 7.4, with 7.3 a single verification error would stop the array, and although I couldn't reproduce, I think it happened if the key was being written at exactly the time of the verification, from 7.4 the array only stops if the key is invalid for more than 30 seconds.

The diagnostics include the requested blocked-task capture and show the same underlying condition as before. A Plex scanner is again blocked waiting for a FUSE request, while Plex, Silo, and ffprobe have additional filesystem reads blocked. Several pgrep processes are also blocked, after which nginx times out waiting for PHP-FPM. There was no Docker auto-update during this boot before the failure, so that does not appear to be a required trigger. The VFS changes may have delayed the recurrence, but they have not resolved the underlying FUSE/media-path stall. The next useful test is still a clean boot with the rclone mount, its nzbdav/Decypharr backend, Plex, Silo, and any other consumers of that mount disabled. Since this occurrence took around 14 hours, recommend leaving it in that state for at least 24 hours. If it remains stable, restore the backend, mount, and consumers one layer at a time.

Unfortunately, there's nothing relevant logged, this can also be a hardware issue, logging stops abruptly after a routine SMART read, and the next boot reports an unclean shutdown. There is no kernel panic, oops, MCE, OOM event, storage error, filesystem error, i915 fault, or network-driver failure before the freeze. One significant issue is that your ASRock B660M Steel Legend is running BIOS 7.03 with an Intel i5-13500. According to ASRock, support for 13th-generation processors was only added in BIOS 8.02, so the current BIOS predates official support for that CPU. Update to the latest stable BIOS, load the BIOS defaults afterward, and initially avoid XMP, overclocking, undervolting, or custom power settings. Then retest with the same Plex and Unmanic workload, if it still freezes: - Run Memtest for at least four complete passes. - Test Plex and Unmanic separately, then together, noting whether hardware acceleration is enabled. - Try booting Unraid in Safe Mode, since several installed plugins are marked incompatible, deprecated, or unknown. - Post new diagnostics generated after the BIOS update.

They are not working correctly; thanks for reporting.

Lost+found folder is created when the filesystem repair cannot correctly fix the paths, you can manually examine the files, and then move them accordingly, but that would have already been visible in the emulated disk.

If you have a backup you can format.

You can always rebuild it to a larger drive, and that should fix the mounting issue, but if UFS explore didn't find anything, I'm not sure there's actual data there.

Yes, for now I would remove all three lines and return to rclone’s defaults: Since you also changed the VFS-cache configuration, returning these settings to their defaults will give us a cleaner test of whether the VFS changes themselves helped. The Docker auto-update timing is another useful observation, but it does not yet prove that the updater caused the stall. For the next test, I would also temporarily disable automatic container updates so that only one variable is being tested. If WebGUI access is lost again, please run: echo w > /proc/sysrq-trigger diagnostics before restarting services or rebooting, and attach the new diagnostics.

Certainly possible, since the drive was minimal and the default Unraid allocation method (high-water) would only use it if the other ones would be basically full.

Unraid doesn't support using whole disks; why didn't you use the GUI to replace it? If you like to use the CLI, you still can, but use a partitioned disk as the new one.

Random reboots are almost always a hardware issue, but enable the syslog server and post that after the next one in case there's something logged.

Do that but a server rebooting by its own is almost always a hardware issue, and there may not be anything relevant logged.

CPU or RAM would be my main suspects for that type of error.

The best bet is to look for the support thread for that container.

Yeah, but when you did the new config with the old disk, it should have kept the original size, so something is missing.

Start here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-819173

You would need to boot from a flash drive, after copying the current config, them remove the pool (you can do that when booting from the flash drive) and recreate it by running the wizard.

There is something significant in the diagnostics. On the boot following one of the freezes, the kernel reports: x86/amd: Previous system reset reason [0x08000800]:an uncorrected error caused a data fabric sync flood event mce: [Hardware Error]: CPU 6: Machine Check: 0 Bank 5:bea0000000000108 This means that at least one of the lockups ended with a CPU-reported uncorrected hardware/platform error. It does not identify the exact defective component, but it points toward the CPU or memory controller, RAM, motherboard/BIOS, or power delivery rather than the JetKVM. The JetKVM USB connection is resetting, but the device successfully reconnects each time, there is no indication that the xHCI host controller itself died, and those events do not occur near either retained freeze boundary. I would treat that as a separate issue for now. Recommend loading BIOS defaults and disable A-XMP/XMP, PBO, Curve Optimizer, any overclocking, undervolting, or manually adjusted CPU/RAM voltages. You can then apply only the required boot/storage settings and the recommended Ryzen idle-power setting. Was the current BIOS installed shortly before these freezes began? If so, that is another important variable. Safe Mode with Docker and VM Manager disabled is still a useful test, but I would perform it with those stock BIOS settings and let it run longer than the normal two-day failure window. If it freezes again or another machine check appears, test with one matched pair of DIMMs at JEDEC speed, followed by a known-good PSU/power path. A passed memtest does not rule out CPU, memory-controller, motherboard, firmware, or load-dependent power problems. Keep remote syslog enabled and, after another freeze, collect diagnostics immediately after reboot, the previous-reset reason and machine-check record may only appear during that following boot.

These diagnostics contain the SysRq output we needed. The command does not display anything in the terminal; it writes the blocked-task information to the syslog. The results show that this is not primarily an nginx or PHP-FPM failure. Before the WebGUI begins timing out, multiple media-related processes are already blocked in filesystem reads. In particular, one Plex thread is waiting in: request_wait_answer __fuse_simple_request fuse_flush Other Plex reads are blocked in the FUSE read path, while the latest capture also contains a find process waiting during ZFS directory traversal. Removing the pgrep section from the hourly script was a useful test. The issue still recurred and blocked pgrep processes remain, confirming that the script line was not the cause. Those processes are getting stuck while inspecting another blocked process, which can then prevent WebGUI PHP requests that inspect the process table from completing. nginx consequently times out while waiting for PHP-FPM. The rclone timeout changes are reasonable as an experiment, although they do not isolate the cause. --contimeout only affects connection establishment, while the other timeouts may not resolve a request already blocked between the local backend, rclone/FUSE, and the backing filesystem. A 10-second I/O timeout may also be fairly aggressive, so please treat it as a test rather than a confirmed fix. The next useful test would be a clean reboot with the rclone mount, the nzbdav/Decypharr backend, and all consumers of that mount, including Plex and Silo, disabled from startup. Observe it for at least the normal recurrence period. If the server remains stable, restore the backend, mount, and consumers one layer at a time. At this point, the evidence points more toward the third-party media/FUSE stack or its interaction with the backing ZFS path. It does not look to me like TTM, FCP, the removed pgrep command, nginx, or PHP-FPM are causing the issues.

The partition size is correct, but XFS is expecting a partition for a 1.5TB disk, not sure how that happened, but it's likely something you did before. I see two main options Rebuild the disk to a new 1.5TB or larger disk, it should then mount use a file recovery app like UFS Explorer; it should be able to recover the data, then reformat the disk.

That is an unrelated bug, it shows for everyone, even when the license can be transferred by the user.

At this point, the results no longer support this being an Unraid 7.3 regression or something that can be resolved by downgrading. The stripped test has now reproduced on both Unraid 7.3.2 with Linux 6.18.38 and Unraid 7.2.8 with Linux 6.12.98 In both cases, faults occurred with the array and pools stopped, Docker and VMs disabled, Safe Mode active, and no third-party plugins involved. They also reproduced from separately prepared boot media. The failures affect unrelated components and execution paths—including PHP, smartctl, Node, the dynamic loader, libc, SquashFS, XFS, BTRFS and core kernel memory-management code, and occur across both CPU sockets. This is not the pattern expected from a single Unraid service or a regression confined to one kernel version. The repeated PHP offset may represent a separate defect in a software path common to both releases, since 7.2 and 7.3 share some userspace components. However, that cannot explain the complete cross-runtime, filesystem and kernel corruption history. Taken together, the evidence now points primarily to intermittent platform-level corruption. The remaining likely areas include: - CPU cache or execution instability - Integrated memory controller instability - Motherboard or chipset problems - Power delivery or transient PSU/board regulation problems - DMA or PCIe-related memory corruption - Firmware or another platform-level issue Passing Dell diagnostics and five Memtest86+ passes reduces the likelihood of an ordinary reproducible CPU, DIMM or monitored hardware failure, but it does not rule out intermittent faults in the CPU caches, memory controllers, motherboard, power delivery or DMA paths. Those failures can corrupt memory without producing an EDAC, MCE or Dell event. You may continue the current 7.2.8 run to 48 hours for completeness, but it is already a failed test because four processes have faulted. I do not think another return-to-7.3 test is necessary unless you specifically want to compare the frequency of faults or kernel oopses. The next useful work should be hardware isolation rather than further Unraid-version testing: 1. Load conservative BIOS defaults and remove any non-default performance or power settings. 2. Reseat the processors, RDIMMs, risers and relevant power connections, or have this performed by a qualified technician. 3. Test reduced matched RDIMM populations, following Dell’s T420 socket/channel population rules. 4. If practical, test with one CPU/socket configuration or substitute known-good compatible CPUs, memory or motherboard hardware. 5. The most decisive control would be running the same stripped Unraid configuration on different known-good hardware. IMO there is no evidence that upgrading, downgrading or changing the Unraid kernel branch resolves the overall problem. The broad failure pattern is now much more consistent with an intermittent hardware/platform fault.

Yep, I've also found that some time ago, LT is aware, but no fix yet AFAIK, a quick workaround is to run the newpermissions tool on the pool.

Thanks, this confirms exactly what is happening. Both commands were read-only and did not change anything. qemu-img info --backing-chain followed the disk chain from newest to oldest. It found exactly two layers: 1. /mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2 — the active overlay containing your newer changes. 2. /mnt/cache/domains/Windows 11/vdisk1.qcow2 — the older base image. There is no third layer. Your current 64 GiB virtual disk is the combined view of those two files. The second command displayed Unraid’s snapshot database. Its output was blank; that means the database is empty. This explains why the Snapshots section no longer appears in the WebGUI. It does not remove the backing-file relationship stored inside vdisk1.provisionedqcow2, which is why the cache file still appears in the running XML. We should not use Remove or Block Commit now. Block Commit would write the changes into the old base on cache, while modifying the existing overlay in place would add unnecessary risk. The safest approach is to read the complete two-file chain and write its current state into a third, new, standalone qcow2 file. First: 1. Shut down the VM and temporarily disable its autostart. 2. Confirm that you have independent backup copies of both original qcow2 files. 3. Make sure the following destination file does not already exist. Then run: qemu-img convert -p -f qcow2 -O qcow2 "/mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2" "/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2" This reads the current guest-visible state through both existing files and writes it into the new vdisk1.flattened.qcow2. It does not modify either original. After conversion, run: qemu-img check "/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2" qemu-img info --backing-chain "/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2" qemu-img compare -p -f qcow2 -F qcow2 "/mnt/vdiskpool/domains/Windows 11/vdisk1.provisionedqcow2" "/mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2" The expected results are: - qemu-img check reports no errors. - qemu-img info lists only vdisk1.flattened.qcow2 and no backing file. - qemu-img compare reports that the images are identical. Post those results before changing or deleting anything. Once they pass, we can point the stopped VM at vdisk1.flattened.qcow2, boot it and verify that the latest data is present. Keep both original files and their backups until the new disk has been thoroughly checked. After recovery, we should also change VM Manager’s default storage path from /mnt/cache/domains/ to the new VM pool.