A September 2025 thread reported that the JBOD option was visible but not selectable in ZimaOS 1.4.4 and 1.5.0. An official Zima response confirmed that the implementation had usability problems and said users could temporarily use an older version or wait for the feature to be reimplemented.
That answer should not be copied forward as current advice. The current ZimaOS documentation again lists JBOD as an available storage configuration.
What Was True in ZimaOS 1.4.4 and 1.5.0
In the reported builds, the user could not select JBOD from the storage setup screen. The official reply treated this as a product usability problem rather than a disk-specific configuration mistake.
What Is Different Now
The current current ZimaOS RAID options describes JBOD alongside RAID 0, RAID 1, RAID 5, and other storage choices. It defines JBOD as a way to join several disks into one continuous volume and emphasizes that it does not provide RAID-style redundancy.
That means the old workaround—installing an older ZimaOS build simply to regain JBOD—should not be the default recommendation for a current system.
When JBOD Makes Sense
JBOD is useful when capacity and simplicity matter more than redundancy. It can combine disks without spending equivalent capacity on mirrored or parity copies.
The trade-off is important: JBOD is not a backup strategy. If the data matters, keep independent backups instead of assuming a multi-disk JBOD volume protects against drive failure.
If JBOD Is Still Unavailable
- Confirm the installed ZimaOS version.
- Check whether the disks are already assigned to another pool or filesystem.
- Review the current storage setup options rather than following the 2025 version-specific workaround.
- Do not downgrade a production storage server solely because an old forum post described a temporary implementation issue.
Current JBOD and Data Protection Context
The RAID 1 recovery workflow is a useful contrast because it shows what redundancy-oriented recovery looks like when data matters. The ZimaOS 1.5 changes provides version context for ZimaOS storage changes, while ZimaOS cloud integration is relevant when deciding which data in a non-redundant pool should also exist in another location.
Seagate's Seagate JBOD definition explains that JBOD can aggregate capacity but does not provide built-in RAID-style redundancy, and QNAP's QNAP JBOD behavior similarly describes linear JBOD as combined capacity with no disk-failure protection. Those definitions reinforce the key operational point: a current JBOD option may be valid for capacity, but it should not be presented as protection for irreplaceable data.
Bottom Line
The community post accurately described a temporary JBOD problem in ZimaOS 1.4.4/1.5.0. Current ZimaOS documentation once again presents JBOD as a supported choice, so use current storage guidance and treat the older downgrade suggestion as historical version context.
