Data Centers

Resolving TrueCrypt and Volume Shadow Copy conflicts

TrueCrypt is a great open source encryption solution to protect data, but it can lock horns with the Windows Volume Shadow Copy Service. Learn how to untangle the two products.

 

hero
Image: iStockphoto.com/enot-poloskun
 

A large part of working in IT involves figuring out how to prevent bad things from happening — or if they do occur, how to ensure they don't happen again. While some might term this "closing the barn door after the horse has escaped," I prefer to think of it as "building the habit of closing the barn door so he won't get out again."  Of course, that's often when you find out the barn door might not look too pretty when you're trying to keep it shut.

This was recently exemplified by an episode I experienced at a client site that involved a critical folder accidentally deleted from a Windows 2008 file server. It was a fairly typical scenario where the folder had somehow gotten lost through user mishap one afternoon. No problem. Just restore last night's backup, right? Well, no dice to that idea since the files had all been created that day, after the previous backup finished.

But the game wasn't quite over, because the client uses the Volume Shadow Copy Service on the server and it was set to take a snapshot of the data volume (H: drive) twice per day – at 10 am and 2 pm. We looked at the 2 pm snapshot using the Previous Versions function in Windows (whereby you right-click a network folder, choose Properties, click the Previous Versions tab, browse to the data you want, then copy it to the live location).  We managed to obtain three files from it, but the remaining dozen or so were still gone because they had been created after 2.

Figuring it couldn't hurt to gamble with free utilities, we tried the undelete programs Recuva and FreeUndelete but did not find any files to recover. I have only had middling at best luck with these types of programs, but they can still be worth a shot — though for some reason they always seem capable of recovering unimportant files rather than important ones.

Cutting losses and preparing for next time

That brought us to the end of the road. The user had to re-create the missing files, which wasn't the end of the world, but we figured rather than taking volume snapshots of the server H: drive twice per day, perhaps a better idea would be to do so hourly during business operations.

Configuring the Volume Shadow Copy Service snapshot schedule is easy. You just log onto the Windows server, right-click the volume in question, choose Properties, and then choose the Shadow Copies"tab. However, when we did this we got the error shown in Figure A.

Figure A

 

Figure A
 

Uh, what?

This error seemed to indicate a problem with the Volume Shadow Copy Service. The service seemed to be running okay, and as previously stated we were able to access the data it protected, but some vague errors appeared in the Application Logs:

"Volume Shadow Copy Service error: Error calling a routine on a Shadow Copy Provider {b5946137-7b9f-4925-af80-51abd60b20d5}. Routine details Cannot ask provider {b5946137-7b9f-4925-af80-51abd60b20d5} if volume is supported. [0x8000ffff] [hr = 0x8000ffff]."

Research indicated that the issue was caused by TrueCrypt running on the server. TrueCrypt is an open source encryption solution that allows you to encrypt entire disks, partitions, or special volumes (called containers) to securely store data. I use it for my personal documents and it provides great peace of mind.

In my client's case, they have an encrypted TrueCrypt 7.1a volume on this server mounted as its own drive (I:), which has folders that are shared and secured via the normal Windows server methods. This volume exists to safeguard extra-sensitive confidential data. When the server boots up and is logged in, a command runs automatically, which mounts the TrueCrypt volume after prompting for the password:

"c:\program files\truecrypt\truecrypt" /q /m /l i h:\Security.TC

This performs the following functions:

c:\program files\truecrypt\truecrypt calls the TrueCrypt executable

/q tells the TrueCrypt program to prompt for the volume password

/m tells the TrueCrypt program to mount a volume

/l i tells the TrueCrypt program to mount the encrypted volume as the I: drive

h:\Security.TC is the actual TrueCrypt encrypted container object

We decided to try dismounting the TrueCrypt volume to see if that Volume Shadow Copy Service error went away (Figure B).

Figure B

 

Figure B
 

This was as simple as launching TrueCrypt then selecting the I: drive and clicking Dismount. Once this was done, the Shadow Copies tab appeared as normal (Figure C).

Figure C

 

Figure C
 

We were then able to set hourly shadow copies of the H: drive, as shown. What would happen when we remounted the TrueCrypt volume, though?

As it turned out, the same error showed on the Shadow Copies tab, but it did not interfere with the actual Shadow Copy operation — nor were backups affected. As you can see in Figure D, the hourly snapshots were being faithfully generated (and we made sure to test this).

Figure D

  

Figure D
 

It seems this is a known issue, which TrueCrypt has acknowledged. There are lots of references to the issue on the TrueCrypt forums, and it's clear this situation has existed for some time. The site states that:

"The Windows Volume Shadow Copy Service is currently supported only for partitions within the key scope of active system encryption (e.g., a system partition encrypted by TrueCrypt, or a non-system partition located on a system drive encrypted by TrueCrypt, mounted when the encrypted operating system is running). Note: For other types of volumes, the Volume Shadow Copy Service is not supported because the documentation for the necessary API is not available."

It should be pointed out that this essentially says that we're using TrueCrypt in a non-supported fashion, but that's an acceptable scenario since it's performing per our needs and has been for some time.

I got curious to see if I could circumvent the error via other methods. I didn't want to make any changes to the system drive, but I did want to see whether encrypting an entire test volume with TrueCrypt (as opposed to the container method I described) might change the situation. Unfortunately, it did not. I also tried this on another server, making sure to keep the encrypted file container on a separate volume from the one for which I was trying to configure shadow copies, but the same error resulted.

Learning to live with things

In the end, some barn doors may get slammed shut and still look crooked, but at least they're shut. It's not a big deal for us to have to dismount the TrueCrypt volume to make changes to the Shadow Copy options on this server. In fact, we probably won't have to make any changes again anyway. So long as the Volume Shadow Copy Service is working as expected, we're satisfied with the results.

However, it's interesting to see how these kinds of problems might arise and how to handle them. If I were younger and more impetuous I probably would have slogged on, stubbornly searching for some kind of solution — perhaps backing up, reformatting, and then restoring the volume, for instance. Nowadays, though, the fear of losing valuable business hours to a cosmetic issue (as opposed to something that is actually broken) outweighs the lure of finding a solution that may not exist, like a treacherous will o' the wisp. You have to pick and choose your battles in the IT realm and decide where your priorities lie, just as you do everywhere else.

Share your feedback

Have you run into conflicts like the one described here? Share your experiences (and workarounds) with fellow TechRepublic members.

 

About

Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.

Editor's Picks

Free Newsletters, In your Inbox