The UGREEN DXP4800+ is a nice little NAS. Compact enclosure, Intel Pentium Gold 8505, reasonable price. But mine shipped with two factory defects that turned a simple Unraid box into a thermal management headache that took me a week to properly diagnose.
This is the story of how I chased phantom fan controls, got fooled by virtual ACPI devices, and eventually fixed everything with thermal paste and a BIOS menu that requires a key combo nobody would ever guess.
The Symptoms
A few days after setting up Unraid, I noticed the CPU was running warm. Not alarming, but warmer than expected for an idle Pentium Gold. The fans seemed to have a mind of their own - or rather, no mind at all. They'd sit at a low speed regardless of CPU temperature. Light workloads would push the CPU into the high 70s. Anything sustained and it'd flirt with throttling.
Something was clearly wrong. Turns out, two things were.
Problem 1: Factory Thermal Paste
When I eventually pulled the cooler, the thermal paste coverage told the whole story. Roughly 40% die contact. The paste application from the factory was genuinely bad - uneven spread, large gaps, insufficient quantity. The heatsink base itself was fine (flat enough), but the paste job was like someone dabbed it on with a finger and called it a day.
This alone explained a good chunk of the thermal issues. But it wasn't the whole picture.
Problem 2: The ACPI Fan Control Lie
This is where things get interesting - and frustrating.
On the DXP4800+, the ACPI firmware exposes cooling devices that look like fan controls. You can find them, read them, write to them. They accept your values without complaint. They do absolutely nothing.
The fans are bound to the board temperature sensor (acpitz, which reads ~28°C at all times), not the CPU temperature sensor (coretemp). So the ACPI layer thinks everything is perpetually cool, and the fans stay low.
Here's what this looks like when you go exploring:
# Let's see what cooling devices exist $ ls /sys/devices/virtual/thermal/cooling_device*/type /sys/devices/virtual/thermal/cooling_device6/type /sys/devices/virtual/thermal/cooling_device7/type /sys/devices/virtual/thermal/cooling_device8/type /sys/devices/virtual/thermal/cooling_device9/type /sys/devices/virtual/thermal/cooling_device10/type # They all look like real fan controls $ cat /sys/devices/virtual/thermal/cooling_device6/type Fan # And they accept writes! $ echo 5 > /sys/devices/virtual/thermal/cooling_device6/cur_state # No error. Success! ...right? $ cat /sys/devices/virtual/thermal/cooling_device6/cur_state 5 # Value changed. Fans must be spinning up now. # Narrator: the fans were not spinning up.
The Script That Did Nothing
Like many DXP4800+ owners in the Unraid forums, I wrote a User Script to "control" the fans based on CPU temperature. It was a reasonable approach. It read coretemp, mapped temperatures to fan levels, and wrote those levels to the cooling devices. Clean code. Good logic. Zero effect on actual fans.
#!/bin/bash # This script looks correct. It runs without errors. # It does absolutely nothing to the physical fans. # Read CPU temperature CPU_TEMP=$(cat /sys/devices/platform/coretemp.0/hwmon/*/temp1_input) CPU_TEMP=$((CPU_TEMP / 1000)) # Map temperature to fan state if [ "$CPU_TEMP" -ge 80 ]; then FAN_STATE=9 # Maximum elif [ "$CPU_TEMP" -ge 70 ]; then FAN_STATE=7 elif [ "$CPU_TEMP" -ge 60 ]; then FAN_STATE=5 else FAN_STATE=3 # Low idle fi # Write to cooling devices (virtual ACPI, no physical effect) for dev in /sys/devices/virtual/thermal/cooling_device{6..10}; do echo "$FAN_STATE" > "$dev/cur_state" done # This logs correctly. Everything looks fine in the logs. # The fans haven't changed speed at all. echo "CPU: ${CPU_TEMP}°C → Fan state: ${FAN_STATE}"
cooling_device6-10 are virtual ACPI devices. They exist in the firmware's thermal zone tables, but they have no connection to the physical fan PWM signals. The DXP4800+ doesn't have an IT8613E chip (which is what the community UGREEN fan control tools target on other models). Writing to these devices is security theater for thermals.
The Eureka Moment
I spent an embarrassing amount of time convinced the script was working but "not enough." I tweaked thresholds. I added logging. I watched the values update in cur_state and couldn't figure out why the fan noise never changed.
The breakthrough came when I ran the fans at "maximum" via the script and held my hand over the exhaust. Same airflow as before. Then I set them to "minimum." Same airflow. The values were changing in sysfs. The fans didn't care.
That's when I checked what thermal zone these cooling devices were actually bound to:
# What thermal zone is the board sensor? $ cat /sys/class/thermal/thermal_zone0/type acpitz $ cat /sys/class/thermal/thermal_zone0/temp 28000 # 28°C - always. never changes. # And where's the actual CPU temp? $ cat /sys/devices/platform/coretemp.0/hwmon/*/temp1_input 72000 # 72°C - the real number. ignored by ACPI. # The ACPI firmware binds fan control to acpitz (28°C). # Board sensor says 28°C, so ACPI says "fans at minimum." # CPU is at 72°C and ACPI doesn't know or care.
The fans were never going to respond to those sysfs writes because the ACPI firmware was the one in control, and it was looking at the wrong sensor. My script was writing to the correct files, but those files were connected to nothing physical. A perfect illusion.
The Actual Fix
Once I understood both problems, the fix was straightforward. No scripts needed. No ACPI hacks. Just hardware work and BIOS configuration.
Step 1: Replace the Thermal Paste
Pulled the cooler, cleaned off the factory paste, and applied Arctic MX-6 using the spread technique (not the dot/pea method - the die is small and you want guaranteed full coverage). This alone dropped temperatures significantly.
Step 2: BIOS SmartFan Curves
Here's the part that nobody tells you: the DXP4800+ BIOS has proper SmartFan controls that read CPU temperature directly and drive the fans via real PWM. The BIOS bypasses the broken ACPI layer entirely.
Press Ctrl+F12 at the UGREEN logo, then select "Enter Setup." The usual keys - F2, Delete, Ctrl+F2 - do not work. This key combo is barely documented anywhere.
┌────────────────────────────────────────────────────┐ │ BIOS → Advanced → Hardware Monitor → SmartFan │ ├────────────────────────────────────────────────────┤ │ │ │ CPU SmartFan Control │ │ Mode ................. Smart Fan IV │ │ Start PWM ............ 75 │ │ Start Temp ........... 50°C │ │ Full Speed Temp ...... 50°C │ │ Extra Temp ........... 70°C │ │ Extra Slope .......... 80 │ │ Slope ................ 25 │ │ │ │ SYS SmartFan1 Control │ │ Mode ................. Smart Fan IV │ │ Start PWM ............ 75 │ │ Start Temp ........... 35°C │ │ Full Speed Temp ...... 40°C │ │ Extra Temp ........... 70°C │ │ Extra Slope .......... 80 │ │ Slope ................ 25 │ │ │ └────────────────────────────────────────────────────┘
These are aggressive curves - CPU fans hit full speed at 50°C, system fans at 40°C. The key insight is that the BIOS reads CPU temperature directly through the hardware, not through the broken ACPI thermal zone. This is the correct fan control mechanism for this board.
Step 3: Re-enable Turbo Boost
During my initial troubleshooting (before the repaste), I'd disabled turbo boost in /boot/config/go as a thermal workaround. With proper paste and proper fan control, turbo can stay on permanently. Removed the disable line from the startup script.
# Removed this line (no longer needed): - echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo # Turbo boost now runs permanently. # P-core boosts to 4.4 GHz, E-cores to 3.3 GHz.
Step 4: Delete the Fan Script
The ACPI fan control User Script got deleted. It was never doing anything. Good riddance.
Results
After the repaste and BIOS configuration, here's where things landed:
| Metric | Before | After |
|---|---|---|
| Idle temperature | 65-72°C | 45-50°C |
| Sustained load | 85-92°C (throttling) | 77-79°C (no throttling) |
| Cache scan spikes | 90°C+ | 77-90°C (brief) |
| Turbo boost | Disabled (workaround) | Enabled permanently |
| Fan control | Broken ACPI script | BIOS PWM (automatic) |
| User Scripts needed | 1 (useless) | 0 |
Repaste the CPU with a quality thermal compound (spread method), configure BIOS SmartFan curves via Ctrl+F12, and delete any ACPI fan control scripts. The BIOS handles everything correctly once you tell it to be aggressive about temperatures. No software fan control needed.
Lessons Learned
A few takeaways from this particular rabbit hole:
- Sysfs accepting writes doesn't mean it does anything. The cooling_device files happily accepted every value I wrote. They confirmed the writes with correct readbacks. They were connected to nothing physical. Always verify the actual effect, not just the interface.
- Check which thermal zone ACPI is actually using. The board temp sensor reading a constant 28°C while the CPU was at 72°C was the smoking gun. If your ACPI thermal zone is bound to the wrong sensor, no amount of userspace scripting will fix fan control.
- The DXP4800+ doesn't have an IT8613E chip. Community fan control tools for other UGREEN NAS models (which use IT8613E for Super I/O) won't work on the DXP4800+. Don't waste time trying.
- BIOS access keys are model-specific.
Ctrl+F12for the DXP4800+ is unusual and poorly documented. If your UGREEN NAS doesn't respond to F2 or Delete, tryCtrl+F12. - Factory thermal paste quality varies wildly. 40% die contact is not a manufacturing tolerance - it's a defect. If your DXP4800+ runs hot, a repaste should be your first step.
The whole experience was a good reminder that the gap between "software says it's working" and "hardware is actually doing the thing" can be enormous. Sometimes the fix isn't a better script. It's thermal paste and a BIOS menu.