Recently forced to leverage the "new config" functionality due to multiple drive failures and I was unable to reimport my (WebUI created) zfs cache pool.

Errors in the logs after recreating the pool with the same everything (disks, pool type etc) were "no pool uuid”. It seemed the cfg created here after recreation of the pool in the webUI was null:

/boot/config/pools/<POOL NAME>.cfg

Luckily I was able to recover by grabbing the UUID from the CLI with:

zpool import -d /dev/disk/by-id

Then manually editing the cfg with the value.

Mostly myself to blame here as I've had "normal" cache pools in the past when I've ran this command and didn't cross my mind that the process wouldn't mirror that scenario.

Not sure if this is a fault in the way the pool is reimported when it already technically exists, or if something can be added to the workflow to accommodate this? Or, an option to exclude zfs pools from the "new config" workflow all together in the WebUI?

If not, I've documented the fix in case anyone falls foul to this in the future and saves them the headache!

Edited January 27Jan 27 by billington.mark
Use the right words

To recover a pool you just need to reimport it:

create a new pool with the same name and number of slots

assign the pool device(s) all together; this includes any zfs subpools. Leave the filesystem set to auto

start the array to import the pool

Did that, and the UUID was empty and it wouldn't work. Had to manually edit the cfg file for the pool and set it manually.

13 minutes ago, billington.mark said:

Did that, and the UUID was empty and it wouldn't work.

That should always work; if you can recreate it and it stil faisl, please create a bug report or new general support forum post and post the diagnostics after the attempt and before rebooting.