JorgeB

Welcome Jake! 🍻

Don't assign any parity, doing that should allow to confirm which devices are data devices.

I would prefer to see a SMART report before suggesting what I would do next.

OK, thanks, I'll keep an eye out for any other occurrences to see if I can find anything in common to create a bug report.

Disk1 is being detected with a different capacity; any idea why? You can try doing a new config and see if it mounts, but if it doesn't, don't format or do anything else and just post the diags. P.S. Are you certain that's how you had the devices assigned? It looks like a very strange setup, having two SSDs as parity and just one as data. If you are not sure, do a new config and assign all the devices as data devices first, then start the array and post the diagnostics.

That may work, but assuming they started rebuilding in normal mode, parity won't be 100% valid, and it may cause filesystem issues on the emulated disk, though if it's XFS it should be recoverable. Depending on how the disk is failing, if they can still run a correcting check after the new config and before the replacement, it would be better.

Thanks. These diagnostics show the Linux VM being Force Stopped at 09:14:25 and starting normally nine seconds later. QEMU was still running when the diagnostics were generated, and there are no host-side errors explaining the original failure. The next time Restart appears to fail, do not Force Stop immediately: 1. Confirm whether Unraid reports the VM as Running or Stopped. 2. Close the old VNC window and open a completely new VNC connection. 3. Check whether the guest is reachable through its normal network service—SSH for Linux, or ping/RDP for Windows. 4. Generate diagnostics while the failure is still present. If possible, also run these from the Unraid terminal while it is stuck and post the output: virsh domstate "<VM name>" --reason virsh qemu-monitor-command --hmp "<VM name>" "info status" virsh qemu-agent-command "<VM name>" '{"execute":"guest-ping"}' For the Stop test, losing VNC is normal once the VM reaches Stopped. Start it again before checking whether VNC returns. Since one reboot worked after the forced stop/start, this may be intermittent or limited to the VNC/display connection rather than every VM reboot failing.

Thanks, these older diagnostics were very useful. On August 29, 2024, while running Unraid 7.0.0-beta.2, the global next-FSID counter was 108, and the existing exported shares had unique IDs 101, 102, 103, and 107. By October 31, the server was running 6.12.13 with 7.0.0-beta.2 recorded as the previous version. The existing share IDs were unchanged, but the global counter had reset to 100. This means the counter became stale during that interval, which includes the downgrade from 7.0.0-beta.2 to 6.12.13. The May 2025 diagnostics still show the counter at 100, and the stored share configuration already contains a duplicate 101. Global NFS was disabled then, so it was dormant, but this confirms the stale state existed well before the 7.3 upgrade. This therefore does not appear to have been introduced by 7.3. However, the current allocator should still validate all retained share IDs before assigning a new one, rather than trusting the global counter, so it looks like there may still exist a product bug to address. If you remember restoring any flash configuration or manually changing share.cfg around the October 2024 downgrade, please let us know. Otherwise, these diagnostics have narrowed the relevant window sufficiently.

Post a screenshot from Main

Thanks, the diags confirm that the new Windows VM was Force Stopped several times, but there is no QEMU crash or host-side error immediately before those stops. The reason=destroyed entries simply record the Force Stop itself. Could you clarify exactly which operation fails: - Restart from inside the guest - Restart from the Unraid VM menu - Stop from the Unraid VM menu - Rebooting the Unraid server Test Shutdown and Restart separately on one VM. When it becomes stuck again, before using Force Stop: 1. Take a screenshot of the VNC console and tell us exactly what is displayed. 2. Note the time and the action that triggered it. 3. Generate and attach fresh diagnostics. 4. Confirm whether the QEMU Guest Agent is installed and running inside the guest. For the Windows installation, also tell us whether it remains on the restarting screen, goes black, or boots back into the installer. I noticed that an older VM definition still references a Windows ISO that no longer exists, recommend removing or correcting that stale ISO reference, although it would not explain the same behavior affecting Linux guests.

Thanks, that clarification is very useful. It confirms this was not a single duplicate assignment: after FSID 100, the allocator continued assigning 101, 102, and 103 even though those values were already retained by other shares, before reaching unused values. Please do not create any more test shares to advance the counter, as that can create additional duplicate FSIDs. please attach the diagnostics from May 2025 and August and October 2024. Since they are from the same boot device, we can compare config/share.cfg with the per-share configuration files to determine when the global FSID counter became stale. The anonymized diagnostics are sufficient. If you also have a flash backup from before the affected share was created, please it. Deleting network.cfg by itself would not normally reset this counter because the value is stored in share.cfg, but the older diagnostics may show whether another configuration change occurred around the same time.

Please post more details on how you are creating the VMs and when you see the issue, also the diagnostics after it happens.

The diagnostics confirm the issue. When the new export was mounted, rpc.mountd reported that it and an existing export had the same filehandle and selected the first one. That explains why the client reached the wrong path. The repeated FSID 0 values are not a problem in this case because those shares have NFS export disabled. The problem is duplicate explicit nonzero FSIDs assigned to different shares. The new share is now using FSID 104, and the global next-FSID counter is currently 107. Please unmount and remount the affected exports on the client, since the client may retain the previous filehandle mapping. Also check both shares for any files that may have been written to the wrong location. Can you confirm whether the flash configuration or share configuration files were previously restored, copied, or recreated, and whether NFS was recently disabled and re-enabled? If you have a flash backup from before correcting the FSID, please preserve it, as comparing its config/share.cfg and affected share files may show how the allocator’s counter became stale. This should not happen, the new-share allocator should validate existing IDs before assigning one, so it may be a bug.

Please post the diagnostics

Yes, you can go back to a flash drive, just create a new one and copy the current config.

If you mean it doesn't even show the Unraid boot menu, either the flash drive is not the selected boot device, or it was incorrectly created. You can try booting the flash drive in another PC to confirm.

Please post a screenshot of the error you see.

If the VM is now pointing to /mnt/vdiskpool you can delete those files.

Everything looks good to me, the next safe steps are: 1. Keep the VM stopped with autostart disabled. 2. Open the VM editor in Form View. 3. Set the primary vDisk location manually to: /mnt/vdiskpool/domains/Windows 11/vdisk1.flattened.qcow2 4. Apply the change, then reopen the VM configuration and confirm it references the flattened file. 5. Start the VM and verify that the newest files and application data are present. 6. Keep both original qcow2 files and their backup copies until the flattened VM has been thoroughly verified. 7. Afterwards, change VM Manager’s default storage path from /mnt/cache/domains/ to /mnt/vdiskpool/domains/.

The diagnostics show that /dev/sdh1 was disconnected at the USB level while it was still mounted. There is no Unassigned Devices unmount before the disconnect, and approximately 20 seconds later a different external disk was connected to the same USB port. The subsequent Btrfs read errors and read-only state are consequences of the original disk no longer being available; they do not indicate that Btrfs caused the disk to disappear. Did you intentionally disconnect or swap the 22 TB disk at that time? If so, always use Unmount in Unassigned Devices and wait for it to complete before disconnecting the disk. If the disconnect was not intentional, check or replace the USB cable, external power supply, enclosure connection, and USB port. Reconnect the original disk and reboot to clear the stale mount. Once the connection is stable, back up any important data, review the disk’s SMART report, and run a Btrfs scrub. Post new diagnostics after rebooting with the affected disk connected so we can review its SMART information. Separately, the logs also show that one of the NVMe cache devices previously timed out and dropped offline. That is unrelated to /dev/sdh1, but it should also be investigated.

The diagnostics suggest a connection-path problem affecting disk10 rather than clear evidence of multiple failing disks. Disk10 is connected to the second ASM1061 port and repeatedly logs SATA handshake/ATA bus errors, followed by link resets and a reduction from 6 to 3 Gb/s. The same error sequence is present in both supplied logs. Since you have already replaced the SATA cable and PSU, I would next move disk10 to a known-good Intel or LSI SATA connection, if possible. If no spare connection is available, power down and swap the ASM1061 connections for disk5 and disk10; that can help determine whether the errors remain with the controller port or follow disk10. I would avoid further correcting parity checks until this connection issue is resolved, and ensure any important data is backed up. The recent extended SMART tests for disks 8, 9, and 10 all passed, with no pending, reallocated, or offline-uncorrectable sectors, but the displayed WD raw-read values are not a good sign, especially if they keep going up. The older syslog also does not include the event that originally disabled disk9, so unfortunately we cannot determine its cause from that file. After moving disk10, exercise the array normally and post fresh diagnostics. If no further ATA errors appear, run one non-correcting parity check during otherwise quiet activity. Some errors during the 1st check can be normal even if the issue is resolved. If parity errors still recur after the 1st check with a clean storage log, the next step would be an extended Memtest86+ run to rule out RAM/platform instability.

What exactly is the error? Did you set it as the first boot device? Also, was it created with the USB Creator?

Please post the diagnostics

The OOM problem is still present. Container ID c4560328a5f1… has a 1 GiB memory limit and repeatedly reaches exactly that limit. Updating the container changed its ID but preserved its template and memory limit. The dump contains >200 nginx processes in that container, likely aggravated by the server’s 120 logical CPUs and automatic nginx worker sizing.

The issue should be resolved now; it was a global FeatureOS problem. Please retest.