Cannot zfs receive unencrypted dataset as a child of encrypted dataset ('cannot receive new filesystem stream: inherited key must be loaded') #13033
Comments
|
Yes, I can reproduce this. There are actually two issues here. The first one is with your sequence of commands. Since or or even Here comes the second issue into play, the above commands also fail with the same error message. This seems like a bug to me. The initial implementation of native encryption disallowed unencrypted datasets below encrypted ones. This restriction was removed in #8870 and it looks like As a side note, I think that nesting unencrypted datasets below encrypted ones is generally not a good idea, and I would try to avoid such a setup if possible. But I can see that here are setups that benefit from that. As a workaround you can do that works as intended but is less than ideal and may not be possible in certain scenarios at all. |
|
Thanks for the explanations and your testing. Actually, the scenario in my case is a backup with syncoid on a potentially untrusted low-performance backup-host, hence the idea to do a raw send ( I agree, that nesting unencrypted datasets under encrypted datasets is probably not a good idea in the first place, but since such configurations are possible, |
Unfortunately that's one of the scenarios where loading the key isn't an option, yes.
That's right, it should work seamlessly. Spotting the place where things fail is the hard part though ;-) |
|
By setting the module parameter Instrumenting that function with This means that the error starts in this part: That and sets goes on to retrieve the key, which is not loaded, so it errors out. |
|
I can confirm that removing the |
|
Well, in Since I'm new to this code please take everything I say with a grain of salt though. Edit: BTW I've come to this conclusion by dumping the nvlist with gdb. |
|
Nice, I think that should work! Do you want to go ahead and file a PR? |
|
Yes, I can do that, but before doing so I'd like to trace this a bit more to get a better understanding of the inner workings. That way I'd feel more comfortable changing the code. |
|
@gamanakis Feeling sufficiently sure that this is the right approach now, I'm preparing a PR and would like to give you credit for the analysis by adding you as a co-author. Is that OK with you? |
|
Sure, thank you! |
|
Opened PR #13076 with a fix. |
dmu_recv_begin_check() unconditionally sets the DS_HOLD_FLAG_DECRYPT flag before calling dsl_dataset_hold_flags(). If the key on the receiving side isn't loaded or the send stream contains embedded blocks, the receive check fails for a stream which is perfectly valid and could be received without any problem. This seems like a remnant of the initial design, where unencrypted datasets below encrypted ones weren't allowed. Add a condition to set `DS_HOLD_FLAG_DECRYPT` only for encrypted datasets, modify an existing test to detect this regression and add a test for raw replication streams. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Amanakis <gamanakis@gmail.com> Co-authored-by: George Amanakis <gamanakis@gmail.com> Signed-off-by: Attila Fülöp <attila@fueloep.org> Closes #13033 Closes #13076
dmu_recv_begin_check() unconditionally sets the DS_HOLD_FLAG_DECRYPT flag before calling dsl_dataset_hold_flags(). If the key on the receiving side isn't loaded or the send stream contains embedded blocks, the receive check fails for a stream which is perfectly valid and could be received without any problem. This seems like a remnant of the initial design, where unencrypted datasets below encrypted ones weren't allowed. Add a condition to set `DS_HOLD_FLAG_DECRYPT` only for encrypted datasets, modify an existing test to detect this regression and add a test for raw replication streams. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Amanakis <gamanakis@gmail.com> Co-authored-by: George Amanakis <gamanakis@gmail.com> Signed-off-by: Attila Fülöp <attila@fueloep.org> Closes openzfs#13033 Closes openzfs#13076
dmu_recv_begin_check() unconditionally sets the DS_HOLD_FLAG_DECRYPT flag before calling dsl_dataset_hold_flags(). If the key on the receiving side isn't loaded or the send stream contains embedded blocks, the receive check fails for a stream which is perfectly valid and could be received without any problem. This seems like a remnant of the initial design, where unencrypted datasets below encrypted ones weren't allowed. Add a condition to set `DS_HOLD_FLAG_DECRYPT` only for encrypted datasets, modify an existing test to detect this regression and add a test for raw replication streams. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Amanakis <gamanakis@gmail.com> Co-authored-by: George Amanakis <gamanakis@gmail.com> Signed-off-by: Attila Fülöp <attila@fueloep.org> Closes openzfs#13033 Closes openzfs#13076
dmu_recv_begin_check() unconditionally sets the DS_HOLD_FLAG_DECRYPT flag before calling dsl_dataset_hold_flags(). If the key on the receiving side isn't loaded or the send stream contains embedded blocks, the receive check fails for a stream which is perfectly valid and could be received without any problem. This seems like a remnant of the initial design, where unencrypted datasets below encrypted ones weren't allowed. Add a condition to set `DS_HOLD_FLAG_DECRYPT` only for encrypted datasets, modify an existing test to detect this regression and add a test for raw replication streams. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Amanakis <gamanakis@gmail.com> Co-authored-by: George Amanakis <gamanakis@gmail.com> Signed-off-by: Attila Fülöp <attila@fueloep.org> Closes openzfs#13033 Closes openzfs#13076
dmu_recv_begin_check() unconditionally sets the DS_HOLD_FLAG_DECRYPT flag before calling dsl_dataset_hold_flags(). If the key on the receiving side isn't loaded or the send stream contains embedded blocks, the receive check fails for a stream which is perfectly valid and could be received without any problem. This seems like a remnant of the initial design, where unencrypted datasets below encrypted ones weren't allowed. Add a condition to set `DS_HOLD_FLAG_DECRYPT` only for encrypted datasets, modify an existing test to detect this regression and add a test for raw replication streams. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Amanakis <gamanakis@gmail.com> Co-authored-by: George Amanakis <gamanakis@gmail.com> Signed-off-by: Attila Fülöp <attila@fueloep.org> Closes openzfs#13033 Closes openzfs#13076
dmu_recv_begin_check() unconditionally sets the DS_HOLD_FLAG_DECRYPT flag before calling dsl_dataset_hold_flags(). If the key on the receiving side isn't loaded or the send stream contains embedded blocks, the receive check fails for a stream which is perfectly valid and could be received without any problem. This seems like a remnant of the initial design, where unencrypted datasets below encrypted ones weren't allowed. Add a condition to set `DS_HOLD_FLAG_DECRYPT` only for encrypted datasets, modify an existing test to detect this regression and add a test for raw replication streams. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Amanakis <gamanakis@gmail.com> Co-authored-by: George Amanakis <gamanakis@gmail.com> Signed-off-by: Attila Fülöp <attila@fueloep.org> Closes openzfs#13033 Closes openzfs#13076
System information
Describe the problem you're observing
When receiving an unencrypted dataset as a child of an encrypted dataset,
zfs receivecomplains with 'cannot receive new filesystem stream: inherited key must be loaded'Describe how to reproduce the problem
Include any warning/errors/backtraces from the system logs
n/a
Additional remarks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259231 obviously describes the same problem. However, it seems that the unencrypted dataset must be a child of an encrypted dataset on both sides to produce this behaviour.
The text was updated successfully, but these errors were encountered: