Error 5 in volume shadow copy

[SvenW]

Hello,

I've got a strange accessing problem:

Error 5 accessing file \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy67\...

- It appears with different file types.

- It appears "only sometimes"

I've got a backup configured with different RDX media. It works fantastic and backs up data each night, if only this error wouldn't be. 

Sometimes the backup runs without error and another day the backup (on the same media) gets an "error 5" in the VSS copy (only) on some files.

The source and the destination file exist and can be opened (e.g. *.jpg or *.pdf), they are mostly not even changed and the incremental backup mustn't copy the file.

The backup runs deep at night and nobody accesses these files.

So i came to think this might be a service or something running on the server.

May this be a "microsoft indexing service" or a virus scanner or something like that?

For me it looks like the shadow copy is made but the file seems to be unaccessible in the shadow copy (but that is only how i would read the error message)...

shadow copy providers: only 1 (microsoft software shadow copy provider 1.0)

BTW: thank you hobocopy is great!

[Craig Andera]

I have to say, I have been stumped by similar problems in the past:
VSS is one of the weirdest, least-documented pieces of Windows. Can
you send us the information from this page:
https://github.com/candera/hobocopy/wiki

[SvenW]

SOLVED

 I've been going this way:

(1) i run hobocopy to a destination directory with some write protected files this seems to appear (i found this in another thread here and the result seemed similar) 

(2) The source directory contains files with write protection, therefor I think hobocopy copies the files with write protection and the destination file is then also write protected.

At the second run, hobocopy  (i tried /incremental and /full, it's both the same result)  on the same destination directory then throws an error 5 because the destination file is write protected (?).
So far so good, I remove the write protection attribute on the destination directory with the batch command "attrib -r %dest_dir%\*.* /s" before hobocopying but still (at least) one file throws that error. After inspecting my logfile i tracked it down that this one file is a thumbnail file (which for me seems to be produced by some image indexing/chaching software). 

(3) after testing some more options i found the solution: "attrib -s -h -r %dest_dir%\*.* /s" does the job for me, when I run it before hobocopy.

TO ALL OTHERS WHO READ THIS, PLEASE BE AWARE:

"-s" removes the attribute "system" from all files (this means you may see files in the deatination directory that are system files)!

"-h" removes the attribute "hidden" from all files (this means you can see all hidden files, thius may be confusing for some users)!

Attrib can only remove the "r" (readonly) attribute from files, if these files are non-system and non-hidden, therefor this is a workaround not a real fix.

CAREFUL: I have no solution for restoring the attributes to its original state after the backup process.

%dest_dir% is a batch variable that has previously been set by "set dest_dir=<path>" if you need to use it, you can also use a real pathname instead of this variable.

@Craig:

I'd suggest to add a hint text to "error 5" (that this may be a readonly destination file).

Because the thrown error reads  (and this looks like the source file is blocked, because it refers the shadow copy) :

"Error 5 accessing file \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy..." 

[Craig Andera]

Nice catch! I think you're totally right: it's just a case of an
extremely bad error message. Very sorry for that!

On the question of what to do about it, I think your fix is the
correct one. However, this sort of thing is the reason that I
deprecated hobocopy in favor of shadowspawn. Basically, I have no
business writing copy programs, which are surprisingly complex to get
right, especially as there are lots of really good ones out there. So,
although I'm somewhat conflicted about it, I'm going to say "won't
fix" on this one, and continue to recommend that people use
shadowspawn instead of hobocopy.

Thanks a ton for tracking this down. Hobocopy has been downloaded
something like 250,000 times, so even though I've decided to stop
supporting it, I still feel bad when people have problems with it.
Hopefully this will help anyone else who runs into the same issue.

Good luck!