I think in general TrueNAS is meant to be used through the GUI/CLI/API. If you start going outside of that you are in uncharted waters as far as TrueNAS is concerned. I’d be worried that you are making changes that the rest of the TrueNAS system is unaware of and who knows how those two will interact. When it comes to data, and ESPECIALLY encrypted data, tread very carefully.
I haven’t tried so I don’t know. send|recieve is how replication is done behind the scenes, I only mentioned it to point out that ZFS can do what you are trying to do, but TrueNAS is throwing up an (confusing) error. So either TrueNAS has reasons not to let you do what you are trying to do – in which case they should have a better error msg – or it’s a bug. Even if the replication task did work after you instantiated the datasets through the command line, I would be worried that TrueNAS is now in an unexpected (by TrueNAS) state. Chances are everything will be ok, but when it comes to encrypted data, I suggest you not take any chances.
I needed the exact same setup, the workaround I went with was to create another dataset that inherited encryption and then place the replication destination in that dataset. So for your setup, you would create a new dataset backup/test_enc/xyz with xyz inheriting encryption from test_enc. Then setup your replication task as you did before except set the destination to backup/test_enc/xyz/data
I took a screenshot of this page before @Stux edited his post and removed everything.
For those that are curious, it was a 56-paragraph long essay about the history of traffic lights. He really likes traffic lights. Kind of weird, but whatever. I appreciate the passion.
Do you think it’s intentional, by design? Maybe there’s a reason for it that is related to TrueNAS SCALE (not ZFS) specifically?
EDIT: I’m not a programmer, but what is preventing someone from adding comments in the source code? Doesn’t it make troubleshooting much easier, since you can see the developer’s “thoughts” and intentions, while reading the code?
Am I wrong to believe that “too many comments” is better than “not enough comments”?
Could be but I don’t really see the rationale. That function (existing_parent_is_encrypted) is called when encryption inheritance is requested, so it makes perfect sense to make sure that SOME ancestor of the target is encrypted (so that there is somewhere to inherit encryption from). However, I don’t see any rationale for why you would require that it must be a grand-ancestor or earlier. Seems like having an encrypted parent should be perfectly fine. Furthermore, if you have a root dataset that is encrypted then this would prevent replication with inherited encrypted because there is no grand-ancestor, which just seems off. Finally, the error message (“but its existing parent is not encrypted”) strongly implies that having an encrypted parent is what is supposed to be tested for.
There is absolutely nothing that prevents a programmer from adding as much comments as they want. But getting programmers to properly document/comment code is a sisyphean task. Having said that, the code is pretty self-explanatory. I could totally see myself thinking that this code was very unambiguous and not in need of comments.
It’s two-fold, from what I meant. Even if you know exactly what is going on in the code, it would be helpful to understand the developer’s intentions.
Take for example your snippet, inserting a hypothetical comment:
<some code>
...
...
# We check for grandparent's encryption (two levels above target dataset) because of "reasons".
encryption = get_property(shell, os.path.dirname(parent), "encryption")
...
...
<some code>
With such a comment, at least you know this is by design. However, if the comment was something like # Get the encryption property for the parent of the target dataset, then it clues you in that this is likely a mistake. You might then think “Seems that the developer accidentally invoked os.path.dirname twice. Small oversight, but at least we know.”
