Hi all,

I've recently started using unraid, and I'm fairly new to it all. I'm running unraid 7.1.4. I've been experiencing random system crashes that I can't find a definitive cause. After enabling syslog, and remotely sending logs to my primary pc, but it hasn’t turned up much. My googling led me to believe that since syslog doesn’t have any smoking guns, maybe the issue is hardware related.

I’ve checked hardware as best I can. I’ve noticed that the crashes seem to happen whenever a resource intensive job is going on or is just about to finish. It almost always happens. I’m using the server as a media server that runs plex and a variety of other docker containers. Last night, the server crashed at 0320, plex starts scheduled jobs at 0300. So I tried to replicate the system crash by writing a 5gb file to every drive simultaneously, but no crash.

This is a non exhaustive list of everything I’ve tried, but the issue keeps on keeping on.

·         Tested RAM (ddr4) with memtest for 24 hours, passed.

·         Changed RAM to different and known good hardware – used on an older gaming rig. Passed memtest, crashing continues.

·         CPU passed intel diagnostic testing (i9-9900k)

·         Multiple PSUs used with same results, currently using a new 1000w corsair, but also tried a known good 850w corsair, but the issue persisted.

·         Changed cache file format to XFS from BTRFS (some internet forums suggested that btrfs format can cause unexpected crashes )

·         Replaced the boot flash to a smaller 32gb usb2.0 drive (original was a large usb3 flash)

·         Within plex, changed scheduled job times – this seemed to help for about 24 hours, but then crashes resumed around the time of scheduled jobs as well as intermittently under high resource load.

·         Within plex, changed transcoder rules and write location (to ram, to cache, to array, back to cache, back to ram, no change, currently writing to cache).

·         Removed every single hard drive, precleared every drive all over again, increasing array one drive at a time to try and identify faulty drives. No change. Smart data indicates all drives are healthy, but hey why not.

·         Changed sata cabling (my logic here was maybe a wire was frayed/pinched internally and was causing some sort of read/write error – literally grasping for straws here)

·         Changed from onboard sata ports to hba cards.

·         Grasping for straws still – I even changed the power switch to see if maybe it was bad. Nothing.

The only thing I can think of now (with hardware) is something motherboard related. I’m using a gigabyte aorus gaming 7 on f15 bios. It IS a second hand unit, but bios voltages are consistently good and when I stress test the system as hard as I can with stress-ng, nothing. It just runs and runs until I make it stop, usually around 45 minutes or so.
I’m at a loss. I could replace the motherboard and cpu, but that’s an expensive fix that may or may not fix the problem. Anyone have any ideas? I’ve attached the most recently syslog output (from remote server, delimited with the "|" character for easy excel export) and diagnostics.

 

 

syslogsept112025.xlsx quasar-diagnostics-20250911-1130.zip

Please repost the log from the syslog server in txt format.

Sure thing, attached.

sept10_11 syslog.txt

On 9/11/2025 at 7:27 PM, sillygingr said:

. I've been experiencing random system crashes

what exactly means "crashes", system freeze or hard reboots ?

may i ask, what is this installation for ?

/boot/extra

total 48

-rw------- 1 root root 43944 May 27 2022 sshfs-3.7.3-x86_64-1.txz

I don't really notice any system freezes, it's more of a sudden hard reboot.

The "-rw------- 1 root root 43944 May 27 2022 sshfs-3.7.3-x86_64-1.txz" was an attempt at mounting a remote drive with sshfs. I ended up using a different method, but the problem was going on before that was installed.

Server rebooting by itself is almost always a hardware problem, since memtest is only definitive if it finds errors, and you have multiple RAM sticks, try using the server with just one, if the same try with the other one, that will basically rule out bad RAM.

Thank you, I'll give it a try this weekend and see if anything changes.

On 9/13/2025 at 6:23 AM, JorgeB said:

Server rebooting by itself is almost always a hardware problem, since memtest is only definitive if it finds errors, and you have multiple RAM sticks, try using the server with just one, if the same try with the other one, that will basically rule out bad RAM.

Okay, I have ruled out the RAM being bad. I tried four 16gb sticks of ram individually in all four slots, and the system still restarts unexpectedly.

On 9/14/2025 at 10:57 PM, alison2033 said:

⚠️ Unraid Crashes Caused by Hibernation/ACPI Settings

There's a BIOS feature that Unraid doesn't work well with when enabled. This feature is Hibernation (ACPI S3/Modern Standby).

I haven't given this a try yet, but it's next on my list.

However, I did try something last night with CPU pinning. I pinned Plex to specific cores/threads on a hunch, and surprisingly, the server did not reboot overnight. I don't mind keeping it this way if it prevents my system from rebooting constantly, but I wonder what the implications of this are? Does this indicate some sort of issue within the CPU itself being unable to handle a full load? I'm using an AIO with decent cooling, cpu temps idle at around 38 C - 40 C.

15 minutes ago, sillygingr said:

and the system still restarts unexpectedly.

PSU and board would be my next suspects, in this order.

5 minutes ago, JorgeB said:

PSU and board would be my next suspects, in this order.

Thanks, I tried multiple PSU with no change. I guess I'll bite the bullet and try a new board. I'll follow up in a few days when I have some more details. Thank you!

7 minutes ago, JorgeB said:

PSU and board would be my next suspects, in this order.

On 9/14/2025 at 10:57 PM, alison2033 said:

⚠️ Unraid Crashes Caused by Hibernation/ACPI Settings

There's a BIOS feature that Unraid doesn't work well with when enabled. This feature is Hibernation (ACPI S3/Modern Standby).

Why?

• The system shuts down almost everything (CPU, disks, peripherals).

• It only keeps the RAM powered to save the system state.

• When you "wake" the PC, it restores the RAM session.

Unraid Problem with S3:

What happens when S3 is enabled?

• SATA/SAS disk controllers don't always resume correctly.

• Disks may not "wake up" together, causing mount errors or even crashes.

• Network interface cards (NICs) sometimes don't restore the connection.

• Some plugins and containers crash because they expect the system to never completely "disappear."

How to fix: Go to BIOS → ACPI Settings (in Legacy BIOS or UEFI) and configure as follows.

Enable Hibernation: [Disabled]

→ Prevents the system from using hibernation.

→ If enabled, causes a crash when Unraid resumes.

ACPI Sleep State: [S1 only]

→ Allows only a simple low-power state (CPU Stop Clock).

→ Prevents S3, which causes crashes.

ACPI Sleep State: [S1 only]

→ Allows only a simple low-power state (CPU Stop Clock).

→ Prevents S3, which prevents crashes.

🖥️ On newer motherboards, only the following option may appear:

• [Disabled] → Disabling forces the use of S1 (CPU Stop Clock), which is stable and recommended.

• [Modern Standby Enabled] → Enables S0ix (Modern Standby), which doesn't work on Unraid.

• [S3 Enabled] → Enables Suspend to RAM (S3), but causes crashes upon resuming.

👉 When you select Disabled, the system automatically uses only the S1 state, the most stable and compatible.

• No additional configuration is required.

📌 Summary

• 99% of crashes reported by Unraid users are caused by this Hibernation (ACPI S3/Modern Standby) feature being enabled by default in the BIOS.

• Simply disabling it will resolve the issue.

⚠️ Of course: This applies as long as the hardware is in good condition:

• Hard drives/SSDs/NVMe without bad blocks or defects.

• Motherboard with stable SATA ports.

• Power supply with adequate real wattage.

 I'll actually try this first, THEN try a new board. 

1 hour ago, sillygingr said:

 I'll actually try this first, THEN try a new board. 

you can try, but thats more a matter when using sleep with your server, not when we talk about random hard reboots, but give it a try ;)

these are most likely

/ hardware issues "somewhere"

/ powersavings (also hardware which doesnt like something)

/ xmp, ram (also hardware which doesnt like something)

...

the wake from sleep is a different story, there its a matter how your bios may setup and how overall its handled by the hardware ... but when i understood your issue correctly, its more a sudden "hard reboot" in running state, either idle or load or ...

wish you good luck to figure it, sadly hard to debug ... always a trial & error game ...

Yes, It's been very difficulty to try and nail down a cause. You are correct, this is a sudden hard reboot, and the server doesn't go into a sleep state.

Thank you for the assistance. I'll see what else I can come up with. 

5 hours ago, alison2033 said:

If your server restarts on its own, it could be due to several factors.

1. If you use a UPS, test connecting it directly to the wall outlet.

2. Check that the server's power supply is working properly. If the power supply's power supply capacity exceeds the power supply's wattage, test another power supply connected directly to the wall outlet.

3. If you use a stabilizer, it doesn't work, connect it directly to the wall outlet, or use a UPS.

4. If you use a UPS, check that the wattage is within a safety margin. For example, a 1500VA UPS with a power factor of 0.6 = 900 watts, but leaves a safety margin of 800 watts maximum.

And remember to check the watts of your power supply to see if your APS supports it.

The calculations:

Computer power supply 500 watts

A 1500VA APS: you need to check if it's 0.5 - 0.6. If it's 0.6, it's like this.

1500VA x 0.6 = 900 watts

1500VA x 0.5 = 750 watts

1200VA x 0.6 = 720 watts

1200VA x 0.5 = 600 watts

Just multiply.

I'm fairly sure it's not a power supply issue. I've used three different power supplies, 500w, 850w, and 1000w. All 3 power supplies new and working fine, but the unexpected shutdown/restarts continued regardless of power supply. I was not using a UPS initially, but I am using one now. 
Ever since I pinned Plex to only use specific cpu/threads, there have been no unexpected shutdown/restarts. I've gone 4 days now without an unexpected shutdown/restart, that's the longest I've gone without it happening. I'm going to unpin Plex and see if I have a shutdown/restart tonight. 
I did purchase a new board to see if the problem persists after changing mobos. I'm confident the issue isn't the power supply since it continued across 3 different units with increasing wattage. 

Just to follow up and mark this as somewhat solved - after weeks and weeks and even a month or two of daily troubleshooting i finally found a solution. Pinning plex to avoid the first few threads of my cpu solved the problem entirely. I have no issues with daily crashes anymore, and I've gone almost three months continuous uptime without issue. I have not been able to determine what job or process that plex is using/running that was causing system crashes, but it's solved now with no noticeable impact to performance. Plex streams to multiple users without issue (locally and remotely) and all my other docker containers are running just fine. Notably, I have NOT pinned any of my other containers to specific threads/hyperthreads on the cpu and leave the system to use whatever resources it needs and everything is working fine.