The Short Answer Changed as the Community Tested ZimaOS
The first replies treated ZimaOS as a minimal, appliance-style system without a traditional package manager. They advised against assuming that apt install or permanent edits to the base OS would be available. Docker and a Debian or Ubuntu virtual machine were proposed as cleaner isolation boundaries.
Later hands-on checks added an important correction: one participant found /usr/bin/mergerfs and mergerfs-fusermount already present on a ZimaCube, while no SnapRAID binary was found. Another participant identified the bundled mergerfs as an older version during boot-race debugging. The result was not “native installation is impossible,” but “manual host changes are unsupported and version-sensitive.”
Manual Binaries Worked but Carried Update Risk
One user built executables in WSL2, copied them to ZimaOS, and reported a working two-data-disk plus one-parity-disk arrangement. The mergerfs maintainer noted that static builds can simplify manual deployment, but container behavior depends on whether the runtime is rootful enough to expose the FUSE mount as required.
Community replies repeatedly warned that copying binaries into an immutable-style system creates maintenance work. OTA updates can replace or conflict with manual changes, and AI-generated Linux instructions contained mistakes during the user's experiments.
The Community Built a systemd-sysext Layer
A contributor then published a community systemd-sysext project for ZimaOS. Its purpose was to add mergerfs and SnapRAID as a separate extension layer rather than modifying the read-only base system directly.
A controlled ZimaCube Pro test confirmed that the layer loaded, exposed mergerfs 2.42.0 and SnapRAID 14.5, and could mount a disposable mergerfs pool. The tester created a file through the pooled path and verified that it appeared on the underlying branch before unmounting cleanly.
That test did not include a full SnapRAID parity-and-recovery exercise. The tester also disabled the default timers and services before configuring anything so they could not act on real disks accidentally.
Two Boot Races Were Found and Corrected
After reboot, one user found that the pool sometimes failed while a manual start later succeeded. The extension author identified two separate races. First, the original guard saw the old mergerfs binary supplied by the base OS and started the pool before the extension's newer binary had merged. The revised guard checked for SnapRAID, which was provided only by the extension.
Second, mergerfs could return success before the physical branch disks were mounted, producing an empty pool that hid the later-arriving storage. A simple Restart=on-failure loop could not catch that successful-but-empty state. The project added explicit checks that wait for each branch mount and refuse to build the pool over a missing branch.
The author reported cold-reboot verification on ZimaOS 1.6.1 after these changes. A user with a four-disk TerraMaster enclosure also reported that the pool eventually appeared after the disks took close to a minute to mount.
SnapRAID Safety Still Requires Operator Review
The extension included a deletion threshold intended to stop synchronization after an unexpectedly large number of deletions. A later user questioned how to override that threshold after deliberately removing thousands of files. The thread did not close that operational question.
Anyone evaluating the project must review branch paths, parity paths, timers, deletion thresholds, and the location of application data before enabling automated jobs. A successful binary check or mergerfs mount is not proof that parity recovery has been tested for a production dataset.
Support Boundary
This is a community-built advanced integration, not an IceWhale-supported ZimaOS storage feature. Docker, a full Linux VM, static binaries, and sysext each have different privileges and persistence characteristics. The thread's strongest result is the tested extension method, but it should still be evaluated on disposable storage before any live data is introduced.
FAQ
Is mergerfs already included in ZimaOS?
A participant verified a mergerfs binary on their ZimaCube. The thread later identified that base copy as an older version, so its presence does not guarantee compatibility with a modern configuration.
Was SnapRAID recovery fully tested?
No. The controlled test verified installation and a disposable mergerfs pool, but explicitly stopped short of a complete SnapRAID parity and restore test.
Why was waiting for a failed service not enough?
One race could produce an empty pool with a successful exit code. Because that was not a failure, a restart-on-failure rule alone could miss it.
