If ZimaOS 1.6.2 enters a reboot loop after a huge file operation and icewhale-files or icewhale-files-backup consumes several gigabytes of RAM, update to ZimaOS 1.7.1 or newer before applying permanent service masks. ZimaOS 1.7.1 officially fixed abnormal memory usage in certain file-operation scenarios.
The source report is still valuable because it documents the failure chain clearly: ~749,000 files were copied, file services grew to roughly 6GB combined on a 7.5GB RAM machine, swap reached almost 100%, and the server rebooted every 9–10 minutes. Masking the services stopped the loop—but also disabled the Files web app and Backup service.
Recognize the Memory-Thrash Pattern
Typical signals include:
- RAM almost exhausted;
- swap near full;
-
icewhale-filesamong the top memory users; - very high I/O wait or apparent system stalls;
- repeated watchdog-like reboots after large file-count operations.
Step 1: Update to ZimaOS 1.7.1 or Newer
The official ZimaOS 1.7.1 release notes explicitly lists a fix for abnormal memory usage in file-operation scenarios.
That is the primary current fix. The 1.6.2 workaround should not be your normal 2026 configuration.
Step 2: Measure RAM and Swap
free -h
ps aux --sort=-%mem | head
swapon --showConfirm whether file services are actually responsible before disabling anything.
Step 3: Check Recent Reboots
journalctl --list-bootsA repeating interval can help distinguish watchdog/reset behavior from random power loss.
Emergency Stop on an Old 1.6.2 System
If the server cannot remain up long enough to update, the source user stabilized it with:
sudo systemctl stop icewhale-files.service icewhale-files-backup.service
sudo systemctl mask icewhale-files.service icewhale-files-backup.serviceThis is an emergency recovery tactic. It disables important native functionality. After updating, remove the masks and test the current services normally.
Unmask After Recovery
sudo systemctl unmask icewhale-files.service icewhale-files-backup.service
sudo systemctl start icewhale-files.service icewhale-files-backup.serviceDo this only after the system is on a fixed/current release and you have enough stability to observe memory behavior.
Large File Count Is Different from Large File Size
749,000 small files can stress metadata/indexing far more than one 67GB video. When reproducing or reporting the problem, include both total bytes and file count.
NTFS/FUSE and Many Containers Add Pressure
The source machine also ran ~38 containers and several NTFS volumes via ntfs-3g. Those conditions are context, not proven causes. Avoid turning them into the root cause when the observed memory growth was in the IceWhale file services.
Do Not Add a Random MemoryMax as the First Current Fix
The source author suggested systemd MemoryMax= as a product improvement. On a current version, artificially capping the service can create new indexing or backup failures if the workload legitimately needs memory.
Update first, then measure. Only apply service limits when you understand the trade-off.
Keep AppData Off the Small System Drive
Memory thrash can create heavy temporary I/O. Current ZimaOS app storage guide recommends moving AppData to main storage.
The performance troubleshooting guide provides a wider resource checklist.
FAQ
Did ZimaOS 1.7.1 fix this memory bug?
It officially fixed abnormal memory usage in certain file-operation scenarios, which directly overlaps the source failure pattern.
Should I permanently mask icewhale-files?
No. Masking was an emergency workaround that disables Files and Backup functionality.
Why did swap make the server worse?
When RAM is exhausted, aggressive paging can generate heavy disk I/O and long stalls, especially while file services are already scanning or copying huge numbers of files.
What evidence should I collect if it still happens?
ZimaOS version, file count, transfer size, RAM/swap state, top memory processes, mount/filesystem types, and boot/reboot timestamps.
