I recently updated CloudBerry Backup, and noticed that it now no longer backs up my EFS encrypted files, but instead skips them with the error messages "Backup file are encrypted" / "Warning. One or more backup files are encrypted".
I would like to keep both my local file encryption and my backup software, so is there any way to make CloudBerry Backup behave like it used to, and actually back up EFS encrypted files instead of complaining about them? (Note that the service runs under my own user account, so CloudBerry backup does indeed have access to read the files!)
The additional exposure of which account the backup service runs under would indeed be nice, but would not solve the problem at hand, as my configuration is correct and used to work just fine, but stopped working in the recent update because of a bug. It sounds like you are already working on fixing it though, according to what Matt wrote above.
Yes, it did. I am also still able to restore previously backed up EFS-encrypted files in the latest version. It just won't do any new backups of these files :(.
I don't understand why you want me to do that, as Matt already wrote above that this issue is a known bug that will be fixed in the next version of CloudBerry Backup. The problem is not lack of access to the EFS encrypted files, so I don't see the relevance of that workaround either. And even if it was, I'd rather not compromise on security by giving the SYSTEM account access to my encrypted files.
I'm not running the backup service as SYSTEM. I'm running it under my own account, as I also wrote in my original post. As I also wrote multiple times by now, the previous version of Cloudberry Backup worked just fine.
Of course giving SYSTEM access per the linked guide is a security compromise. The guide even states so at the top! Did you read it? (it says "Allowing SYSTEM to access encrypted file could be dangerous, anyone with physical access to this machine would be able to decrypt crucial data.")
It seems like Anton does not agree with us about this being a bug, and that it will be fixed as you wrote earlier. Could you please help clear up the confusion? Thanks!
we're going to have a meeting on Monday to discuss this particular post. And then we'll get back to you with a more detailed response. Apologies for the confusion.
Send us the logs to support via tools > diagnostic menu. I'll check them out and maybe even provide an early build with the fix(if it's indeed a known issue). Mention that the logs are for Matt and also paste the link to this forum thread in the description.
Thanks!
In case anyone else encounters this problem: usually it's related to trying to mount a bucket that is in a region that we don't support yet, in this case EU Central.
There's an easy workaround: Just add this destination as an S3-compatible storage with the corresponding endpoint, like on the screenshot below.
I'm on 6.2.0.154 and have this same problem with EFS files. It gives the same error both with local and cloud backups (to B2). I don't want to use the SYSTEM account "workaround" as that somewhat defeats the purpose of EFS encryption to begin with. Other backup software like MozyPro has supported backing up EFS files and certificates.
Currently there are 2 options:
1) Either user workaround posted eirlier in the thread.
2) Change service account to the one that was used to encrypt the files.
We're already working on a solution to back up such files regardless of encryption settings.
Thanks for the update. I look forward to the solution, as I'm using the server (i.e. more expensive) version to back up a Windows server that contains network shares. The EFS encrypted files in question are coming from multiple users, so neither of the workarounds are viable options at this point in time.