JorgeB

It does appear to be failing, you try try cloning it to a spare devicew, to see if it can copy enough data to rescue some: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-525075

Welcome! 🍻

Enable the syslog server and please post that after the next crash.

That looks OK; I recommend booting the flash drive in a different PC in legacy mode to confirm it's working (not UEFI). You can also try recreating it with Rufus, just to rule out some USB creater compaity issue wi tht eflash Get the Unraid zip from https://docs.unraid.net/unraid-os/download_list/ - Open Rufus and change "Boot selection" to "Freedos" - Set the "Volume label" to UNRAID - set filesystem to FAT32 - click START - once done, unpack the Unraid ZIP to the flash drive - run the make_bootable.bat as administrator.

It's not logged as a disk problem and SMART looks fine, most likely a power/connection issue, check/repalce both cables, remove any splitters if in use,and if the emulated disk is still mounting, and contents look correct you can then rebuild on top

Click ENTER on "Hard Disk Boot Priority" and post a photo of that

Taking another look at the screenshots shows the likely problem. The first boot device is set to USB-FDD, which treats the flash as a floppy device. Set First Boot Device to USB-HDD. Then open Hard Disk Boot Priority and move the actual Unraid flash drive to the first position. You can also press F12 during startup and select the flash by its device name. The USB Controllers, USB Legacy Function, and USB Storage Function settings are already correct. This board is currently using its legacy Award BIOS, so the EFI folder is not relevant to this boot attempt. Since make_bootable_mac completed successfully, try the corrected boot selection before recreating the flash again. If it still stops at Loading Operating System..., use a direct rear USB 2.0 port. Also post a photo of Hard Disk Boot Priority and provide the motherboard revision and BIOS version, also worth confirming the flash drive is booting with a different PC (in legacy mode, not UEFI) Separately, after it boots, I recommend changing PCH SATA Control Mode from IDE to AHCI before configuring the storage drives.

DId you run Make Bootable? That's needed for legacy boot after creating the flash drive, also mention the board model.

The iGPU is detected at 00:02.0 and is bound to the i915 driver. However, the driver fails during initialization: ERROR GT0: Failed to reset GuC, ret = -110 This leaves the GPU engine unusable even though /dev/dri/renderD128 exists. It explains the GPU Statistics, intel_gpu_top, Tdarr, and Jellyfin failures. These diagnostics are from Unraid 7.2.6. The same error appears in both recorded 7.2.6 boots. Therefore, we cannot yet confirm that 7.3.2 caused the problem. Please do a complete cold power cycle: 1. Shut down Unraid cleanly. 2. Disconnect power from the server. 3. Wait until all standby lights turn off. 4. Reconnect power and start the server. 5. Before starting any transcodes, post new diagnostics. Please also provide the exact motherboard or appliance model. The diagnostics report only Default string. Tell us the last Unraid version on which transcoding definitely worked, and do not change i915.enable_guc or device permissions yet. Those changes can hide the result of the cold-boot test.

The diagnostics are still useful, even though they were collected after removing the NIC. One point needs clarification: these diagnostics identify an ASUS X99-DELUXE with one Xeon E5-2697 v4 and one CPU socket. Your original description mentioned a dual-socket motherboard and two CPUs. Can you confirm that these diagnostics came from the same server and tell us the exact printed motherboard slot label where the NIC was installed? Please leave the NIC removed until the reconstruction finishes. Before testing it again: - Configure remote syslog to another machine through the working Intel interface. The current configuration keeps only one 1 MiB log file on the flash drive, which is why the failure boundary was lost. - Return the networking configuration to a clean baseline. It still references absent eth2 and eth3 interfaces, and the boot log contains two modprobe segfaults. - Temporarily remove the custom go file commands for eth2/eth3 and the custom bnx2x.conf. In particular, disable_fw_vpd does not appear to be a standard bnx2x parameter. - Check the exact NIC manufacturer and part number, firmware version, fan operation and airflow, DAC model, and PSU model. - After the rebuild, reinstall the card with Docker and VM autostart disabled and collect diagnostics before applying any load. Then test it in stages: idle first, 10GbE traffic with storage idle, and only afterward controlled storage activity. If it still hard-freezes from that clean baseline, testing another suitable slot or the card in another system should tell us whether replacement is warranted. The earlier lspci -vvv VPD warning does not identify which device caused it. The current log also contains an optional-VPD warning from the LSI HBA, so that warning alone is not proof of a NIC or PCIe problem.

The diagnostics suggest that this is being caused by the third-party HomeAssistant_inabox_v3 container. The container starts before VM Manager and bind-mounts /var/run/libvirt/libvirt-sock. Because the socket does not exist yet, Docker creates a directory at that path. Libvirt then cannot create its socket and fails with Address already in use. Please disable autostart for HomeAssistant_inabox_v3 and reboot. Make sure that VM Manager starts first, then start the container manually. There is no need to recreate libvirt.img. The diagnostics show that the existing image and VMs start correctly after the socket conflict is removed.

Also please post a photo of the error you see.

The SSD appears to be failing; run an extended SMART test and post the result.

You cannot add a device to an XFS pool, only btrfs or zfs, so no, in this case it won't let you change slots to 2, you would need to backup and recreate the pool with a multi device filesystem for the data partitions.

There's a missing device, if the pool were redundant, you can try to import it degraded with the remaining one, for that: on main click on the first device for that pool and then "remove pool" back on main, create a new pool with the same name and 1 slot assign the remaining pool device (sdf), leave the filesystem set to auto start the array to import the pool and post new diags

This server is named lexiconm, previous diags were from a server named tower. These do have that pool, but no btrfs filesystem is being found post the output from btrfs fi show

I would try a different PCIe slot first

Please post the diagnostics.

The replacement share exists, its Time Machine SMB configuration looks correct, and your successful Finder write test confirms that the path is accessible and writable. However, the share is currently configured as Public, which permits guest access. Finder may therefore be using a guest or previously cached connection while Time Machine is trying different saved credentials. Please try the following: 1. Create or use a regular Unraid user with a password, do not use root. 2. Change the Time Machine share’s SMB Security setting to Private and give that user Read/Write access. 3. Remove the destination from Time Machine and disconnect existing SMB connections to the server. 4. In macOS Keychain Access, remove saved network-password entries for both the server IP and hostname. 5. Reconnect in Finder using the same SMB address and the named Unraid user, then add that share to Time Machine again. If it still fails, please note the exact failure time and collect diagnostics after the error appears. The diagnostics you attached do not contain the reported attempt: their syslog stops at 08:26, while the attempt was around 08:30. Regarding the cache NVMe, the new diagnostics contain nine additional critical-medium read errors at the same LBA. SMART still reports PASSED, but that does not override the repeated device-level read errors. I recommend copying the data and replacing the NVMe rather than relying on a self-test. Copying /mnt/cache to /mnt/disk3/tempcache is reasonable, provided disk3 is healthy and has sufficient free space. First stop Docker, VM Manager, and anything else writing to cache. Then run: mkdir -p /mnt/disk3/tempcache rsync -aHAXS --numeric-ids --info=progress2 /mnt/cache/ /mnt/disk3/tempcache/ Do not add --delete. Check that rsync completes without read errors. Also keep both ends as physical disk/pool paths, do not change one side to /mnt/user/.... Once the copy is safe, you can run an Extended SMART self-test from the cache device’s SMART page if desired, but even a passing result would not change the replacement recommendation. Please do not run a scrub or stress test before protecting the data. The replacement Time Machine share is on disk1, so the failing cache NVMe is not causing this credentials error.

Yep

Since the pool is redundant, and assuming there's enough free space, you could remove one drive at a time.

I see an issue moving files to exclusive shares due to the rsync changes, but it's not deleting any files for me, just failing to move them, but we can continue in the bug report.

Please post the diagnostics.

That will work as long as the new device isn't smaller.

The external LSI 9207-8e HBA is detected on PCIe, but it fails during driver initialization: doorbell handshake int failed baseget_ioc_facts: handshake failed This failure occurs on two consecutive boots. Since the HBA never initializes, Unraid cannot discover any disks in the external shelf.