Pool marked as Legacy Encryption after Config Restore

[TempleHasFallen]

I recently went through the process of migrating all data from a legacy GELI pool to a new native zfs encryption pool that was also bigger.

Since there are hundreds of SMB/NFS/other shares, after renaming the new pool to the name of the old one and importing it via the GUI (where it was correctly recognized as a native zfs encryption pool), I restored the config file which was taken pre-migration.

While all shares and services work correctly, now the pool is marked as having legacy encryption.

Is there any way around having to export the pool, importing it and having to re-create the shares manually?

 

[TempleHasFallen]

Additionally, any new dataset that is created, is created as such with no way around it:

Meanwhile, it seems to be detected as native zfs encryption from CLI:

Code:

root@freenas:~ # zpool get feature@encryption
NAME          PROPERTY            VALUE               SOURCE
freenas-boot  feature@encryption  disabled            local
redacted      feature@encryption  active              local

Which is gathered from the fact that on another server, pools that are legacy encrypted with GELI are marked as "enabled" while native ZFS encryption is marked as "active".

Is there any way around to fixing this issue?

 

[winnielinnie]

Since there are hundreds of SMB/NFS/other shares, after renaming the new pool to the name of the old one and importing it via the GUI (where it was correctly recognized as a native zfs encryption pool), I restored the config file which was taken pre-migration.

Maybe this is why the GUI / middleware is confused?

Your config file has the old pool name as a pool imported via legacy (GELI) encryption.

I know it sounds tedious, but maybe with a new pool name, you can restore your config (which will likely show a missing/offline old pool), and then you change all references to the old pool name to point to the new pool name?

This does bring up an interesting issue with the whole concept of "backup and restore your config file."

 

[TempleHasFallen]

Maybe this is why the GUI / middleware is confused?

Your config file has the old pool name as a pool imported via legacy (GELI) encryption.

I know it sounds tedious, but maybe with a new pool name, you can restore your config (which will likely show a missing/offline old pool), and then you change all references to the old pool name to point to the new pool name?

This does bring up an interesting issue with the whole concept of "backup and restore your config file."

In my mind detaching the pool and importing it again (regardless of name) should work - however I'm trying to avoid it as much as possible as there are hundreds of shares to re-configure.

Any idea if the configuration could be changed manually to view the pool as zfs native encryption?

 

[winnielinnie]

Any idea if the configuration could be changed manually to view the pool as zfs native encryption?

Out of my comfort level and expertise. That would require editing the database config file, and could lead to worse problems.

How about this alternative approach, if it's still feasible:

Have the new pool use a new name (not the original pool's name.)

Import the legacy pool, original name. Leave the shares as they are (pointing to it.)

Export/disconnect this legacy pool. (Do NOT destroy data and UNCHECK the option about removing shares that use the pool.)

Now export the new pool.

Now re-import the new pool manually in the CLI to use the original name.

I haven't done this myself, and I'm not sure how safe it is with TrueNAS, being an appliance.

 

[Teeps]

I recently went through the process of migrating all data from a legacy GELI pool to a new native zfs encryption pool that was also bigger.

I'm trying something similar. Care to outline the steps you took? It seems as simple as exporting the old pool, removing the drives, adding new drives, creating new pool, and restoring the data. Was that your experience?