I am trying to restore a folder from a shadow copy but I am getting access denied errors. I have tried right clicking the folder within the previous folders view panel and changing the permissions this why but get access denied error.

I have tried to copy the shadow copy folder but get the same error again. I have taken ownership of the live folder and tried the above again and still get the same error.

I am a domain admin and have added in both the admin, domain admin and my own user account until the ACL but not getting anywhere at all!

I have logged on and off and tried again but with no luck…

The folder I am trying to restore was a folder that I did not have access to beforehand so I am thinking maybe the snapshot took a copy of this ACL hence the access denied error but surely there is a way around this as domain admin?

Cheers, Chris

7 Spice ups

I am not 100% sure it’ll work but you could try using Microsoft’s psexec and access the files under the SYSTEM context. You can then robocopy the files/folders to the active file system and then as administrator you can take ownership and grant yourself the necessary NTFS permissions.

Cheers for your reply, I am confused as to why I would use psexec to access the files to then use robocopy? I am a domain admin and have access to all servers including the file server which is where these files are stored…

Clearly that is not the case or you wouldn’t be having this issue. :slight_smile:

Normally you’d just be able to take ownership which would grant you full access. The problem is that a shadow copy is read-only so you cannot overwrite the owner or permissions on the folder/files.

By using psexec you can get a command line session to run as the SYSTEM account. This may have access even though your administrative account does not.

Do you know who ‘owns’ the files in question? Could you get them to access the shadow copy? This will at least allow you to view the NTFS permissions that were set up on the folder/files.

I have taken ownership of the ‘live’ files with no problems, its just accessing the shadow copy that is the issue. Are all shadow copies read only or does the snapshot take an up to date copy of the ACL at that point in time?

I’ve not used psexec before! Could you give me a brief master class on what I need to be doing?

I do know who owns the files and folders but I don’t have access to there account and resetting the password is out of the question as it is the CEO…

The snapshot takes a copy of the ACL at that point in time.

Download and extract psexec
Open an administrative command prompt
Browse to the folder containing psexec.exe
Run psexec.exe \localhost /s cmd.exe

Once you have your new command prompt you can mount the shadow copy as normal and try robo-copying the folder to the active file system. Once you have an active (writeable) copy you should be able to seize ownership.

You don’t have to log on as the CEO - just get him/her to open the shadow copy using the Previous Versions tab from their own machine. You may then also want to advise said CEO of the dangers of removing administrative access to files and folders…

EDIT: Usually I’d use the FQDN of the server rather than \localhost - I doubt it’ll matter but if \localhost doesn’t work you may want to try the FQDN.

4 Spice ups

Mount the shadow copy? I am not familiar with doing this…

At the command line:

:> vssadmin list shadows > shadows.log
:> notepad shadows.log

Find the shadow copy you want to mount in shadows.log. You are looking for the Shadow Copy Volume guid. You’ll need to look at the Original Volume and the creation time. Once you have the guid you need to run the following where ZZZ is an integer value.

:> mklink /d C:\shadowcopy \?\GLOBALROOT\Device\HarddiskVolumeShadowCopyZZZ

Now use robocopy to grab the folder you want from C:\shadowcopy and copy it to a suitable location on the active system such as C:\active

Once you have finished copying the files you need to remove the symbolic link:

:> rmdir C:\shadowcopy

Of course you won’t be able to copy the files if SYSTEM was denied access to the files/folders either.

7 Spice ups

Sorry for my late response! This seemed to do the trick, thanks for the help on this. To prevent this occurrence in the future how can I make sure that any new folders or files created by users automatically have domain admins group as full control?

Hi Christowfurs,

Did you find an answer to your question regarding preventing such occurences?

Thanks.

I didn’t really find a solution to preventing this problem sorry but the fix to get into the files once the damage has been done did work!

I know this is old but I think I have found a better solution. You must be the “built-in administrator” for that machine, not simply in the administrators group. That can either be THE local “Administrator” account or THE domain “Administrator” account. Hope that helps someone!

4 Spice ups

Can’t see how that would work. If the built-in administrator account did not have rights they’d have to take ownership to replace the ACL - which they cannot do as a shadow copy is read-only.

I shall have to give it a try when I get in to work tomorrow. :slight_smile:

Please give it a shot because I don’t want to send anyone in the wrong direction! At least for me, I could not access the shadow copy with my domain admin account but could once I used the domain admin account “Administrator”. There are specific group policy options that address the behavior of the built-in administrator accounts vs other administrator accounts so our setups might be slightly different.

Logon with builtin administrator account worked for me also. Thanks

1 Spice up

same here… does not work with Domain admin, but does work with builtin admin. thx!

Quick question about this for you gurus…

I’ve tried pulling data from ‘previous versions’ that have the date I’m looking for, but when I copy data from the shadowcopy, all I’m seeing is the data that is current? Am I missing something here?

old thread, but if someone land here, if you cannot even take ownership of shadow copy folder, try this , it worked for me Unable to access or take ownership of file users shadow copy files « Memorise

I know this is a really old thread, but the instructions from lmaslany on Oct 7, 2013 at 7:48 AM has a slight error. The command is missing a trailing slash, otherwise you will get a permission/parameter error when trying to access the directory link.

mklink /d C:\shadowcopy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyZZZ

Needs to be:

mklink /d C:\shadowcopy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyZZZ\

I found this thread very useful for solving a similar issue for me, so I wanted to save future visitors the trouble of it not working for them.

4 Spice ups

From what I found, it comes from trying to use an admin account that did not create the shadow copy. I have an older main one I used back in the day and my newer admin account encountered this problem, but the old admin account worked fine.