as preparation for the change from core to scale, i have backup my plugin and jail, install the iso of scale 24.10.1 and imported my pool. As i realized that the config backup from Core 13.3 doesn’t work, i used the key i had also backup in my bitwarden. copied the text and paste it to open “tank” which is my pool’s name. and i got this error.
'/mnt/tank' directory is not empty (please provide "force" flag to override this error and file/directory will be renamed once the dataset is unlocked)
after looking up i saw this tread cannot unlock pool after upgrade from CORE to SCALE 24.04. pre-release. from what i got this should have bug should have been resolve for the full release many version ago. i have a very limited experience searching for bug report in the new system (was used to JIRA). but i didn’t find report like this.
on a second point. what impact will have if i flag “force” and directory will be renamed. what directory will be renamed? is it only some system directory that i don’t really interact with or it will be impacting my data folder structure?
sorry misstype that i meant that i do have a hex key like you said.
tank and its child are all locked with the exception of the following child that are not encrypted:
tank/Backup/Keven
tank/Backup/VBL-PC
tank/Windows_handbrake-06jlnd
This is likely the problem, throwing off the middleware.
In the past we could initially create an encrypted root dataset upon a new pool’s creation, with unencrypted children nested underneath. This has since been “fixed”.
Because your pool was likely created before this change was enforced in TrueNAS, you’re left with an “unsupported” (discouraged) dataset topology.[1]
In vanilla, upstream ZFS (without TrueNAS or a middleware in between), you can do this, as long as you understand the complications and risks involved.
I’m not sure what the “safe” approach is going forward for TrueNAS SCALE systems that carry over an older pool that break this enforcement.
If I was caught in this dilemma, I would export the pool, then boot into a recent Linux live ISO (from a USB stick), and then manually do a “shuffle” of the unencrypted datasets.
Import the pool in the live Linux session with the -N flag, to prevent it from automounting the unencrypted datasets
Create a checkpoint for pool tank
Rename tank/Backup to tank/Backup-plain
Rename tank/Windows_handbrake-06jlnd to tank/Windows_handbrake-06jlnd-plain
Do a full, recursive replication of the -plain datasets into new ones that will inherit tank’s encryption, and use the original dataset names
Confirm everything went well
Destroy the -plain datasets
Import the pool into TrueNAS SCALE
Discard the checkpoint if everything went well
That’s just what I, Winnie, would try to do! Don’t try anything without knowing what you’re doing.
Even on TrueNAS Core 13.3-U1, we can no longer create unencrypted datasets if the root dataset is encrypted. If you try, the GUI/middleware will stop you and print an error message with red text. ↩︎
thanks for the follow up @winnielinnie with sudo it did work.
I forgot a couple of nested/nested/nested datasets that are also NOT encrypted. all of them have been created because i zfs replication those datasets from my really old pool “vol1” which has been dismantled. Fortunately for me, all the datasets that are unencrypted are either very old backups from windows 7 days and backups of my old pool before i dismantle it, in case my data that has been merge into the same folder on the “tank” pool would create some sort of problem.
so basically i can delete all those redundant unencrypted datasets.
i’m not familiar at all with linux, so if i just boot back on TrueNAS CORE 13, go into the storage section of the GUI and delete all datasets that are unencrypted then boot back into TrueNAS SCALE. will this solve my problem?
