chris206

Parity check finished without errors. Everything's all good it seems.

Will do. It's scheduled to start tomorrow and is set up to increment, so I'll report back in a few days with results.

Done. tower-diagnostics-20260110-2152.zip

As the title states, the drives in my DAS didn't appear upon booting my server, because I failed to plug in the external cables correctly. I shutdown my server and the das, fully seated the cables and rebooted. All of my DAS drives show up now and short SMART tests of my two parity drives and disk 16 was completed without issues. These three drives are a part of my DAS along with the 4 12TB unassigned drives. The question I have is, should I proceed with caution still and start my array in maintenance mode to perform further checks? If so, what would those be? I'm due for a quarterly parity check that I've postponed for a week due to swapping hardware in the server. tower-syslog-20260111-0258.zip tower-diagnostics-20260110-2058.zip

To elaborate a bit further. My drives are actually connected to a SAS expander card, that is then plugged into the SAS raid controller. So perhaps the SAS expander had temp issues upon spinup? I need to recheck my drive positions in my tower, but based on previous notes it seems that the drive errors were spread across three different power splitters each on their own individual SATA power cable back to the PSU. Edit: Also, I should add, the 14TB drives and the 4 in unassigned devices are plugged directly into the RAID card through two of the external ports in a DAS.

I believe it should be in IT mode? I would not be surprised if it's setup wrong, I'm certainly an amateur.

Done. I often forget to include that one, thanks. tower-diagnostics-20251221-1506.zip

I am using power splitters. There should be a max of five drives on each SATA power cable if I'm recalling correctly. The SAS card itself has a noctua 40mm fan attached to it that is constantly spinning at ~3k rpm. I could certainly open up the back of my tower and trace each drive back to their respective power cable.

Today I decided to start using a different approach to managing my drives in my array. I thought I'd start spinning them down after an hour of no usage. This seemed reasonable until I ran into an issue when I opened windows explorer on my PC to access a local file which has a share folder from my array mapped as a network drive. I traced my array drives all spinning up to the opening of windows explorer. This led to five of my drives having four read errors each, which I assume was related to the drives not being fully spun up when explorer tried to access some data on them. My filesystem seemed to have some issues as I couldn't see any of the folders/files on the mapped network drive. I went ahead and stopped my array and started it back up, which unRaid reported as error free and the errors disappeared on the main tab in the GUI. I was also able to browse the folders properly after doing this. So, my primary question is, how can I prevent windows explorer from doing this in the future? I removed a network folder that had been pinned automatically to quick access by windows, but there's also a few files in the history of explorer too. Should I turn off indexing for the mapped network drive? Also, should I be concerned about those five drives throwing four read errors each and the filesystem not being accessible until I stopped and started it back up? tower-syslog-20251221-0439.zip

Finally reran xfs_repair through the CLI. The GUI for check filesystem doesn't seem like it'll refresh itself after taking the array out of maintenance mode. Anyways, I uploaded the output from the CLI. Seems like it zeroed the log and mentioned moving files to the lost + found, but I didn't see that folder on the disk after starting the array. Everything still checks out okay and that previous warning I was worried about is no longer there. Not entirely sure what caused the issue with reporting the remaining freespace, but I've got a new drive in my server, so hopefully it won't happen again. Thanks for all of the help. xfs_repair_log_20250824.txt

Alright, should I run that through the terminal as well or is the GUI fine? I don't remember having the ability to change flags in the check filesystem section for the disk's page.

Before this reply, I had gone ahead and started the array with a new disk, which is in the process of being cleared. Prior to that, I had checked several of the files on the disk and everything seemed okay. In addition, I managed to free up ~280 GBs of space by cleaning up some folders. If still recommended I can run that command after the disk clear is done tomorrow. Question though, I can't seem to find documentation on what -v flag is for xfs_repair, what's it do?

Hmm alright, I do get this message in the syslog, "XFS (md15p1): Per-AG reservation for AG 9 failed. Filesystem may run out of space." I'm guessing to resolve that I should move some files from that disk to another using krusader in order to free up space?

I also checked the filesystem on the drive and it seems to be back up without any lost+found files, so I'm not entirely sure what happened. Yesterday prior to the filesystem going down on the drive, I had roughly 1.8 TB of space left on it, so unless it stopped reporting the free space left accurately, I'm not sure how it managed to fill all the way up.

So, I stopped the array in maintenance mode and restarted the array normally. The disk mounted but said it was at almost 100% utilization. If I go back to the disk to look at check filesystem status, the repair hasn't reset at all and still has the same option before about zeroing the log. Any tips would be appreciated. tower-syslog-20250823-0232.zip

Alright, so now it mentions the log is dirty and wants to zero it, but it says I should attempt to mount the filesystem first to replay it? Some files were put into a temp folder while the filesystem was down, not many though. Could those be what this error message is referring to? Should I back out of this and try to restart the array as normal first before doing this next step?

Done. Shows that the File System is corrupted and gives the option to fix. Should I proceed?

Was moving some files to my server and it seems I ran into an XFS error at some point. XFS seemed to shutdown the filesystem intentionally. It seems it ran into an issue with a certain file, but I'm not sure entirely. I accidentally kicked the enclosure where my two parity drives are located at some point today, but I don't remember the exact time and if that lines up with the error. XFS was spitting out a lot of messages for the past 24 hours or more prior to that, so I'm uncertain if nudging the drives is related to the failure. My syslog is full of the messages about XFS and I didn't notice them before, so if there was a previous error, I can't seem to find it. For some context, I was able to browse the files from that disk earlier in the day prior to kicking it. None of the disks have failed out of the array either. Disk 15, the one with an invalid path, is in a different enclosure that wasn't affected by my blunder either. I ran a short smart self-test on the disk and it doesn't appear there was a major issue with it. I imagine an XFS repair will be needed, but I don't know exactly what steps to take first, so some guidance would be appreciated. syslog 20250822 0642.zip HUH721010AL42C0_2TJPHM8D_35000cca26a97d5c4-20250822-0115.txt

Thanks, I appreciate all the help I received. I've never had issues with mounting before, so I was at a total loss. I suppose the question is, how much should I investigate the cause of the initial failure? I think I may have a few files with filenames that are too long for the filesystem that may remain on the cache drive? I'm not entirely sure, I saw messages about them on the syslog before the drive had a bunch of write errors. So, I wasn't sure if that was the root cause of the issue.

Done. tower-diagnostics-20250516-1409.zip

So, check, "parity is already valid" and then start?

Alright, unmounted, created the new config, and swapped the two drives. Now, I should start in maintenance mode and check parity? How do I go about that without overwriting what's currently on the parity disks? I know it warns about overwriting the parity drives when the array is started. Also, I got this error: when creating the new config, should I investigate that first or ignore? tower-diagnostics-20250516-1323.zip

One last question before I proceed, should I expect to see activity for the mounting/unmounting of sds1 in its disk log information? I can see the failures from using the UD plugin yesterday, but nothing was logged from mounting via the webterminal? Is that normal/expected? For clarification, I opened disk log information from the drive symbol in unassigned devices. tower-diagnostics-20250516-1300.zip

Just to clarify, to unmount I should do: umount /dev/sds1 Do I need to remove the directory I created as well? Also, when I create the new config, should I preserve the current assignments and swap the old drive back in for disk 13 on Main? Wanting to clarify, before I make any missteps.

By new config, you mean placing it back into the array where it was originally? As for parity checking, I should start the array in maintenance mode and run a check through the CLI? If I can check parity before doing corrections I would probably prefer that. Also thanks, I greatly appreciate the help I've received.