I want to back up EFS encrypted files in my Windows %USERPROFILE% to an external NTFS formatted USB drive using Windows FileHistory. I have the following problems:

  1. After clicking "Select Drive" in "advanced settings", and selecting my USB backup drive, a message is displayed on a yellow background, above the box showing the selected drive, saying that "EFS encrypted files were found on a non-NTFS file system or a network location and FileHistory won't backup such files." The only part of this message that is not bogus is that it found some EFS encrypted files. Neither source (C:) nor backup volume were non-NTFS & no network was involved.
  2. If, you click "Run Now" under the selected, disk drive, you get a message to the effect that "the drive could not be used" & a cryptic error code.
  3. If instead you close "advanced settings", returning to the main Backup settings screen, and click the "Back up Now" button, FileHistory will spin forever displaying the message "Your files are being backed up for the first time", apparently backing up files, but not actually accessing the backup disk. The USB disk went to sleep due to the lack of activity. I left it for more than 2 hours but FileHistory did nothing except create its folders.

The external USB drive in question is protected with BitLocker and the NTFS volume is in the 3rd partition on the disk. Just mentioning this for completeness. They should not affect FileHistory.

How can I get my files backed up?

Please don't ask why I am not using BitLocker on my C: drive instead of EFS. The answer is not relevant to this question but it is because my C: is a BootCamp partition and Apple says these are not compatible with BitLocker.

  • I did a clean install of Windows 10 and it enabled bitlocker without me even approving it explicitly. This greatly reduces the viability of using file history because it's telling me encrypted files won't be backed up. There were rumors file history was going away - so perhaps this is why. – Simon Jul 6 '18 at 17:07

I posted this question in order that I could provide the answer, that I figured out, in a truly public forum. I spent a long time searching the web for an answer without result so I think this will be valuable to others as I found the question asked many times but never an answer.

I posted the question and following answer to Microsoft's Feedback Hub as a problem under the title "FileHistory won't initialize when %USERPROFILE% encrypted with EFS" but that still is not showing up in web searches after several days, hence this post.

The answer I found after much blood, sweat & tears...

If %USERPROFILE% is not EFS encrypted then FileHistory set up and first back-up, using the same BitLockered NTFS formatted USB drive, proceeds without error. Yes you probably knew that. What you likely don't know is that Once FileHistory is set up, one can EFS encrypt one's %USERPROFILE% and FileHistory will happily back up the files to the already selected drive. The backed-up files remain encrypted under the same key used originally.

So either set up FileHistory before EFS encrypting for the first time, or decrypt %USERPROFILE%, set up FileHistory and re-encrypt. Since my external USB drive is BitLockered, having an initial un-EFS-encrypted backup is not a problem.

I cannot understand how Microsoft can ship such a critical app as FileHistory with such bugs.

  • I discovered that after a reboot FileHistory stopped working. Symptom is that FH does nothing and writes nothing to event log. Pressing the Backup Now" button in Control Panel merely changes the button label to Cancel. Pressing Run Now in the Advanced Options panel, results in a a cryptic error "Failed to initiate user data backup (error 80070005)". The solution is to turn off encryption on %USERPROFILE%\AppData\Local\Microsoft\Windows\FileHistory. Because FH runs as Local System User it is unable to read these files if they are encrypted. – msc Feb 19 '18 at 23:26
  • I suspect that if I had created an unencrypted FileHistory folder in the first place, I could have avoided the whole decrypt, reencrypt %USERPROFILE% cycle. I am not in a position to be able to test this theory at present. – msc Feb 19 '18 at 23:28
  • I think FH worked from initial re-encryption until reboot because it was already up and running and had its history files open when I performed the encryption. – msc Feb 19 '18 at 23:33

protected by Ramhound Jan 1 at 0:54

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.