The support forum

"Alternate data streams can't be listed, access denied"

mhw-at-work :

Jan 24, 2020

I'm getting the error "Alternate data streams can't be listed, access denied" for some files.

Part 1: For example 'C:\ProgramData\Microsoft\Diagnosis' and 'C:\Windows\system32\LogFiles\WMI'.

What permissions are needed in order to a) back these files up, and b) not defeat the security reason these are restricted from Read by the bvckup service user?

Alternatively, if these really shouldn't be exposed to bvckup, is there an exclusion rule or setting I can use so that the errors don't mask real problems in the log? (because they increase the noise level)

Part 2: same error message during "Running archive maintenance" task for files within the "$Archive (Bvckup2)\System Volume Information (date and time stamp)" tree. I would expect no problem here since these were created by Bvckup in the first place.

mhw-at-work :

Jan 24, 2020

v80.2 on Windows Server 2012R2

mhw-at-work :

Jan 24, 2020

I see an update is available, applying...

Alex Pankratov :

Jan 27, 2020

Part 1 - these should be perfectly accessible, because Bvckup 2 service user account is a member of the Backup Operators group. These aren't really files that are worth protecting to begin with, especially in such bizarre way - with just streams being inaccessible, but not files themselves.

So I'd guess this is either due to 3rd party security software that decided to over-police this access or due to nefarious reasons with malware/rootkit hiding something in those streams.

At the very least try and list the streams with "dir /r". If you CAN do this, then it's the former reason. If you cannot, then it's something else that's probably worth a closer look.

Part 2 - if the backup is going to a remote share and you selected to copy the security and/or ownership info, you may see this sort of errors. Basically, you cannot clone DACL/Owner/Group across a machine boundary unless it runs in a domain-controlled environment. This is because DACLs are expressed in terms of security IDs (SIDs) that are specific to their host machine. Once copied elsewhere, they start referring to non-existing entities => hilarity ensues.

If the backup is fully local, then it might be the same cause as with Part 1.

All that said, System Volume Information doesn't need to be backed up, because there's simply no point in doing that. It is also excluded by default, but that's easy to override, of course.

mhw-at-work :

Jan 28, 2020

Thanks for the info. It seems to be zealous security settings, Backup Operators group has zero effective access. Is there any reason to not simply grant Backup Operators read access to the entire machine?

The dirs noted aren't being protected on purpose, more of a "I don't know what's important so just get everything".

I don't know why System Volume Info is in there for Part2. It's excluded in the backup settings. Maybe an earlier version of the set inc;luded it.

Alex Pankratov :

Jan 30, 2020

Is there any reason to not simply grant Backup Operators read access to the entire machine?

Can't really comment on this, because BO missing all privileges might be due to an IT policy you have in place. That is, not for a purely technical reason.

New topic

Made by IO Bureau in Switzerland

Blog / RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms