Asus (formerly Intel) NUCs weren't designed for use as a 24/7 server, though they see enthusiastic use as such. Some users report instability. And while some of that can be bad RAM or a faulty motherboard / CPU, some can also just be configuration issues. And some is plain heat.
It's a little tough to nail it down. Here are some good practices to follow, to have a stable NUC.
Particularly if it's an older NUC, upgrade the BIOS. These are now hosted by Asus and may be a little hard to find for older models.
- Get your model number / SKU. For example, NUC10i7FNH
- On the ASUS download center, look for the Model search box and enter the model number.
- On the right side of the page the model number will show up, with options underneath. Click on "Drivers and Tools"
- On the next page select "Bios and Firmware"
User DagoDuck says this about NUC11 firmware: "For the TNTGL357 BIOS (NUC 11), if you're below version 0071, you first have to update to 0071 before being able to apply the latest update (newest version atm is 0077).
To obtain the file for version 0071, you have to modify the URL of the download link, as the older version isn't referenced anywhere on the ASUS website."
The NUC 14 Pro BIOS for example is here: https://www.asus.com/displays-desktops/nucs/nuc-mini-pcs/asus-nuc-14-pro/helpdesk_bios?model2Name=ASUS-NUC-14-Pro-Kit
The default setting for these is "broil". That means the fans run a lot, which can lead to dust build up inside until airflow is completely blocked.
Cleaning this requires removing the board so the fan assembly underneath is accessible. While you're in there, carefully remove the CPU heatsink, clean it with cleaning alcohol, then apply fresh thermal paste.
You can check heat by using smartctl. Install smartmontools:
sudo apt update && sudo apt install smartmontools
Then run sudo smartctl -x /dev/nvme0n1 and look for the temperature of the drive. It should be below 60C so it does not throttle, and ideally below 50C. "Temperature" is a computed value; "Temperature Sensor 1" is the NAND flash memory temperature; and "Temperature Sensor 2" is the flash controller temperature.
If your NUC has room for it, you can add a low profile heatsink to the NVMe. Or use a thermal pad between the NVMe and the casing. This can drop NVMe temperature by 5-10 C.
Setting the power level / limit to something less aggressive is generally better for 24/7 running.
First, find the data sheet for your CPU, simply by googling the CPU model. Here's the one for an Intel Core 5 125H.
In the data sheet, look for one of:
- Minimum Assured Power
- TDP down
- TDP low
- TDP min
Boot the NUC and press F2 to get into BIOS.
Under "Power", you'll find "Package Power Limit 1", or possibly simply "Power Level 1". Set that to the min value you found, which is specific to the CPU. For this specific CPU, 20W.
Then, set "Package Power Limit 2" to the nearest number that's 1.25x to 1.3x that. In this example, that'd be 26W.
And that's it for controlling heat.
Some models of NVMe drives (example Samsung 990 Pro) can cause the system to lock up when the drive enables power savings. This can be cured by changing the kernel startup parameters.
sudo nano /etc/default/grub
Find the line GRUB_CMDLINE_LINUX_DEFAULT. Add to it, keeping what's already there: nvme_core.default_ps_max_latency_us=0 pcie_aspm=off. Save the file with Ctrl-X.
sudo update-grub, then sudo reboot
This keeps the drive from entering powersave states by itself
The NUC 11, 12 and some models of 13 use the I225-LM/V Ethernet chip.
There are some reports that the Ubuntu 22.04 kernel can cause the Ethernet driver for the Intel I255-LM NIC to lock up. Maybe also the I255-V, reports are mixed. Other models such as the I256-LM/V on NUC14 and later are fine.
There are also reports that this resolved after a BIOS update and updating the kernel by either using the hwe kernel package with sudo apt install --install-recommends linux-generic-hwe-22.04 or by
upgrading to Ubuntu 26.04.
Debian 13 is also reported stable.
The BIOS update is key, we also have reports of the new kernel alone not resolving the issue.
Some users side-stepped the issue entirely by using an Ethernet USB dongle instead of the built-in Ethernet.
There are reports that the hangs with the I255-LM/V are caused by power management. Only take these steps if a BIOS upgrade and kernel upgrade did not stabilize the NIC.
In BIOS, disable Wake on LAN, if you can. Then change the kernel startup parameters.
sudo nano /etc/default/grub
Find the line GRUB_CMDLINE_LINUX_DEFAULT. Add to it, keeping what's already there: pcie_port_pm=off pcie_aspm=off. Save the file with Ctrl-X.
sudo update-grub, then sudo reboot
This keeps the NIC from entering powersave states.
All consumer RAM can fail, and it'll do so silently. The symptoms can range from corrupted data to the NUC "freezing".
To rule out (intermittently) faulty RAM, donwload memtest86+, flash it to an USB stick, boot from that USB, and run a continuous loop memory test for 5 days (!) or until you see errors, whichever is earlier.
If no errors were seen after 5 days, the RAM is probably fine.
A single run, or even 5 runs, of the memory test, are inconclusive. RAM failures can be quite intermittent.
This one requires a bit of sleuthing, and I'd only go there if the machine remains unstable despite everything else having been checked and corrected, such as BIOS version, kernel version, BIOS power level and clogged heatsink, and kernel settings/parameters. That said: Your "not-server-related" hardware in the NUC might cause trouble. In one case, disabling the sound card on a NUC11 stabilized it.
Start with an lspci -nn and identify hardware that is extraneous to requirements. Sound card and old WiFi are prime suspects.
Note that most everything on your NUC is required, and you don't want to mess with it. Your Intel VGA video output, various USB, Host, PCI, SMBus, ISA, Serial, SATA, RAM &c controllers and bridges: Leave those alone.
Once more: Take care. If you remove required hardware, your machine may no longer boot, or you're unable to log in.
What you are looking for is audio, and possibly WiFi if it's very old. For those you'll get a name, and two hexadecimal numbers shown as [<vendor>:<device>], like so:
00:1f.3 Audio device [0403]: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller [8086:a0c8] (rev 20)
Your exact output will vary. What you want here are the hexadecimal numbers identifying it.
Now, create yourself a rule to remove this device when scanning the PCI bus: sudo nano /etc/udev/rules.d/00-remove-audio.rules and place into it:
# Remove Intel Audio
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x8086", ATTR{device}=="0xa0c8", ATTR{remove}="1"
The {vendor} and {device} values must be the ones you see in lspci, with 0x prepended to signify "this is a hex number". The above is correct for that particular NUC11, but may not be for yours. Be sure to adjust this.
Do the same thing for /etc/udev/rules.d/01-remove-wifi.rules, if you have very old WiFi. NUCs come with AX200/AX210 generation, which are fine. Mine on an HP Z2 Mini G3 was a 8265/8275 and caused issues:
03:00.0 Network controller [0280]: Intel Corporation Wireless 8265 / 8275 [8086:24fd] (rev 78)
If WiFi is very old and did contribute to instability, removing it physically is often an option and easier than a soft removal. You may even be able to replace it with an AX200 or AX210 if you need WiFi.
Finally, sudo update-initramfs -u and sudo reboot, and verify that the offending devices are gone when running lspci -nn. On a NUC11 with audio removed, and WiFi and SmartCard reader still in place, it looks like this:
00:00.0 Host bridge [0600]: Intel Corporation Tiger Lake-UP3/H35 4 cores Host Bridge/DRAM Registers [8086:9a14] (rev 01)
00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01)
00:06.0 PCI bridge [0604]: Intel Corporation 11th Gen Core Processor PCIe Controller [8086:9a09] (rev 01)
00:07.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP Thunderbolt 4 PCI Express Root Port #0 [8086:9a23] (rev 01)
00:07.3 PCI bridge [0604]: Intel Corporation Tiger Lake-LP Thunderbolt 4 PCI Express Root Port #3 [8086:9a29] (rev 01)
00:08.0 System peripheral [0880]: Intel Corporation GNA Scoring Accelerator module [8086:9a11] (rev 01)
00:0d.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller [8086:9a13] (rev 01)
00:0d.2 USB controller [0c03]: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 [8086:9a1b] (rev 01)
00:0d.3 USB controller [0c03]: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #1 [8086:9a1d] (rev 01)
00:14.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller [8086:a0ed] (rev 20)
00:14.2 RAM memory [0500]: Intel Corporation Tiger Lake-LP Shared SRAM [8086:a0ef] (rev 20)
00:14.3 Network controller [0280]: Intel Corporation Wi-Fi 6 AX201 [8086:a0f0] (rev 20)
00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0 [8086:a0e8] (rev 20)
00:16.0 Communication controller [0780]: Intel Corporation Tiger Lake-LP Management Engine Interface [8086:a0e0] (rev 20)
00:17.0 SATA controller [0106]: Intel Corporation Tiger Lake-LP SATA Controller [8086:a0d3] (rev 20)
00:1c.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI Express Root Port #5 [8086:a0bc] (rev 20)
00:1c.6 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI Express Root Port #7 [8086:a0be] (rev 20)
00:1f.0 ISA bridge [0601]: Intel Corporation Tiger Lake-LP LPC Controller [8086:a082] (rev 20)
00:1f.4 SMBus [0c05]: Intel Corporation Tiger Lake-LP SMBus Controller [8086:a0a3] (rev 20)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP SPI Controller [8086:a0a4] (rev 20)
01:00.0 Non-Volatile memory controller [0108]: Sandisk Corp WD Black SN850X NVMe SSD [15b7:5030] (rev 01)
58:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader [10ec:525a] (rev 01)
59:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-V [8086:15f3] (rev 03)