That's a known problem which will be fixed in 6.1.

Would these screenshots (if implemented) help you to get the idea how to to configure it?





Also, have you tried this approach?
https://kb.cloudberrylab.com/standalone-backup/general/how-to-backup-efs-encrypted-files-with-system-account

Thanks. I am looking forward to it. I still don't see it though, here a month later.

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.

Can you please confirm it worked before? I had an impression it was skipping such files with no warnings.

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 :(.

try this: https://kb.cloudberrylab.com/standalone-backup/general/how-to-backup-efs-encrypted-files-with-system-account

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.

>The problem is not lack of access to the EFS encrypted files

This is the problem. Local System account doesn't have access to those EFS encrypted files.

In any case on order to back those up you need to have read access. It's not about compromising, it's about backing up.

Thanks

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.

Done.

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.

Yes, I completely understand the problem, it's on our priority list.

Any updates on this issue?

Priorities have shifted and the issue is more complex than we though initially, so it'll be fixed in v 6.4.

That's unfortunate. Version 6.3 is not even out, so when is 6.4 expected? I was under the impression that this would be resolved in months, not years.

Was this ever resolved? I am having this issue now.

Hey Guys,

I’ve seen a few fixes on here but can anyone confirm they have worked? Also having this same issue