TVsIan

Thank you! I had to shut the server down due to the issue that I think caused this in the first place, but the array appeared intact. Just to help anyone in the future - the Dell HBA330 and other cards based on the LSI SAS3008 have an issue with firmware versions older than 16.12. There are problems with SATA drives, and in Unraid this appears as a series of errors followed by the drive going offline. It may or may not appear in unassigned devices afterwards if it comes back online. It also puts the array in a weird state where it seems like it's trying to keep running despite 2+ drives being unavailable. The problem didn't show up when I was leaving Mint up for an extended amount of time, but the drives weren't mounted and it seems like writes trigger the issue. I'm fairly sure this isn't restricted to Unraid. I attempted to flash it with the generic firmware since Dell stopped updating it after 16.11, but Dell has a lock to prevent non-Dell firmware from being crossflashed onto it. The jumper to bypass that doesn't seem to exist on the HBA330 Mini and I didn't see any evidence the PCIe versions have it either. So I'm shut down until I get my hands on a replacement card, likely an H730/H730P that I'll run in HBA mode. My research before getting the hardware all said for Unraid or something like TrueNAS, use the HBA330 rather than a RAID card. I suspect the people who had success with that were running SAS drives. For the H730, I've seen mixed reports. Some "It may work now, but you'll have unspecified problems in the future," some "It works fine but SMART isn't available," and even "Everything works including SMART."

Not much, if anything. Maybe a couple of logs for my Docker containers. I suspect I would be absolutely fine using the data on the disk and ignoring the emulated disk. What would be the next step on that? I assume I can format the emulated disk and manually copy before adding the disk back to the array, but it there a better way? The filesystem on the emulated disk appears to be a loss anyway: would have junked entry "ply" in directory inode 1496476592 would have corrected i8 count in directory 1496476592 from 2 to 1 would rebuild corrupt refcount btrees. No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 Maximum metadata LSN (2135175357:1264576416) is ahead of log (0:0). Would format log to cycle 2135175360. No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Tue Mar 17 16:46:16 2026 Phase Start End Duration Phase 1: 03/17 15:08:55 03/17 15:09:01 6 seconds Phase 2: 03/17 15:09:01 03/17 15:09:04 3 seconds Phase 3: 03/17 15:09:04 03/17 16:46:02 1 hour, 36 minutes, 58 seconds Phase 4: 03/17 16:46:02 03/17 16:46:16 14 seconds Phase 5: Skipped Phase 6: Skipped Phase 7: Skipped Total run time: 1 hour, 37 minutes, 21 seconds

It's still running, but while I'm waiting I mounted the disk as an unassigned device and took a look, and at first glance it at least looks like my data is there.

That's possible, I didn't mount any of the other disks, but I was having a weird issue with them dropping out. Which I think caused this in the first place. I'll post the end of it when it's done. Right now it's a lot of "imap claims in-use inode (number) is free, would correct imap" and a few "badness in key lookup (length)." I'll let it keep running, but I'm guessing I may have to go to the physical disk and see if there's anything readable to copy from it.

Running it now. It's finding a LOT of problems that it didn't when I checked it with the disk in the array.

Ok, updated diagnostics with Disk 2 removed from the array. Main still says it's unmountable and there's no mnt/disk2 folder, though that may be normal behavior for an emulated disk. longserver-diagnostics-20260317-1339.zip

Ok, I'll hold off on doing anything else with it until we determine if that repair is doable or if I'll just have to manually salvage what I can.

Yes, I was running out of space recently and went down to one parity drive, with the expectation of moving to a new machine that could hold more drives and going back to 2 at that point. Correct. It still indicates that if I hover over it on the Main tab, but obviously it's not going to work in this state.

root@LongServer:~# fdisk -l /dev/sdh Disk /dev/sdh: 10.91 TiB, 12000138625024 bytes, 23437770752 sectors Disk model: ST12000NM001G-2M Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 16773120 bytes Disklabel type: gpt Disk identifier: 92B2D47B-E56E-4114-9AD2-2B6719D80C4D

Removed the partition in gnome disk management, but did not format and have not mounted the disk since. I did run TestDisk, but it didn't identify anything that looked like the partition, so I did not write any changes. Just restarted the server in Unraid, diagnostics are attached. If the array can be restarted and the parity recovered and/or rebuilt, that would be amazing. longserver-diagnostics-20260317-0955.zip

I did not attempt to mount the drive anywhere else. Before I saw that it was unmountable, I started the array in normal mode intending to rebuild. The rebuild started automatically, but there was a warning that Disk 2 was unmountable, and on the array status that drive had a red X rather than the green dot. Hovering over the drive said that the contents were emulated, and my system appeared to be functioning normally otherwise, my docker containers were running without problems. At that point, I cancelled the rebuild since I knew it being unmountable would not let it complete successfully. I stopped the array and restarted it in maintenance mode. The SMART diagnostics for Disk 2 were fine, so I ran the XFS file check. It attempted to fix it but failed. I tried again from the command line and got the same failure. In maintenance mode, there was no error message about the drive being unmountable, but it came back when I switched back to normal mode. My initial thinking at that point was format the drive and let it rebuild. But it did warn that formatting would lose the data, so I didn't proceed with that. When that wasn't getting anywhere, I shut down and rebooted from a Linux Mint image. I hoped that if I formatted the drive outside of Unraid, it would be treated like a new disk and I could add it in place of the now-missing Disk 2 to rebuild, since the contents would have been emulated. None of the drives were mounted while I was in Mint. I ran xfs_repair -n on the four drives showing XFS filesystems. None showed any errors that should have made them unmountable, and Gnome's disk manager showed an enabled mount button for all 4 (which I did not hit). My mistake was thinking the parity drive was also xfs and the one drive showing an unknown file system and no mount button was Disk 2 of my Unraid array, since I didn't see any reason it would be unmountable in Unraid but (theoretically) mountable in Mint. At this point I'm thinking I'll have to recreate the array with a couple of smaller disks that I have available, copy data via mounting in unassigned devices, then add the now-empty disk to the array and move onto the next. If I'm understanding the way Unraid stores files, I should be able to get at least 3/4 of my data from the 3 good drives and cache SSD, and maybe the rest if the failed drive can be mounted. For future reference if something like this happens again, if a filesystem is corrupted and unmountable, is there a non-destructive way to reset the disk? ie remove the disk from the array and start it with an emulated disk, format the disk in unassigned devices, then re-add it as if it were a replacement drive? Also fwiw, I'm still on 7.2.0 because I had an update fail on me a while back and was holding off on trying again. So if it was a glitch that may have been fixed since then, that's also on me. I'll post the diagnostics when I'm back in front of it and boot it up in Unraid again.

The actual drive was unmountable, but the emulated drive was running in its place. If I started the array in normal mode, my data was available, but that drive had a red X and on the array function screen it said it was unmountable. I tried an xfs repair both from the UI (while in maintenance mode) and the command line, but it kept failing. I knew rebuilding wouldn't fix that, which is why I didn't do a rebuild, and was trying to reset that drive so I could replace it with itself, basically. I didn't actually mount the other drives, though if I can get the bad data drive repaired and mounted, then I can rebuild the parity, hopefully.

So, I screwed up. I've been moving my server from an ITX case to a Poweredge R730xd. I was initially having trouble with drives cutting out, and one of my data drives wound up with a corrupted, unmountable file system. I tried several times to repair it, but it would always fail at the end. After a day or two of trying to get it mountable (the drive itself passed diagnostics, the XFS filesystem was just completely hosed), I figured that since the emulated drive was working, I'd boot into a different Linux, wipe that drive, and let Unraid treat it like a new replacement and rebuild. My mistake was not getting the serials of the drives first. On the five drives, I saw four XFS volumes and one unmountable unknown format. The four XFS drives seemed to pass a check, so I figured the bad drive was the unknown, and deleted the partition. Rebooted to Unraid and discovered it was the parity drive, and my array was now totally shot. I haven't mounted any of the drives since. I'm currently running TestDisk on the parity drive. It's found deleted FAT32, HPFS - NTFS, and FAT16 partition info so far, but it's still got 25% or so to go on the quick scan. Is there any hope it'll find the correct partition and let me restore it? If so, what format is the partition in? I assume the filesystem is something not normally readable, and as I recall gparted said it was a Linux partition. Failing that, is there another way to recreate the partition since the data should still be intact? I didn't format the drive, only remove the partition.

Ahhh, got it. Okay, so I'll give up on sound in steam for now.

I do (trying to use steam-headless on the connected display). Rebooting didn't work. After a series of uninstalls/reinstalls/reboots - if the sound driver is installed. amdgpu fails on boot. If it's removed, it starts working again after reboot. I can't get the sound driver and radeon-top installed at the same time. [edit] fwiw, I don't know if the sound driver was actually working - prior to rebooting, steam-headless still only showed the null sound device after adding /dev/snd restarting the docker. Post-reboot with just the sound driver, I couldn't get in to see if there was another sound device due to the amdgpu failure.