CurlyBen

Annoyingly my server is half an hour away and I don't know if that drive is on a SATA-SATA cable or SAS-SATA! This might be a good time to rethink how I'm allocating drives anyway. A number of my array drives are 5+ years old now.

It looks like that might be what's happened, I've attached the diagnostics file but the key bit seems to be here and the read errors precede the write errors: The extended SMART test passed, so I think I'll re-enable the drive. I've ordered two new drives so when they arrive I'll retire this drive to be used as a bit of a dumping ground rather than part of the array. This is where I'd really like multiple arrays - a high value array with my irreplaceable data and newest drives, plus a second array with older drives, which may have thrown an error or two, but which only holds films, music and other replaceable media (but still with a parity drive so a single drive failure isn't a big deal). tower-diagnostics-20260213-0901.zip

Interesting. I've only got a CRC error count of 8, so nowhere near those numbers, but useful to know that I can't entirely discount them as the cause. From the notifications I've had the disk is disabled due to a read error rather than a write error. Hopefully the extended SMART test will throw a little more light on the issue!

Hi all I got a notification from my sever a couple of days ago that disk3 is in error state (disk dsbl), along with another notification stating that the array has 1 disk with read errors (disk3 - errors 16). I've run a short SMART test with no errors, and now the extended test is running. Looking at disk 3's attributes I see this: To my untrained eye nothing looks horrendously abnormal and none of the attributes has 16 errors. The only line that's highlighted is the UDMA CRC error count, but in my experience previously that's just issued a warning and not disabled the drive. Has the behaviour changed in UnRAID or do I need to keep looking for the cause of the disk being disabled? Cheers

I've just re-installed the file integrity plugin, as it had disappeared for some reason! However, I'm not able to select blake3 as the hashing method. I understand that it's disabled if the processor doesn't support it, but I still have the blake3 hashes from when it was previously installed so I can only assume the CPU does support it! It's an Intel 12600k. Is there another reason for blake3 to be disabled?

Hi all. A couple of times in the last week my server has become unresponsive - unable to login to the GUI or the dashboard only partially loads. After a reboot it's responsive but is showing 100% log file usage, which I think is what caused the unresponsiveness in the first place. The culprit is a 130mb log file called graphql-api.log, which appears to be related to the Unraid Connect plugin (see link and link). The log file seems to be mostly gibberish, with '\u0000' repeated thousands and thousands of times. It seems to have taken about 3 days for the log file to have grown to this size, and the first issue was about 3 days after installing Unraid Connect 2025.04.24.1328. Is this a known issue?

Update: after a reboot I was able to remove the pool and start the array

I've just upgraded to 7.0.0 and after rebooting I can't start my array. I get an error warning of invalid configuration of one of my pools ("backup - too many wrong or missing devices"). I created a pool some time ago to use for backing up my desktop and laptop. It was a single drive which was slightly suspect and it started to make strange noises so I removed it. Obviously the pool became unusable, but otherwise everything worked as normal. After upgrading to 7.0.0 it won't allow the array to start without a valid configuration for this pool. No problem, I'll remove the pool - but every time I click remove pool it takes me back to the main GUI page and the pool is still present and the array still cannot be started!

Does the Wallabag container need an external database? This article says that it should work without requiring changes to the template, but I get an error saying the database connection can't be established. The log file from my Wallabag installation is below:

Just for completeness, I rebooted my server today and the BIOS error messages had all gone. It's definitely not something I've come across before but at least it was an easy fix!

Fantastic, thanks a lot for your help (again!). It was actually sdd (my parity drive), I misread which device the error message related to. All seems to be fixed now though - I haven't tried a reboot though as I'm working away this week and I'd rather be there in case I need to attach a keyboard and monitor. It's certainly interesting that the BIOS checks this, but also a bit frustrating - I wasted a lot of time removing sticks of memory etc. as I assumed it was a hardware issue that was preventing it from booting.

Thanks, I ran fdisk -l and under /dev/sdc1 there's a message saying "the backup GPT is corrupt, but the primary appears OK, so that will be used". Presumably there's some way to overwrite the backup with the primary? It's an array drive so I'd rather not mess it up!

Sorry, I wasn't very clear! It's a message from the BIOS, almost immediately after turning on. I can't post a photo at the moment but it's very similar to the one I linked to above - obviously the processor details are different, but it's at that same point just after POST. I haven't received any errors from Unraid.

Today I finally got round to upgrading my server! I've gone from a 3570k to a 12600k on an Asus Z690 motherboard. However, when I boot I get a message stating that GPT header corruption has been found, and to check SATA mode or attempt to repair the boot sector (this isn't my computer, but the wording here is the same or very similar). If I enter setup and immediately quit then my server will boot and Unraid seems to be operating with no issues. However, it's a bit of a pain as I normally run the server headless, and I have to attach monitor and keyboard to be able to boot at the moment. Is there any way to check the GPT headers using Unraid? I don't want to run a tool that 'fixes' the headers only to make the drives unreadable to Unraid. I don't think there's any useful info, but I've attached my diagnostics file. tower-diagnostics-20221002-1634.zip

I'm about 95% sure the filesystem corruption didn't occur immediately - I think I was able to load some files from the emulated disk1 when I first started the array with disk1 removed. I could be wrong but I'm fairly confident that was the case I've run one parity check with all four drives in the array, no errors, and I'm about 75% through a second check with no errors so far. Are there any other steps that can help in the meantime? I'm considering running the Dynamix File Integrity plugin, although I've not yet read enough to fully understand how it works. I may also bring forward my plans to upgrade my server's hardware. I don't really have the budget for it at the moment but I don't have time to be dealing with data loss either! Does ECC memory prevent issues like this? (Assuming it is the memory) Thanks for all your help!