Is My Data Lost? A ZFS Encryption / Replication Remote Keys Unable to Be Loaded Question

[winnielinnie]

So then if a new snapshot is made on FrickNASty, and you try to use that for an incremental stream to Yolen, it will crash?

 

[fricker_greg]

So then if a new snapshot is made on FrickNASty, and you try to use that for an incremental stream to Yolen, it will crash?

Yes, if I try to send FrickNASty/Encrypted/PhotoVideo@auto-2023-04-10_00-00, it crashes

But I think it is crashing because of encryption issues. Because I get the same crash message when I try to unlock the dataset

 

[winnielinnie]

Because I get the same crash message when I try to unlock the dataset

Unlock it when? I thought you said you can unlock it successfully?

then unlocked successfully using passphrase, then via GUI said to unlock with parent and inherit parent encryption

 

[fricker_greg]

So, when I first transferred from BrownNASbackup to Yolen, the dataset was acting normally so to say, and I was able to unlock it then and then clicked inherit parent encryption.

But, after a restart, now I cannot unlock Yolen/RemoteBackups/PhotoVideo

Then, after restart of Yolen servers, when I was unable to unlock the dataset despite it appearing in the GUI like it was unlocked (no lock at all beside it, just like a regular, unencrypted dataset), I did:
zfs get encryptionroot Yolen/RemoteBackups/PhotoVideo it says the root is Yolen/RemoteBackups
So I zfs load-key Yolen/RemoteBackups and enter passphrase and it seems like it loads the key
And then if I zfs load-key Yolen/RemoteBackups/PhotoVideo it says error: keys must be loaded for encryption root.
I verify that with zfs mount Yolen/RemoteBackups that I can mount it, great
then I do zfs mount Yolen/RemoteBackups/PhotoVideo and I get a Permission denied error
OK, so zfs get keystatus Yolen/RemoteBackups/PhotoVideo shows "keystatus: available"
Ok, so lets load it, keyload error, must be loaded for encryption root. Boo.
zfs get keystatus Yolen/RemoteBackups shows key is available and then "load-key" shows that key is already loaded.

That was to show that despite having the parent unlocked, the dataset Yolen/RemoteBackups/PhotoVideo remains unmountable for permission error.

 

[winnielinnie]

What does this show:

Code:

zfs list -r -t filesystem -o name,encryption,encryptionroot,mountpoint FrickNASty

zfs list -r -t filesystem -o name,encryption,encryptionroot,mountpoint Yolen

zfs mount | grep Yolen

zfs mount | grep FrickNASty

 

[fricker_greg]

 

[fricker_greg]

What does this show:

Code:

zfs list -r -t filesystem -o name,encryption,encryptionroot,mountpoint FrickNASty

zfs list -r -t filesystem -o name,encryption,encryptionroot,mountpoint Yolen

zfs mount | grep Yolen

zfs mount | grep FrickNASty

Replied above, but I actually think perhaps a key part of this is found when I try to unlock Yolen/RemoteBackups in the GUI as I give the correct passphrase and then it starts the unlock and then it fails saying permission denied, but in the GUI, it appears as if Yolen/RemoteBackups is unlocked. I think this permission error is the same. I am root when I am doing that.

Thinking back I am not certain if I made the Dataset RemoteBackups or if RemoteBackups was made as a parent when I transferred over PhotoVideo dataset from BrownNASbackup to Yolen.

 

[winnielinnie]

Without using the command-line, you need to first unlock Yolen/RemoteBackups (its own encryptionroot), and then unlock Yolen/RemoteBackups/PhotoVideo (which is also its own encryptionroot). The "unlock" method in the GUI doesn't simply load the key, it also automatically tries to mount.

You should not try to unlock ("load-key") for PhotoVideo before unlocking RemoteBackups.

 

[fricker_greg]

What you described is what I did

 

[fricker_greg]

Without using the command-line, you need to first unlock Yolen/RemoteBackups (its own encryptionroot), and then unlock Yolen/RemoteBackups/PhotoVideo (which is also its own encryptionroot). The "unlock" method in the GUI doesn't simply load the key, it also automatically tries to mount.

You should not try to unlock ("load-key") for PhotoVideo before unlocking RemoteBackups.

When I unlock Remote Backups via the GUI, it initially says success then fails with error Permission Denied and then it looks like the screenshot above, which is curious because it appears unlocked

 

[winnielinnie]

I think this permission error is the same.

The same as what? The only time "permission denied" was mentioned before was when you said you tried to mount using the command-line.

 

[fricker_greg]

The same as what? The only time "permission denied" was mentioned before was when you said you tried to mount using the command-line.

That is what I am talking about. That the permission error I get when trying to unlock Yolen/RemoteBackups is the same problem I have when I tried to mount Yolen/RemoteBackups/PhotoVideo after the GUI said it was unlocked and the command line says the key is loaded and the dataset mounted.

 

[winnielinnie]

Then I wonder if you threw off the middleware or GUI by trying to mount in the command-line after unlocking via the GUI?

As it stands now, PhotoVideo uses RemoteBackups as its encryptionroot, and it should automatically mount the moment you unlock RemoteBackups.

 

[fricker_greg]

Then I wonder if you threw off the middleware or GUI by trying to mount in the command-line after unlocking via the GUI?

As it stands now, PhotoVideo uses RemoteBackups as its encryptionroot, and it should automatically mount the moment you unlock RemoteBackups.

Yes, that is my issue. It should be mounting, and it is not and further causes a kernel panic when you try to unencrypt it. I only did the command line when I was preparing this post so that I can provide more information for those looking from afar to see what is happening under the hood.

 

[winnielinnie]

then unlocked successfully using passphrase, then via GUI said to unlock with parent and inherit parent encryption

Did you attempt this while RemoteBackups was still in a locked state?

 

[fricker_greg]

Both.

For every other replication task though, it doesn't matter if Yolen/RemoteBackups is unlocked or locked.

 

[winnielinnie]

For every other replication task though, it doesn't matter if Yolen/RemoteBackups is unlocked or locked.

Not asking about replications. In regards to changing the encryption properties of PhotoVideo.

then unlocked successfully using passphrase, then via GUI said to unlock with parent and inherit parent encryption

 

[winnielinnie]

--------PhotoVideo (Copied over dataset and all snapshots using "zfs send -Rw BrownNASbackups/RemoteBackups/PhotoVideo | zfs recv -Fuv Yolen/RemoteBackups/PhotoVideo", then unlocked successfully using passphrase, then via GUI said to unlock with parent and inherit parent encryption)

I can access Yolen/Encrypted/PhotoVideo however, and it acts as expected when unencrypting the parent,

Just going by this, it appears "everything worked" so far. So it's hard to see this as the "IV is not available". Otherwise, how would you have been able to access the files within in the first place? (I really doubt it loads anything from the other server to be able to allow you to access data on this particular encrypted dataset.)

 

[fricker_greg]

Not asking about replications. In regards to changing the encryption properties of PhotoVideo.

Thanks for clarifying.

I restarted Yolen server. Yolen/RemoteBackups is locked as expected. While still locked, I cannot change the encryption status of RemoteBackups/PhotoVideo (this is also expected).

I unlock Yolen/RemoteBackups, it says success then permission denied (photos attached). It then looks like it succeeded in the GUI. Then I go to PhotoVideo (its encryption is listed as inherit), then if I change that for instance from inhereted to passphrase, I get a system crash.

 

[fricker_greg]

Just going by this, it appears "everything worked" so far. So it's hard to see this as the "IV is not available". Otherwise, how would you have been able to access the files within in the first place? (I really doubt it loads anything from the other server to be able to allow you to access data on this particular encrypted dataset.)

This was my error. It was a typo. I was referring to everything worked with Roshar/Encrypted/PhotoVideo and both FrickNASty and Roshar pools are available to that local host locally. I fixed my original post to better reflect this