Bottom Line: First Decide Whether ZimaCube Lost Networking or the Whole OS Froze
“It disappeared from the router” sounds like a NIC problem, but the thread eventually produced a stronger clue: with a monitor and keyboard attached, the screen was visible yet the machine would not respond to keyboard input. That is a system freeze, not merely a missing DHCP lease. Troubleshooting changes completely once you make that distinction.
Use a Local Console Before the Next Failure
Leave a monitor and keyboard attached temporarily. When remote access dies, test the console before power-cycling. Try the ZimaOS console keys and see whether the screen updates or accepts input.
If local input works but the router no longer lists the device, focus on Ethernet, DHCP and the network service. If local input is also dead, capture the screen and treat the incident as an OS/kernel/hardware hang.
Use uptime to Tell a Reboot From a Hang
uptime
last -x | head
journalctl -b -1 -p warning..alert
journalctl -b -1 -kAfter recovery, uptime tells you whether the server actually rebooted. Previous-boot logs can reveal kernel faults, storage timeouts, OOM kills or driver errors before the forced power cycle. The previous-boot logs covers journal boot selection.
Do Not Assume the Router's Night Schedule Is the Root Cause
Several users disabled Wi-Fi schedules or router reboots and still reproduced the outage. That makes “the router turns Wi-Fi off” an insufficient explanation. The server was wired, and later incidents occurred during the day as well. Keep router events in the timeline, but require a reproducible correlation before blaming them.
Check the Current Ethernet State After Recovery
ip addr
ip route
ethtool YOUR_INTERFACE
dmesg | grep -i -E 'link|ether|nic|reset|timeout'Current ZimaOS exposes physical Ethernet link state, negotiated speed and assigned IP separately. If the next incident is network-only, compare the router's port state with the local interface state. The ZimaOS network interfaces provides the current network controls.
If the console still accepts commands during a network-only incident, ethtool can expose link state, negotiated speed and driver information without rebooting. The ethtool network checks help separate a live OS with a dead link from a complete machine freeze.
Do Not Use Repeated Hard Resets as Normal Recovery
Holding the power button several times a day risks filesystem and database damage, especially during large transfers or RAID activity. If the console is frozen and there is no graceful shutdown path, one forced power cycle may be unavoidable—but gather evidence before it whenever possible.
The ZimaOS backup is especially important while diagnosing intermittent system hangs.
Reduce Variables During the Stability Test
Temporarily stop nonessential apps, disable unnecessary USB/PCIe devices, keep one known-good Ethernet path and avoid simultaneous multi-terabyte migrations. If the freeze disappears, reintroduce workloads one at a time. This is far more informative than changing router, client, storage and app settings all at once.
The ZimaOS recovery provides the current system-recovery boundary if stability testing exposes a bad system slot or install.
Historical 1.2.x Reports Should Not Be Applied Directly to ZimaOS 1.7
The thread belongs to 2024 and IceWhale was actively fixing stability cases in the 1.2.x line. Current ZimaOS has moved through many kernel, network, memory, storage and file-service changes. Use the thread to learn the diagnosis method—console vs network, reboot vs hang, logs vs guesses—not to claim that every modern overnight disconnect is the same 2024 bug.
When to Suspect Hardware
If a current stable release still freezes with minimal apps and known-good storage/networking, run memory diagnostics and inspect temperatures, power, PCIe devices and disk/controller errors. A repeatable complete freeze under different OS/network conditions can move the investigation below ZimaOS itself.
The ZimaCube 2 platform is useful when separating an original ZimaCube hardware case from later platforms.
FAQ
Why does ZimaCube disappear from my router?
It can be a network-only failure, a reboot or a complete system hang. Test the local console and previous-boot logs before deciding which.
Can disk standby make the whole ZimaCube disappear?
Disk standby should not be assumed to suspend the entire server. If keyboard input and networking both stop, diagnose a full system freeze instead.
Should I schedule a nightly reboot?
A scheduled reboot may hide an instability but does not identify the cause. Use logs and controlled testing before making rebooting the permanent workaround.
What should I collect before hard-resetting?
Photograph the console, test keyboard response, note router link/DHCP state, record the time, and after reboot collect previous-boot kernel and warning logs.
Could large file transfers cause the freeze?
They can expose storage, memory, driver or thermal problems, but the transfer itself is not a root cause without supporting logs. Reproduce with controlled workloads.
