I've run into quite the error with my server. Something seemed to have happened with my RAID card which is running in HBA mode.

I don't know if the card failed or the CPU did. Noticeable signs I'm running into is the CPU cores being pinned in the dashboard and the LEDs on the raid card are all flashing solid. I also cannot access files on my server. I honestly have no idea what exactly happened. It seems to have started with my UPS; however, I set it up to auto shutdown if it was on battery power for several minutes and the unit itself is new. I've only had it for a few months. (UPS was doing normal things. aacraid is the start of my problems.) Am I at risk of losing my data if I shutdown the server or reboot it?

Also, even though it seemed to have thrown some serious errors, my server did not inform me about them.

Edit: diagnostics scan seems to be taking quite a long time as well.

tower-syslog-20261006-0532.zip

Edited October 6Oct 6 by chris206

The syslog shows what happened. On Oct 4 at 06:37 the Adaptec controller stopped responding: the driver logged "Host bus reset request. SCSI hang?" and reported the adapter as unhealthy, with commands stuck inside the controller's firmware. There were no disk errors before this, and nothing from the UPS around that time. The last power event it logged was Aug 27, and its last self-test, on Sep 24, passed. So the UPS isn't what caused this.

When Linux tried to reset the controller, the aacraid driver itself crashed during the reset. The disks were never marked as failed, but nothing can be read from or written to them anymore. That's why files are inaccessible, the CPU looks pegged (processes stuck waiting on the disks) and diagnostics never finish. It's also why you didn't get a notification: no disk returned an error, so from Unraid's point of view nothing failed. Everything just stopped.

Rebooting won't make things worse. Nothing has been written to the array since Oct 4, and a power cycle is the only way to recover the controller. Anything being written at that exact moment may be incomplete, but your existing data shouldn't be affected. What I'd do:

1. Try a normal shutdown from the GUI. It will probably get stuck trying to unmount the disks. If it hasn't finished after about 10 minutes, hold the power button.

2. Unplug the server for a minute or so, so the controller fully resets, then power it back on.

3. Expect an unclean-shutdown parity check. Before starting anything, check that all disks show up and none are disabled. Then start the array and post the full diagnostics.

4. Enable the syslog mirror (Settings → Syslog Server → Mirror syslog to flash) so we get the full log if it happens again.

As for why the controller failed: these Adaptec cards run very hot and expect server-grade airflow over the heatsink. In a desktop case with no fan blowing directly on the card, overheating is a common cause, so check that first. If it happens again, I'd recommend replacing it with an LSI/Broadcom HBA in IT mode. That's what most Unraid users run, and it's much better tested with Unraid than the aacraid driver.

Should I bother with stopping the array first, or should I let the shutdown attempt to handle that?

The normal shutdown will try to stop the array, but I expect it will fail

2 minutes ago, JorgeB said:

The normal shutdown will try to stop the array, but I expect it will fail

Alright, started the shutdown process, it certainly seems stuck already after 90 seconds. I'll wait until 10 as suggested and do a force shutdown with the power button.

Forced shutdown, unplugged everything for several minutes and then powered it all back on.

All disks appear as they should, none are disabled.

As for the parity check, should I enable maintenance mode first? I figured I should uncheck "write corrections to parity". Is there anything else I should do before starting the array? Changing syslog to mirror was mentioned, would it be good to do that now before starting anything?

Also, I should add that the Adaptec card I have does have an audible alarm for chipset overheat. I had that happen when I first got the card before I hooked up a Noctua fan to blow directly on its heatsink. I hadn't had issues since then. Plus, I never heard it alarm ever in the last couple days. It's as loud as the alarm on a UPS and I'm fairly certain it would've woken me up as its in the room next door. I don't know if windows 11 and quick access being buggy in the days leading up to this crash was at fault. I was having issues removing folders on the server from quick access in windows explorer.

Anyways, below is the syslog from the reboot. It looks clean to me.

tower-syslog-20261006-1716.zip

The syslog looks good. The controller came back up normally, all disks were detected, and none are disabled.

Yes, enable the syslog mirror now, before starting the array. It takes effect immediately, and if this happens again we'll have the complete log.

No need for maintenance mode. Start the array normally, so you can also confirm all disks mount. Because of the unclean shutdown, Unraid will start a parity check automatically, and that check writes corrections, the "write corrections" checkbox only applies to checks you start manually. Since this followed a controller problem, I'd prefer a non-correcting check first: cancel the automatic one, then start a check manually with "write corrections" unchecked. If it finds no errors, or only a few that could be explained by writes in progress when the controller hung, you're fine. If it finds a lot, stop and post diagnostics before doing anything else.

After the array is started, please post the full diagnostics, and again after the check finishes.

About the cause: good that the card has a fan on it, and the overheat alarm not going off makes overheating less likely, though it doesn't fully rule out a heat or age-related problem on an older card. The Windows Quick Access issues wouldn't cause this. A client can't make the controller firmware fail. If those problems started after the morning of Oct 4, they were just a symptom of the hang, since the server couldn't answer any requests touching the array. For now, keep an eye on it. If it happens again, I'd recommend replacing the card with an LSI HBA.

Alright did as suggested and restarted the parity check with corrections off.

here's the diagnostics and syslog again.

Is there a way to sanity check that write corrections are off? I forgot how the GUI displays the type of parity check in progress.

tower-syslog-20261006-1751.zip tower-diagnostics-20261006-1247.zip

2 minutes ago, chris206 said:

Alright did as suggested and restarted the parity check with corrections off.

here's the diagnostics and syslog again.

Is there a way to sanity check that write corrections are off? I forgot how the GUI displays the type of parity check in progress.

tower-syslog-20261006-1751.zip tower-diagnostics-20261006-1247.zip

I restarted it after a few minutes for my own sanity. So, I should be okay.

Edit: checked syslog again and this time it showed up as "check nocorrect", so it was probably good that I stopped and restarted it.

Edited Tuesday at 05:59 PM5 days by chris206

Restarting it was the right call. The syslog shows the check you started at 12:49 was still a correcting one ("check correct"). The way you confirmed it is the reliable one: the syslog line check nocorrect means corrections are off.

Everything else looks good. The array started normally, all disks mounted without issues, and there are no controller or disk errors. SMART looks fine for all disks. Disk16 shows 14 uncorrected read errors in its lifetime error log, but no pending or reallocated sectors, and nothing related in the syslog, so just keep an eye on it.

Let the check finish and post new diagnostics when it's done.

Just now, JorgeB said:

Restarting it was the right call. The syslog shows the check you started at 12:49 was still a correcting one ("check correct"). The way you confirmed it is the reliable one: the syslog line check nocorrect means corrections are off.

Everything else looks good. The array started normally, all disks mounted without issues, and there are no controller or disk errors. SMART looks fine for all disks. Disk16 shows 14 uncorrected read errors in its lifetime error log, but no pending or reallocated sectors, and nothing related in the syslog, so just keep an eye on it.

Let the check finish and post new diagnostics when it's done.

Regarding disk 16, I've been wary of that drive since I got it. Those errors were present two years ago when I first precleared it if I recall correctly. I have four newer hotswap spares and I've considered swapping it out for one of them. There's not much data on it, so the copy wouldn't take much time.

It'll take about 22 hours to finish the parity check, so I'll post the requested information along with any updates around this time tomorrow.

Edited Tuesday at 06:15 PM5 days by chris206

On 10/6/2026 at 1:09 PM, JorgeB said:

Restarting it was the right call. The syslog shows the check you started at 12:49 was still a correcting one ("check correct"). The way you confirmed it is the reliable one: the syslog line check nocorrect means corrections are off.

Everything else looks good. The array started normally, all disks mounted without issues, and there are no controller or disk errors. SMART looks fine for all disks. Disk16 shows 14 uncorrected read errors in its lifetime error log, but no pending or reallocated sectors, and nothing related in the syslog, so just keep an eye on it.

Let the check finish and post new diagnostics when it's done.

Okay, took several more hours than I remembered it would, but parity-check finished with 0 errors.

As requested, I uploaded more recent diagnostics.

Now, one question I have is, would it be okay for me to turn off syslog mirroring? The documentation warns that it can wear out the usb drive faster if it's left running.

tower-diagnostics-20261007-1530.zip

The diagnostics look good. The non-correcting parity check completed with zero errors, and there are no new controller or disk I/O errors.

Yes, you can disable Mirror syslog to flash under Settings → Syslog Server now. Flash mirroring is intended for temporary troubleshooting because it adds writes to the USB drive.

For longer-term monitoring, consider remote syslog to another device, as described in the syslog server documentation. Without persistent logging, the normal syslog is lost after a reboot.

The clean check is reassuring, but the cause of the controller hang remains unknown. If it happens again, save the syslog before rebooting, if possible.