SOLVED B2 Cloud Task Restore - Permissions reset on restored files

[Castigo]

Hy! This post is a bit of a sanity check for me, so I apologise in advance if this issue is known or not an issue at all and working as intended.
I found no reference to this specific behaviour in the TrueNAS docs and only very sparce references for other OSes (for example here - warning, external link).

Status:

I am using Backblaze B2 free allotment to host a few buckets for off-site backups of small datasets, each to its own specific and isolated bucket.​

I am running nightly push syncs, with zero issues.​

I am encrypting the data before being it pushed out through the cloud sync task menu.​

The destinations buckets on B2 are private and encrypted server side (my files leave my TrueNAS encrypted and are placed in an encrypted bucket).​

Issue (or allegeded):

The Restore function from the Task cloud sync menu works fine: a few deleted test files were flawlessly pulled from the cloud bucket, decrypted and restored in the correct local dataset.​

BUT the file owner was now set to root:root. The original files were not created by root:root but by my user:usergroup.​

In order to be able to modify the restored files I need to run the chown command from the CLI and reset ownership of the files.​

Questions:

• Has anyone else noticed this?
• Is this expected behaviour in this scenario?
• Is the encryption process (local and/or remote) at fault?
• Is the file ownership assigned by the Samba ACL management stripped when the files are encrypted or are the files restored and assigned to the root used by default?
• Is it because the restore task is run by root?

I do understand that pulling data from a bucket in this scenario is not meant to be a frequent occurrence, we are not meant to restore from the cloud unless all local copies are lost. Also, I do understand that I should not restore to the original dataset, but to a new restore destination to avoid possible conflicts, in which case probably a recursive run of chown for the whole dataset is not such a big deal. But did I set up something blatantly wrong or is it just as it is?

Thanks for any input you might be able to offer!

 

[Castigo]

Hy! So I kept looking into this and I wanted to leave a note behind, in case someone else got into this.

I have verified that:

1)

Is the encryption process (local and/or remote) at fault?

has nothing to do with anything. I restored from an unencrypted bucket the files I sent out locally encrypted, they were restored with modified owners. I could try to send out unencrypted files, but that would defeat the whole purpose of this exercise, won't it?

2) So, the following is kind of ruled out in my opinion:

Is the file ownership assigned by the Samba ACL management stripped when the files are encrypted

The technical jargon more apt for answering this is "nuh, you dummy...".

3)

Is it because the restore task is run by root?

I think this answers my question, but the issue remains. I could run the cloud sync task as user to begin with, loggin into Truenas' Gui as user (I'm not allowing it at the moment). Running pre or post scripts doesn't work for the restore task, not the automated way anyway....

Since I'm not exactly restoring file every five minutes (I never restore form cloud buckets) it's not something I run into every day, and file ownership can be easily fixed with an ACL recursive command in the GUI on the restored share or by running the chown -R command. It's just something to keep in mind when you run a cloud restore, that's all. Automation might even be counterproductive in this instance.
I will suggest a small addendum or a note in the TrueNas Docs about it, though.

P.S.:

file owner was now set to root:root. The original files were not created by root:root but by my user:usergroup.

I must correct myself here, I won't edit the original post to remind myself to triple check the CLI before posting: the restored files are not owned by root:root, but by root:usergroup, as in the usergroup of the original file owner (this is getting existential...).

Anyway, it's really not a big deal, I just wanted to throw it out there, maybe someone new to this got into a snag when running programmed robocopy /mir tasks from their windows machine to their share and worried needlessly about having royally screwed something up when robocopy would spew errors left and right about ownership of files recently restored from the cloud... Don't ask me how I know, purely hypothetical.

Bye!