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:
Issue (or allegeded):
Questions:
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!
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!