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

@Matt Is there any update to this now that v7 is out? There never was a v6.4 release. I only point that out because that is the version you stated would include a fix. I see nothing about any EFS related fixes or updates in the "What's New" release notes going back to version 6.3.2. I don't typically complain, but Cloudberry is supposed to be an enterprise-level backup solution and isn't super cheap either. The basic server-capable license for Cloudberry also at some point recently increased in price to $180 from $120 (a 50% increase).

The solution is not an easy one for file / folder backups that need to access EFS encrypted files created by users other than the service account that is running the backup service. Windows prevents such access, as you're aware. I assume if you're using EFS at the user level, you have a reason for doing so. The easiest way around this might be to perform an image backup instead. You can restrict the image to just the folders needed using the Exclude Option. But the caveat here is that in order to restore files to a system other than the one that was used for the backup would require you had the certificates and would have to back them up. In my opinion, this adds additional complexity you may not want to absorb.

I saw your earlier post about MozyPro, but when I check other products like CrashPlan, Carbonite, Acronis, and Veeam, I see information which would suggest that it's not supported on those platforms either. It's possible some of these other products do what you need, but I haven't come across that information.

The requirement, as you noted, has been pushed to 7.4, which is some time off. At this point I do not think it would be realistic that it will be added in a time-frame you need it (if at all). I know the team is looking at options and if something is found during their research, they will re-prioritize.

I would like to ask why you are using EFS, are you using it for more than one user, and whether Bitlocker encryption would suffice in its place since it's whole-drive encryption - and we support it?

I'm not expecting some magic solution. Of course the EFS certificates would need to be backed up. In a Windows domain scenario, the best solution would likely be backing up the recovery agent's private key (since the default recovery agent is the admin account on the first domain controller).

While it might be possible for backup software with sufficient privileges to handle this key backup automatically, I'm certainly OK with having to do a one-time manual export of a recovery agent key to a file that could then be backed up along with all the other files.

But all of that is moot if the software refuses to backup EFS encrypted files at all. There are certainly other apps that have successfully backed up EFS files without decrypting them. The trick is using an EFS specific API from Microsoft. Bvckup2 is one such software (great software, but only supports local network source/destinations). You can google "bvckup2 efs" and the top result should be a forum where there are details and a link to Microsoft's EFS API.

You ask why I am using EFS. I'm not, nor do I like it. I'm actually about to disable support for it domain-wide with GPOs for most of my clients. The problem is that, unless it is disabled in the domain, any domain user can choose to use it. So any clients with users that already have EFS-encrypted files will still have those files. It is what it is.

In regards to the image backup, there is a lot more flexibility for a variety of things (like retention) that you can do with file-level backups, so I don't see an image backup as being a viable workaround at this point. Bottom line, it doesn't seem like it would be that hard to just back up the files as-is using Microsoft's EFS API in a file-level backup (along with warnings for any EFS files in regards to the need for a recovery key).

I have a question pending for the dev team onthis request. If I get an update from them, I'll post it here. Thanks for your feedback.