Unlocking Pool/Bug?

[markgca]

i recently spun up a new truenas server, been running another one for a few years
set up an encrypted pool, then set up replication to another pool in the same server
that worked ok after a few adjustments, but...

since the original pool/datasets were encrypted, the replications are encrypted with the original key. that makes sense.

but when i try to decrypt the individual datasets, they wont with the json file. it WILL work with the code FROM the json file.
that seems to be a bug? or is it? maybe i dont understand how the json file works

help?

 

[winnielinnie]

but when i try to decrypt the individual datasets, they wont with the json file. it WILL work with the code FROM the json file.
that seems to be a bug? or is it? maybe i dont understand how the json file works

Because the exported .json file (from the original pool) references the original layout and names of datasets/"encryptionroots".

You can unlock all datasets on the destination pool, and then export the keys (which will be saved as its own separate .json file.)

 

[markgca]

i knew there was a good explanation, thank you so much, makes perfect sense.

that begs another question; is there a way to avoid this? right now i have an encrypted pool replicating each of the datasets on that pool to another pool. is there any way to set up the target pool so as not to have each target dataset having their own json file (other than no encrypting the original pool)? i dont see how since each dataset is replicated separately, but thought i would ask. i dont remember going through this on the last truenas box, but that used geli encryption so it was probably totally different than this.
thanks for any help.

 

[winnielinnie]

It depends how you configured your Replication Task and your pool/dataset layouts.

I'd just be taking guesses at this point.

For what it's worth, I use my "pseudo-roots" method to avoid this type of thing. However, it might be too late for that, but something to consider for future reference.

Difficulty replicating native ZFS encrypted pool to new pool.

I'm preparing to move a series of datasets residing on one encrypted pool to another pool. This is primarily intended to be a move from a smaller pool of storage to a larger pool of storage, after which point I'll destroy the smaller pool. The source pool, tank, is set up with TrueNAS 12.0-R...

www.truenas.com

 

[markgca]

i like that idea vs what i have now which is about 15 root datasets....
im still in the early stages, so that can still be done; just need to redo the replications and snapshots.

one question; using the pseudo-roots will that add more character count to the directory listings? we are mainly using windows, i have some limitations now, and if i add any additional character count some of the file names will be too long and wont copy over (they were created with a single/short root dataset name, and this seems to add some length to that). its just in one area so i could likely do a work around...

 

[winnielinnie]

one question; using the pseudo-roots will that add more character count to the directory listings? we are mainly using windows

An SMB share's root begins from the directory being shared out. So I don't see how it will affect the character limit?

If you have on TrueNAS the dataset: mypool/zroot1/documents

Then under SMB Shares you share the directory: /mnt/mypool/zroot1/documents

A Windows client will not see anything before "/documents". The root of the share will begin after "documents/".

To give an example, if you configure an SMB Share named "Docs" for /mnt/mypool/zroot1/documents, and there exists a subfolder and file named "Legal" and "2022-tax-form.pdf", respectively, then it will appear like this to the client:

\\ip.add.re.ss\Docs\Legal\2022-tax-form.pdf


Take your time and be very careful with setting things up. One small mistake using encryption could result in losing your data forever.

 

[markgca]

perfect, that is very helpful

i think the issue i ran into was i attempted to copy large portions of the pools (in your example zroot1) that that added to the issue. but i dont have to do that, so this works.

thanks for the help, every time i bring up a new server i find new 'options' that make it better, but i dont do this enough to understand all the tradeoffs/best practices to make it work. but this forum with people like you are a lifesaver!