Since I upgraded to 7.3.1, every ~4 days, always at around 2am, my server just quietly drops off the network. I cannot access the GUI, all my dockers go offline, I cannot SSH in. The only solution is to manually power off the machine and reboot. It then stays online for about a few days before it happens again. I attach my syslog, recorded using the syslog server. As far as I can see, absolutely nothing appears to be happening before it drops offline.

I've set a notification on my router for when the server drops offline, and the dates it has fired are:

10th June, 02:27 (I manually rebooted at 15:40)

6th June, 02:58 (I manually rebooted at 08:59)

2nd June, 02:19 (I manually rebooted at 18:36)

31st May, 02:16 (I manually rebooted at 07:57)

I started the syslog server after that one, but it also happened before that:

29th May, 02:19 (I manually rebooted at 08:25)

28th May (I don't have a record of the time, but after this I set the notification of when it goes offline)

I see a few other posts with a similar issue but there always also seems to be some other related issue.

Can anyone help with diagnosing this? The system has been stable for a year or so before this issue. syslog-192.168.4.200.log

Attach Diagnostics ZIP to your NEXT post in this thread.

Diagnostics attached as requested.

chriscloud-diagnostics-20260611-0126.zip

4 hours ago, Yakuza965 said:

every ~4 days, always at around 2am

What do you get from command line with this?

cat /etc/cron.d/root

root@ChrisCloud:~# cat /etc/cron.d/root

# Generated system monitoring schedule:

*/1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

# Generated mover schedule:

40 3 * * * /usr/local/sbin/mover start > /dev/null 2> >(logger -t move)

# Generated Unraid OS update check schedule:

11 0 * * 1 /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null

# Appdata.Backup cron settings

0 03 * * * php /usr/local/emhttp/plugins/appdata.backup/scripts/backup.php > /dev/null 2>&1

# Generated schedule for Mover Tuning move:

40 3 * * * /usr/local/emhttp/plugins/ca.mover.tuning/mover start |& logger -t move

# Generated cron settings for docker autoupdates

0 3 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateDocker.php >/dev/null 2>&1

# Generated cron settings for plugin autoupdates

0 2 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1

# CRON for CA background scanning of applications

28 * * * * php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1

That look OK.

Why did you decide to use a docker folder instead of docker.img?

I did that quite a while ago but I think I’d either run out of space on the docker image a few times, or it’d got corrupted a few times, or both - and I just thought the folder might avoid that.

Sometimes docker folder seems to cause more problems that it solves.

And running out of space on docker.img either means you have an application writing to a path that isn't mapped, or your dockers really do require a larger docker.img depending on how many and what applications.

Not clear that is the cause of your problems though.

The usual advice is to disable Docker and VM Manager in Settings, and also start in SAFE mode to eliminate plugin problems. Run as just a NAS for a while and if it still crashes probably a hardware problem.

Been having the same problem in the last week.

1 hour ago, Window said:

same problem

Start your own thread with your Diagnostics.

This definitely only started with 7.3.1. I've run every version up to that upgrade and it has been stable. I'm going to see if I can capture any more detailed logs etc when it freezes next. If that yields anything helpful then great. If not I'm going to downgrade to 7.3.0 and see if it stops happening.

Edited June 11Jun 11 by Yakuza965

The server hung again in the same way this morning at 0249. I managed to capture the ACPI BERT reports from the last two freezes - I saved them directly after forcing the system to reboot. I've downgraded to 7.3.0 as an experiment and will see if it continues to happen.

bert-2026-06-12-0730.txt bert-dump.txt

Edited June 12Jun 12 by Yakuza965

I eventually tracked this down - as you predicted - to a hardware failure. Specifically, two cores on my CPU (an Intel 14500) that were failing to respond and bringing down the whole system. I managed to capture the efi-pstore DMESG error messages, which included lines like this:

<0>mce: CPUs not responding to MCE broadcast (may include false positives): 4-5
<0>mce: CPUs not responding to MCE broadcast (may include false positives): 4-5
<0>Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
<0>Shutting down cpus with NMI

I manually disabled those specific cores, which made the system stable again for 5 days where it had previously silently frozen every couple of days. Then I replaced the CPU entirely. The system has been stable for 2 weeks and the old CPU is with intel for replacement under warranty.

Sharing in case it helps others who have trouble with Intel CPUs down the line Thanks for the help in tracking it down.