Community Solution

Move Existing RAID or ZFS Pools into ZimaOS: Import/Export Safety Limits

A ZimaOS 1.6.1 user migrated a healthy mdadm RAID5 with Btrfs metadata from another Linux system and reported Storage UI errors, missing device nodes, and no documented GUI workflow for safely adopting or exporting the foreign pool.

This thread is an advanced storage-migration failure report, not a supported import recipe. The source array assembled at the Linux kernel level, but ZimaOS's Storage layer did not adopt it cleanly and the user encountered a persistent UI error.

Kernel-Level Array Detection Does Not Equal ZimaOS Management

A Linux system can recognize RAID metadata or a filesystem while an appliance-style storage manager still lacks the lifecycle state needed to manage that pool safely. The RAID recovery workflow shows the safer ZimaOS principle for arrays it already understands: preserve existing RAID metadata and avoid recreating the array as a first step.

OpenZFS Has an Explicit Export and Import Lifecycle

The official OpenZFS pool export says exporting a pool unmounts its datasets and marks devices as exported so they can be moved and imported later. The OpenZFS pool import explains how another host discovers and imports available pools.

Current ZimaOS developer documentation also exposes ZFS CLI operations, including zpool export. That is not the same thing as a general GUI wizard for importing arbitrary mdadm+Btrfs, native Btrfs, and ZFS pools.

Current Public Docs Do Not Document a Universal Foreign-Pool Wizard

The current Storage wizard focuses on creating and managing ZimaOS storage, while the public ZFS developer guide documents manual ZFS operations. If your actual goal is moving managed ZimaOS data to new storage rather than adopting a foreign array, the ZimaOS data migration is the safer current path. The ZimaOS backup workflow should be part of the plan before destructive storage work.

Do Not Force Import Recovery Flags on the Only Copy

OpenZFS warns that forced or recovery imports can discard recent transactions or otherwise be hazardous. Do not experiment with recovery flags or destructive reformatting on the only copy of important data.

Bottom Line

The 1.6.1 community failure shows why a kernel-recognized foreign array is not automatically a ZimaOS-managed pool. ZFS has a defined export/import lifecycle, but current public ZimaOS docs do not document one universal GUI workflow for adopting every foreign RAID/filesystem combination.