ZimaOS 1.6.0 introduced important storage changes, but this April 2026 community thread documented a difficult upgrade period for some users moving from 1.5.4. Reports included USB drives no longer auto-mounting, backup targets becoming inaccessible, ZimaOS-HD filling unexpectedly, some application failures, and ZVM web-interface problems.
The thread also contains the most important context: IceWhale acknowledged several upgrade defects, explained the USB-mount root cause, and released ZimaOS 1.6.1 with targeted fixes. This page should therefore be read as a historical upgrade incident, not as a description of current ZimaOS behavior.
What Users Reported After Upgrading to 1.6.0
The original poster reported two major problems after moving from ZimaOS 1.5.4 to 1.6.0:
-
ZimaOS-HDsuddenly appeared almost full even though application data had previously been migrated away; - external USB backup drives were detected but could not be enabled normally, making browsing and restore access difficult.
Other users added reports of missing USB storage, ZVM UI failures, apps failing to start, high CPU use, and systems that were difficult to manage after the upgrade.
IceWhale Acknowledged the Release Problems
777-Spider apologized for the slow response after the Friday release and said the team would change future release timing so support staff could respond more quickly to problems.
More importantly, the team said it had identified related issues and would release 1.6.1 urgently.
Official Root Cause: Missing Storage Fallback Metadata
On April 21, 2026, 777-Spider described the USB auto-mount root cause. ZimaOS 1.6.0 had introduced a storage fallback mechanism using a .zimaos_storage.json file. Beta testing did not fully reproduce the real upgrade path from 1.5.4, so some users upgrading directly lacked the fallback file needed for the new mount logic.
.zimaos_storage.json file used by the new storage fallback mechanism.The team said 1.6.1 added stricter validation and handling so the database data and fallback file state would be managed correctly during the upgrade path.
ZimaOS 1.6.1 Directly Fixed the Main USB Upgrade Problems
The official ZimaOS 1.6.1 release notes list these fixes:
- USB devices not auto-mounting after an upgrade;
- backup tasks continuing to write to the system mount point after the intended mount point was lost;
- mod-module services not starting according to service policy after reboot;
- mount-point names becoming inconsistent when device names contained spaces.
IceWhale's published list of fixes in ZimaOS 1.6.1
Why the Full System Disk Report Was Especially Serious
The 1.6.1 fix about backup tasks continuing to write to the system mount point after a lost target explains a mechanism that could turn a missing USB mount into system-disk consumption. Instead of writing to the intended external destination, a backup path could continue writing under the system mount location.
That connection is supported by the official 1.6.1 fix list and is much stronger evidence than simply assuming the 1.6.0 image itself was too large.
ZVM Problems Were Not All the Same Bug
One user reported VMs that would not start, while another said the VMs themselves were running and reachable over SSH but the ZVM web interface was stuck. A separate GitHub report traced one VNC console problem to custom ZimaOS WebUI ports not being included in the WebSocket URL.
Because those symptoms were different, do not summarize the entire thread as one “VMs broken” issue.
1.6.0 Is Historical, Not the Current Baseline
ZimaOS continued beyond 1.6.0 and 1.6.1. Use current release information before assuming an April 2026 upgrade defect still applies.
ZimaOS 1.6.0 Upgrade FAQ
Did IceWhale confirm a USB auto-mount bug in 1.6.0?
Yes. The team explained the storage fallback-file issue and shipped stricter handling in 1.6.1.
Did 1.6.1 fix backup jobs writing to the wrong mount point?
Yes. The official 1.6.1 notes specifically list a fix for backup tasks continuing to use the system mount point after the original mount point was lost.
Does this mean every 1.6.0 user lost storage?
No. The thread contains reports from affected users, not evidence that every installation failed.
Should this thread be used as current upgrade advice?
Only as historical context. Current ZimaOS releases and storage documentation supersede the 1.6.0 launch state.
