timg11

In my Windows 11 VM running under Unraid 7.2.2, it is difficult or impossible to safely remove USB drives that are mounted in the VM. One of the host system's USB3 controllers (ASMedia) is passed through to the VM. It is a physical USB3 controller on a PCIe card. Devices that are directly and locally used by the Windows VM are connected there. In the Windows VM, the device Manager tree looks like this: The problem is the "Safely Remove Device" dialog in the tray looks like this: If I remove the ASMedia USB3.1 controller, it also removes devices unrelated to the USB hard drives and used by applications, and would affect system operation. The USB Mass Storage Device that holds the drives is a Sabrent 4-bay drive docking controller Attempting to disable this device in Device Manager results in a prompt to reboot. Has anyone found a clean way to shut down drives for replacement without shutting down the VM?

I run Unraid 7.2.0 on a Dell T440 server with two Gigabit Ethernet ports. They are bonded as bond0 using 802.1ad LAG. The two ports connect to a Cisco SG200-26 26-Port Gigabit Smart Switch, on ports GE25 and GE26. They are also configured as LAG. When I first built the system, I did an informal test copying large files from network hosts to the array. On the Dashboard Interface, I saw the Inbound go well above 1000 Mbps, so I thought Bonding was OK. Now I've run a more precise test with iperf. Running a single iperf test with the client on a system on the LAN to the Unraid Server running iperf server shows throughput of 950 Mbps. I expected running simultaneous iperf (from separate hosts on the LAN to two different iperf server ports on Unraid) would show a speed around 1900 Mbps due to LAG. What actually happens is each iperf test slows down to about 300 Mbps when run concurrently. Gemini suggested changing Unraid xmit_hash policy. It is currently layer2: root@T440:~# cat /sys/class/net/bond0/bonding/xmit_hash_policy layer2 0 The recommendation is ifconfig bond0 down echo layer3+4 > /sys/class/net/bond0/bonding/xmit_hash_policy ifconfig bond0 up I have not done that because the only way I access Unraid is by the network, so I'd have to add a monitor and keyboard to retain connectivity. Is this the first thing to look at for poor network performance with Bonding and Lag?

I have an array of 4 Seagate IronWolf Pro drives in this Unraid 7.2.2 system. When copying large files from another system to the Array, I'm seeing about 50 - 55 MB/s write speed. The CPU is running 6-10%, and the network interface is running about 500 Mbps. The "theoretical" write rate of IronWolf Pro is about 200 MB/s. Is there something wrong or misconfigured, or is this all these drives can actually deliver in a real-world Unraid array? Here's the results of a copy process writing a group of 100 2 GB files to the array from another computer over the network. Everything else is idle on the Unraid system. The sending computer is not CPU limited or network limited. I'm curious why the read rate is about the same as the write rate? Is that expected? Diagnostics attached: t440-diagnostics-20260118-1201.zip

@trurl here are the user share settings for domains: and my global share settings: It looks like I'd need to Permit Exclusive Shares, and then set that in the domains share settings. Making that change would apparently require shutting down everything, VMs, Dockers, and the Array. And the benefit is better VM performance? Is there any downside? I think I set up the "mover" thinking it would be easy to back up the VMs to the Array, but it turned out that copying a VM .img from newcache to array is incredibly slow. I don't want to leave the VMs shut down that long. But using the magic of btrfs, I can shut down a VM, copy its image file to a folder on newcache (which takes about a second), restart the VM, and let Unraid perform the leisurely copy of the .img file copy to the Array. Once copied to the Arrary, I can then delete the copy from newcache.

I've been running with the snapshots flattened, and down to a single .img file. However, Unraid still thinks that snapshots exist. You said to remove the .db files, but where do I find them to remove them?

I have a Windows 11 VM with image files located on /mnt/newcache/domains/Windows11. The VM primary (boot drive) vdisk image is 100G. When I was debugging, I was frustrated that when I stopped the VM to copy the .img file to my array, it was unexpectedly slow. It took about 1 hour to copy 100 GB from newcache to array (made of Seagate IronWolf Pro drives). 100,000 MB / 3600 seconds = 28 MB / s. This was on an unloaded system, <10% total CPU use during the copy. When the array is operating I can see individual disk rates of 200 MB / s on sustained transfer on the Unraid Main tab. I have not solved that issue yet. As an alternative, I explored keeping the backup images on the newcache drive. It is 1T in size, and only 150 GB was in use. With the VM stopped, I ran the commands: root@T440:/mnt/newcache/domains/Windows11# mkdir imgbackup root@T440:/mnt/newcache/domains/Windows11# cp vdisk1.img imgbackup/ This command completed in about 1 second! I thought it didn't work, but the copy of the file was there. I asked Gemini if this was something done internally by the DELLBOSS card, but it said it was a result of btrfs: The 1 second "copy" is not trickery from your Dell BOSS card, but a brilliant feature of the BTRFS (or XFS) file system Unraid uses for cache pools called Reflink (Reference Link). 1. The "Magic" of Reflink Copies When you use cp on the same NVMe pool, the file system doesn't actually move the 100GB of data bits. Instead, it creates a new "pointer" (metadata) that points to the exact same physical data blocks on the drive. Space Savings: Currently, that 100GB copy is taking up zero extra bytes on your NVMe. Instant Backup: It is 100% bit-perfect and safe. Copy-on-Write (CoW): If you start the original VM and it changes a single block of data, the file system will only then write that specific change to a new area of the drive. The backup in your working_img_0102 folder will remain unchanged, frozen at the moment you made the copy. Is this true? It seems to be, at least in terms of space, since I have created 4 "copies" of the 100G img file and the total space is only up to 268 G now. Is there any performance overhead leaving several versions of the image file reflinked like that on the drive? Should I move them off to the Array once the VM is stable? Presumably I could copy the backup copies to the array while the VM is running?

That sounds like a great idea! I had not heard that suggestion before, but it makes sense. I will try it the next time I'm feeling adventurous and have time for debugging.

I believe my image files are on a cache drive There appears to be two ways to access the same place. root@T440:/mnt/user/domains/Windows11# ls -l total 36480328 drwxrwxrwx 1 root root 264 Jan 1 17:54 badimage/ drwxrwxrwx 1 root root 20 Jan 1 18:06 badimage2/ -rwxrwxrwx 1 root users 107374182400 Jan 4 16:11 vdisk1.img* -rwxrwxrwx 1 nobody users 1073741824 Dec 31 16:21 vdisk2.img* drwxrwxrwx 1 root root 184 Jan 2 10:18 working_img_0102/ drwxrwxrwx 1 root root 184 Jan 2 13:16 working_img_2026-01-02_13_10_44/ root@T440:/mnt/user/domains/Windows11# cd /mnt/newcache/domains/Windows11/ root@T440:/mnt/newcache/domains/Windows11# ls -l total 36480772 drwxrwxrwx 1 root root 264 Jan 1 17:54 badimage/ drwxrwxrwx 1 root root 20 Jan 1 18:06 badimage2/ -rwxrwxrwx 1 root users 107374182400 Jan 4 16:12 vdisk1.img* -rwxrwxrwx 1 nobody users 1073741824 Dec 31 16:21 vdisk2.img* drwxrwxrwx 1 root root 184 Jan 2 10:18 working_img_0102/ drwxrwxrwx 1 root root 184 Jan 2 13:16 working_img_2026-01-02_13_10_44/ root@T440:/mnt/newcache/domains/Windows11# I was under the impression that the /mnt/newcache/domains/Windows11 was the best choice for the VM's vdisk, since it would not have the overhead of the FUSE filesystem that paths through /mnt/user incur. I could be wrong - please educate me. t440-diagnostics-20260104-1618.zip

That is exactly what I did. Stop VM, add 2nd vdisk as VirtIO. Start VM, load drivers. I saw the RedHat VirtIO serial driver was installed for the 2nd disk, with no errors in Device Manager. I then stopped the VM, changed the boot disk vdisk1 to VirtIO and restarted. The noVNC console was black for over 5 minutes. No spinning circle, no Unraid Logo, nothing. Unraid said VM was running. I tried Force Stop, waited a couple minutes, then restarted VM. BSOD - PAGEFAULT IN NONPAGED AREA. I forced stop, and tried to reset the VM configuration for vdisk1 back to SATA. Restarting gave BSOD SYSTEM THREAD EXCEPTION NOT HANDLED. It went downhill from there.

Maybe that's an easy process for you, but it has been a nightmare for me. The basic issue is the VM now uses SATA for the boot drive. It can't be changed without updating the drivers, which can't be changed without the VM running - catch 22. The process I tried (suggested by Gemini) was to create a 1G small vdisk2, and set it to VirtIO. That was supposed to cause Windows to load the needed VirtIO driver for vdisk2, then I could stop and change the boot vdisk1 to VirtIO and it would use the driver for vdisk1 and it would be happy. Not at all! I've been through two full days of BSOD, boot device inaccessible, SYSTEM THREAD EXCEPTION NOT HANDLED, SYSTEM THREAD EXCEPTION, PAGE_FAULT_IN_NONPAGED_AREA, Windows Automatic Repair, booting off the ISO, diskpart, bcdedit, and on and on. Sometimes I could get the VM to boot, but the desktop would freeze after less than a minute. I was trying to use Gemini, but had to keep reigning it in as it always want to keep pressing on in the same direction, rather than step back for a broader look. Gemini was always making excuses for each new failure, which made me think the QEMU / Windows combination is like a house of cards or a 100m high Jenga tower. After two days spent, I finally set aside the failed image, restored a backup vdisk1.img (fortunately saved off before trying VirtIO), and put the XML back to the way it was. Surprisingly, I still had BSODs, and learned from Gemini that there is another "State" file - the NVRAM images in /etc/libvirt/qemu/nvram/. It keeps hardware details and had no doubt become a mess during all the trials, failed boots, force stops, and BSODs. I had to find the one for the Windows VM and delete it. Finally I can run the VM again, but of course it is still slow. Is there any other resource, white paper, thread, or other place I can go for guidance on the correct way to approach updating a WIndows VM to use VirtIO for its boot drive?

AI makes this suggestion. Can any expert confirm if it is correct? 1. Storage – Biggest Likely Culprit Your vdisk is at /mnt/user/domains/Windows 11/vdisk1.img. /mnt/user/ paths go through Unraid's FUSE/shfs layer, adding overhead—even if the files are on cache. This often causes VM sluggishness (high disk latency, slow responsiveness). Fix: Move to a direct cache path for better IO: Stop the VM. Create a dedicated folder (e.g., via terminal: mkdir -p /mnt/cache/domains). Move the img file: mv /mnt/user/domains/Windows\ 11/vdisk1.img /mnt/cache/domains/. Edit VM > Primary vDisk Location: Change to Manual and set /mnt/cache/domains/vdisk1.img. Ensure your "domains" share is set to Use cache: Prefer or Only (Settings > Shares). Bonus: Enable SSD and Discard: Unmap (Trim) (already on in your screenshot—good for SSD cache). I was unable to find a "Use cache:" setting under Settings / Shares. CPU use on the VM does not seem unusually high:

I migrated a Windows system running on a Core2 CPU to a Windows 11 VM on my T440 with Intel Gold 6134 8 Core (3.20Ghz). 3 of the 8 cores are dedicated to the Windows VM, and 16G of the total 64G of RAM are dedicated to Windows. I interacted with the old system using TightVNC and I interact with the new system using TightVNC, so that much is constant. (Not the VM's VNC (which has problems with mouse), but a separate server) However, the Windows VM performance under UnRaid is terrible. Typing in a terminal gets behind. Everything is sluggish. I would estimate it is running 20% as fast as the old system. Most functions of the old server have been migrated to a Debian VM or Docker containers under Unraid, but there are some Windows-only programs. It is not a heavy CPU load at all, but the slowness of the UI makes it painful to use. Is there any white paper or guidance on performance tuning VMs? What techniques for benchmarking can identify performance issues?

Here's how my "domains" folders look now: root@T440:/mnt/user/domains# cd Debian/ root@T440:/mnt/user/domains/Debian# ls -l total 9140352 drwxrwxrwx 1 root root 590 Dec 27 10:38 temp/ -rw-r--r-- 1 root users 32212254720 Dec 29 17:18 vdisk1.img root@T440:/mnt/user/domains/Debian# cd ../Windows\ 11/ root@T440:/mnt/user/domains/Windows 11# ls -l total 38000332 -rw-r--r-- 1 root root 7148 Sep 1 16:47 2025-09-01--generate.running -rw-r--r-- 1 root root 6778 Jun 21 2025 S20250621140445.running -rw-r--r-- 1 root root 6960 Aug 24 13:27 S20250824132729.running -rw-r--r-- 1 root root 7349 Sep 27 12:32 S20250927123248.running -rw-r--r-- 1 root root 6778 Jun 21 2025 Windows--generate.running -rwxrwxrwx 1 root users 107374182400 Dec 29 17:19 vdisk1.img* root@T440:/mnt/user/domains/Windows 11# Which of these would be the "snapshot dB" file that causes the GUI to show the old snapshots?

@SimonF Thanks for your help. I performed the flatten process and now the Debian directory looks like this with a single image file: root@T440:/mnt/user/domains/Debian# ls -ltr total 11438560 drwxrwxrwx 1 root root 590 Dec 27 10:38 temp/ -rw-r--r-- 1 root users 32212254720 Dec 27 10:53 vdisk1.img root@T440:/mnt/user/domains/Debian# When I edited the vdisk back to vdisk1.img, it changed its setting from Manual to Automatic after I Updated. I am seeing the bug where the old snapshots still show in the GUI: Is there a manual fix for that, or should I just ignore it?

@simonF, It seems that my Unraid 7.2 setup differs from your, which makes me nervous. You say "base is the first image in the tree with top being the latest." Here is my snapshot tree for Debian: Using the DATE/TIME field, it appears the latest is at the bottom. Here are the raw files, which don't lie, but also don't show the tree relationship. root@T440:/mnt/user/domains/Debian# ls -l total 23813084 -rw-r--r-- 1 root root 7353 Jun 21 2025 Debian2025-06-21--generate.running -rw-r--r-- 1 root root 7540 Jul 13 16:38 S20250713163832.running -rw-r--r-- 1 root root 7724 Aug 10 13:18 S20250810131826.running -rw-r--r-- 1 root root 7724 Aug 10 13:18 S20250810131841.running -rw-r--r-- 1 root root 7916 Aug 24 13:15 S20250824131502.running -rw-r--r-- 1 root root 7353 Jun 21 2025 debian-snap-2025-06-21--generate.running -rw------- 1 root users 1130758144 Jul 13 16:38 vdisk1.Debian2025-06-21--generateqcow2 -rw------- 1 root users 777977856 Aug 10 13:18 vdisk1.S20250713163832qcow2 -rw------- 1 root users 9655549952 Aug 24 13:15 vdisk1.S20250810131841qcow2 -rw------- 1 root users 9864347648 Dec 22 16:17 vdisk1.S20250824131502qcow2 -rwxrwxrwx 1 root users 32212254720 Jun 21 2025 vdisk1.img* root@T440:/mnt/user/domains/Debian# Because the snapshot UI has bugs and inconsistencies, I got an AI recommendation to go with CLI: 🛠️ How to Flatten your Snapshot ChainThis process will create a new, 100% independent "Gold Image" from your current state. Stop the VM: You cannot safely flatten the chain while the VM is running. Open the Unraid Terminal: Navigate to your VM directory: cd /mnt/user/domains/Debian/ Run the Convert Command: Identify your latest snapshot file from your ls output: vdisk1.S20250824131502qcow2. Run this command: Bash qemu-img convert -O raw vdisk1.S20250824131502qcow2 vdisk1_flattened.img What this does: It reads the latest snapshot, looks back through every parent file in the chain, and writes one single, consolidated raw image file containing everything. 🔄 Swapping to the New Flattened ImageOnce the command finishes, you will have a new file named vdisk1_flattened.img. To use it: Backup the old files: Move the old .qcow2 files and the original vdisk1.img into a "TEMP" folder just in case. Rename: Rename vdisk1_flattened.img to vdisk1.img. Edit VM Settings: In the Unraid VM settings, ensure the Primary vDisk is pointing to the new vdisk1.img. Start the VM: It should boot exactly as it was, but now it is a "single file" VM again with no dependencies on snapshots. Is that process valid and safe to get back to a single IMG? If the web UI is up to the task and better than the AI's CLI process, can you give me a step by step procedure? Maybe it is just as simple as this: 1) click on most recent snapshot (Bottom). In my case, it is S20250824131502. Click on Block Commit. 2) wait for process to finish. 3) click on next most recent snapshot (now moved to bottom of tree since the prior one has been merged?) Click on Block Commit. 4) repeat (working up the tree from bottom leaf to top root, until all snapshots are gone (or will they never by gone because of the bug with the ghost record you mentioned?) PS - I have changed my profile "Personal text" and "About Me" to "Unraid 7.2.2 on Dell T440 server with Windows 11 VM and Debian 13 VM" yet every post still has Unraid 7.0.1. Is posting signature yet another setting I am unable to find?

I second this. Replacing an existing disk in an array with a larger one should take the time of copying the data on the replaced disk, not the new (blank) one. Scenario: I originally set up my array with 16T drives. I upgraded the Parity to 28T, now I'm upgrading data drives to 28T as they are affordable. If the disk contains a maximum of 16T of data, why spend the time copying 28T? This makes a big difference as we get to these larger drives that take multiple days to fully copy. The related question is why if the disk is 50% full and is replaced with one of the same size, why does the full capacity of the drive have to be copied?

The thing I'm looking for experts to confirm is the correct procedure for removing and merging unwanted snapshots back into the base IMG. There was conflicting information earlier in the thread on how to proceed with a Block Commit when there are multiple snapshots. Should I start with the most recent (at the bottom of the tree), and sequentially work my way up performing a block commit on each? Or start with the top of the tree (first/oldest snapshot), do a block commit on it, and it will automatically incorporates the changes from the subsequent snapshots in the tree below it? Either approach sounds plausible, and I expect doing it wrong could result in data loss by setting the VM to a point in the past.

@JorgeB Thanks for the reply. So if I want to move the PSQL data off the primary share I would just shut down the PSQL Container, run a command like this from Unraid SSH: mv /mnt/user/d/postgresql18/* /mnt/user/some/other/share/ Then change the volume mapping of the docker container to /var/lib/postgresql <--> /mnt/user/some/other/share/ To my original question on how to back up PSQL, I presume use something like pg_dumpall > /mnt/user/d/postgresqlbackup/psql_dumpfile.dat That can create a backup while the psql container is running. Set it up as a user scripts scheduled process once a day or something? That would write its output to the d share and get backed up automatically.

I have a share set up on my array at /mnt/user/d/. There are specific users that have permissions to read and write. I recently installed Postgresql in a Docker container. I'm migrating PSQL from a Windows machine to Unraid. It's database folder is on the shared drive, at a similar place as it was on the prior Windows server. (On Windows D: was a physical drive, on Unraid, d is a share) /var/lib/postgresql <--> /mnt/user/d/postgresql18/ I'm finding that /mnt/user/d/postgresql18/ is not accessible by users of /mnt/user/d/ Looking at the /mnt/user/d/postgresql18/ in an SSH terminal, I see the user and group are all 999. root@T440:/mnt/user/d/postgresql18/18/docker# ls -l total 64 -rw------- 1 999 999 3 Nov 28 11:46 PG_VERSION drwx------ 1 999 999 53 Nov 29 10:49 base/ drwx------ 1 999 999 38 Dec 10 13:29 global/ drwx------ 1 999 999 10 Nov 28 11:46 pg_commit_ts/ drwx------ 1 999 999 10 Nov 28 11:46 pg_dynshmem/ -rw------- 1 999 999 5743 Nov 30 13:19 pg_hba.conf -rw------- 1 999 999 2681 Nov 28 11:46 pg_ident.conf ... Since PSQL is accessed over the network, I generally don't need direct file access. However the d share is for files that needs layers of backup, not just the array and parity. I have a script for periodic offline/offsite backup that runs from another machine. It has permission for the d share. It should be including the PSQL files, and it is failing. What is the best approach to insure the PSQL databases get backed up?

@SimonF thanks for the reply. Here are some of the directory content's you mentioned: root@T440:/mnt/user/domains/Windows 11# ls -ltr total 38818060 -rw-r--r-- 1 root root 6778 Jun 21 14:04 S20250621140445.running -rw-r--r-- 1 root root 6778 Jun 21 14:10 Windows--generate.running -rw-r--r-- 1 root root 6960 Aug 24 13:27 S20250824132729.running -rw-r--r-- 1 root root 7148 Sep 1 16:47 2025-09-01--generate.running -rw-r--r-- 1 root root 7349 Sep 27 12:32 S20250927123248.running -rwxrwxrwx 1 root users 107374182400 Dec 10 14:26 vdisk1.img* root@T440:/mnt/user/domains/Windows 11# root@T440:/mnt/user/domains/Debian# ls -ltr total 23688028 -rw-r--r-- 1 root root 7353 Jun 21 14:02 debian-snap-2025-06-21--generate.running -rwxrwxrwx 1 root users 32212254720 Jun 21 14:09 vdisk1.img* -rw-r--r-- 1 root root 7353 Jun 21 14:10 Debian2025-06-21--generate.running -rw------- 1 root users 1130758144 Jul 13 16:38 vdisk1.Debian2025-06-21--generateqcow2 -rw-r--r-- 1 root root 7540 Jul 13 16:38 S20250713163832.running -rw-r--r-- 1 root root 7724 Aug 10 13:18 S20250810131826.running -rw------- 1 root users 777977856 Aug 10 13:18 vdisk1.S20250713163832qcow2 -rw-r--r-- 1 root root 7724 Aug 10 13:18 S20250810131841.running -rw------- 1 root users 9655549952 Aug 24 13:15 vdisk1.S20250810131841qcow2 -rw-r--r-- 1 root root 7916 Aug 24 13:15 S20250824131502.running -rw------- 1 root users 9864347648 Dec 10 14:31 vdisk1.S20250824131502qcow2 root@T440:/mnt/user/domains/Debian# root@T440:/etc/libvirt/qemu# ls -ltr total 16 drwxr-xr-x 1 root root 40 Apr 13 2025 networks/ drwxr-xr-x 1 root root 34 Apr 27 2025 swtpm/ drwxr-xr-x 1 root root 32 Jun 21 14:10 snapshotdb/ drwxr-xr-x 1 root users 0 Oct 4 17:43 snapshot/ drwxr-xr-x 1 root root 1894 Oct 26 11:07 nvram/ drwxr-xr-x 1 root root 48 Nov 28 16:43 autostart/ -rw------- 1 root root 6265 Dec 10 13:28 Debian.xml -rw------- 1 root root 7335 Dec 10 13:28 Windows\ 11.xml root@T440:/etc/libvirt/qemu# Note that above there is a file named "S20250824132729.running" and a file "2025-09-01--generate.running" in the directory /mnt/user/domains/Windows 11# However these files seem to be quite small in size compared to the .img files. Note that above there are also files matching these names in the directory /mnt/user/domains/Debian# For the Debian VM, the files appear in pairs. For the S20250824131502 Snapshot, there are two files. vdisk1.S20250810131841qcow2 and S20250824131502.running. The vdisk1.*qcow2 files are very large. root@T440:/etc/libvirt/qemu/snapshotdb# ls Debian/ Windows\ 11/ root@T440:/etc/libvirt/qemu/snapshotdb# cd Debian/ root@T440:/etc/libvirt/qemu/snapshotdb/Debian# ls snapshots.db root@T440:/etc/libvirt/qemu/snapshotdb/Debian# cd ../Windows\ 11/ root@T440:/etc/libvirt/qemu/snapshotdb/Windows 11# ls snapshots.db Win_snapshots.dbDeb_snapshots.db

I found what I was looking for in the file I located. In the future, I'll have to remember to download diagnostics before I remove a failed drive.

Using the smart directory in the diagnostics as a guide, I searched for filenames with the disk name ST16000* find / -name "ST16000*" I found this which matched the failed drive: /tmp/disklocation/smart/ST16000NT001-3LV101_ZRS2371E.json I had Gemini interpret it, and it said The most critical information pointing to the drive's failure is found in the Extended SMART Error Log: Error Description: "Error: UNC at LBA = 0x480295be8 = 19330063336" UNC stands for Uncorrectable Error. This means the drive tried to read data from a specific Logical Block Address (LBA) on the disk and failed because the data was corrupted and couldn't be corrected using the drive's internal Error Correction Code (ECC). Log Details: Error Number: 1 (The first and only logged error). Lifetime Hours: 5448 hours when the error occurred. Error Count: 1 logged count.

I have a ST16000NT001 drive that was in my array, and failed. Unraid reported 2050 errors and shut the drive down and would not spin it up. I have replaced the drive in my array, and temporarily put the failed drive in another system to document the failure. It is in a USB3 UASP SCSI dock. The SMART metrics report it is now in perfect health. I ran a short self test using Hard Disk Sentinel and it passed. Are there logs in Unraid that contain more details about the disk failure while it was in the array? I found the new 7.2 log viewer, I see a variety of logs. I would think that faillog would be a candidate, but it is zero bytes: I looked in dmesg, and found hundreds of lines like this: Are there any more specific details logged anywhere? I ran Diagnostics and looked at the file. There is a directory in the archive named "smart" which has the 6 drives currently in the system, but not the one that failed. Are the "Smart" reports retained on the server anywhere?

Diagnostics: t440-diagnostics-20251201-1402.zip

Yesterday, I added a new Parity drive to my array, and it has been working on building parity on the new drive. Today, I see that one of the drives in the array has an "X" and the tip pops up as "Device is Disabled - click to spin up" I click it and see Disk 3 settings. There is nothing like "spin up" visible. On the Attributes tab I see this: Self-test tab looks like this. Still nothing about how to spin up. Edit: Here is the log for the drive: Edit2: If Disk 3 is dead, should I wait until the Parity 1 drive rebuild has completed before replacing, and thus starting a rebuild of Disk 3?