This project has moved. For the latest updates, please go here.

Not actually auto mounting on Windows 10 (+EFS incompatibility)

Topics: Technical Issues
Jul 27, 2015 at 8:53 AM
Hello. I created an encrypted container, mount OK against keyfile, set is fav and mount at user logon. After reboot and logon to account, nothing happens however, what's wrong?
What I'm disappointed also on VeraCrypt is relative long mounting time relative to TC (used AES/SHA-512 only encryption).
Coordinator
Jul 27, 2015 at 9:12 AM
Hi,

Can you please try using the 1.12-BETA version? Some fixes were done since 1.0f-2. it available at: https://veracrypt.codeplex.com/releases/view/616110

Concerning the long mounting time, this has been documented and explained since VeraCrypt birth 2 years ago and it is also explained in the home page, so I will not repeat the arguments here.

That being said, version 1.12-BETA introduces a new feature called PIM (https://veracrypt.codeplex.com/wikipage?title=Personal%20Iterations%20Multiplier%20%28PIM%29). You can use it to make mounting quicker.
Jul 27, 2015 at 9:19 AM
Thank you but I'm already using 1.12-beta. On Windows 8.1 the automount seems working however it takes quite a time.
Coordinator
Jul 27, 2015 at 9:25 AM
OK.
For automount , you mean mounting at logon using favorite, right? Because in VeraCrypt automount has another meaning (there is an automount button to mount devices connected to the system).
In this case, just use a small PIM and favorite mounting at logon will be very quick.

Just to clarify: the favorite mounting at logon works on Windows 8.1 but not on Windows 10?

Subsidiary question: Is VeraCrypt auto starting when you open your session on Windows 10? Can you please check that the option "Start VeraCrypt background task" is checked in the Preferences?
Aug 1, 2015 at 8:49 AM
VeraCrypt not auto starting when open your session on Windows 10

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
"VeraCrypt"="\"C:\Program Files\VeraCrypt\VeraCrypt.exe\" /q preferences /a logon /a favorites"

1.12-BETA

TC 7.1a is auto starting
Coordinator
Aug 1, 2015 at 9:59 AM
Edited Aug 1, 2015 at 10:00 AM
By reading the content of your registry, this seems to be a configuration issue from your side: VeraCrypt will try to mount any configured favorite volumes and it will quit right after (notice the /q) unless the option "Start VeraCrypt Background task" is checked in the preferences. So, judging by your report, it is clear that you either:
  • forgot to check this option.
  • you didn't configure VeraCrypt favorites to mount at startup.
Since VeraCrypt kept the same TrueCrypt logic, if you go to TrueCrypt, you'll see that you either have checked the background task option or you have at least one TrueCrypt favorite configured to mount at logon. Most probably you have a TrueCrypt favorite volume set to mount at startup.

Thus, to have the same behavior as TrueCrypt, just use VeraCrypt like TrueCrypt and add a favorite volume to VeraCrypt that is configured to mount at startup.

Voilà voilà...actually many TrueCrypt users compare between VeraCrypt and TrueCrypt without putting them both in the same configurations, so it is normal to have different behavior!
Aug 1, 2015 at 4:19 PM
That's not the case, in VC prefs VC background task is enabled, start VC background task disabled
Favorite volume has flag mount on logon set.
Same in TC prefs (enabled.disabled)
Coordinator
Aug 1, 2015 at 5:45 PM
humm...weird...and you don't get the password prompt upon logon? You favorite don't get mounted or they get mounted by VeraCrypt exits afterwards?

This is the simplest configuration and it works for me and others on Windows 10. This is the basic test that we all do to check if VeraCrypt works (favorite mounting, both normal and system).

Thus, there must be another cause. First thing is to check Windows Events Viewer to see if there is any error (both on System and Application) that would explain this.
Second, try running the same the command line from a command prompt and check if you get the password prompt: "C:\Program Files\VeraCrypt\VeraCrypt.exe\" /q preferences /a logon /a favorites

Third thing, verify if you have any software on your machine that can block VeraCrypt from auto-running at startup: some security software offer such functionality and they may falsely target VeraCrypt binaries.

Anyway, I have done a test on a Windows 10 Pro with an encrypted USB key that uses only a keyfile (no password). I recorded a video that demonstrates how to set this encrypted USB key to mount automatically at startup without typing any password. Here is the link to the video: https://www.youtube.com/watch?v=gbJKUEUXWVo

As you can see, it works as expected. That's why I said there is something else involved in your case.
Coordinator
Aug 1, 2015 at 6:24 PM
And last remark: your registry extract is missing some "/" in the path so it can't work like that. Maybe it's just a copy-past issue. It should look like this:
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
"VeraCrypt"="\"C:\\Program Files\\VeraCrypt\\VeraCrypt.exe\" /q preferences /a logon /a favorites"
Aug 1, 2015 at 7:44 PM
No, using no password, only keyfile stored in user profile

This is right export

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
"TrueCrypt"="\"C:\Program Files\TrueCrypt\TrueCrypt.exe\" /q preferences /a logon /a favorites"
"VeraCrypt"="\"C:\Program Files\VeraCrypt\VeraCrypt.exe\" /q preferences /a logon /a favorites"

It shows Vera is using exactly same startup switches. While TC starts always.
tho TC has problems with accessing it's encrypted keyfile too (content altered between PC restarts).

May the keyfile not be ready at startup time?
Coordinator
Aug 1, 2015 at 8:08 PM
As I have shown in the Youtube video above, the mechanism with only a keyfile works. So, as I said, the problem is elsewhere.

I don't know the specifics of your machine. Maybe there is an issue with the accessibility of the keyfile, maybe something else...it is hard to investigate such things without having the machine at hand. All I can do is give you hints to investigate your particular situation.
You can for example start by moving the keyfile to another location outside user profile to see if the issue comes from there. You also said that the content of the keyfile is altered between restarts so maybe you should look in the direction of a process corrupting your files.

Anyway, the important thing here is to show that there are no issues with VeraCrypt mounting mechanism and that the mounting time can be reduced by using a customer PIM value (I used 7 in the video but one can use 1).
Aug 1, 2015 at 8:11 PM
Is Vera even compatible with Windows 10?
All the system is fucked up, encrypted files alter, progrms complain about access rights. I dont know what's wrong.
Coordinator
Aug 1, 2015 at 10:16 PM
Of course it is compatible...I have been working on Windows 10 compatibility since beginning of June and nothing wrong came up.
You can see my video that shows it is working on the final Windows 10 that was released 2 day ago. I have also made a video showing a Windows 10 encrypted system as a Decoy OS for a Hidden OS that is Windows 7. The video is here: https://www.youtube.com/watch?v=wInvy8GEkGU

Just to check: you can use test volumes created here in order to check if they work on your machine. Their password is test. You can get them from https://bitbucket.org/veracrypt/veracrypt/downloads/VeraCryptTestVolumesWindows.zip
Aug 2, 2015 at 3:32 AM
Is the current problem tukan is experiencing due to Apple bootcamp?

Forum member duntuk made the following discovery for his system in the issue "Cannot access any encrypted file containers after Windows 10 upgrade".

duntuk wrote:
The problem has to do with Apple Bootcamp drivers....

Followed directions here:
https://discussions.apple.com/thread/7140688
  1. Run Sysinternals Autoruns "Autoruns.exe" as administrator.
  2. Search for: apple
  3. uncheck Apple HFS
  4. Done. Reboot...
Other note: I also went into add/remove software and selected "repair" for Apple bootcamp... Not sure if that did anything...

I only installed bootcamp to get Apple Keyboard and Apple Thunderbolt display drivers working...

There's also a note saying to install the latest bootcamp version--this may also fix the problem; not sure since I haven't tested that....
Aug 2, 2015 at 6:08 AM
Edited Aug 2, 2015 at 6:22 AM
No that's apparently not same case. If I read the topic the problem there is about not accessing once mounted volume, problem here is not automountning volumes using encrypted keyfiles. Once my volumes are mounted in VC/TC manually later they expose no problems (edit: they can't handle NTFS encrypted files as written below). Also I don't have installed Paragon HFS on Windows 10.
There must be something very weird with file system or files security in Windows 10.
I unencrypted both keyfiles, after restart
TC 's keyfile seems no more been altered during restart (TC was able automount correctly)
VeraCrypt still not auto starting (or it autostarts but due some problem it dies silently). Does it provide some logging? This is very weird and I need to know what's happening.
More observations: test volumes can mount, still long mount times, trying to copy my encrypted keyfile on NTFS of them I get error Incorrect function. This sounds similar to error described in the other thread. In summary

copy encrypted keyfile -> VC volume (NTFS) => Incorrect function
copy unencrypted keyfile -> VC volume (NTFS) => OK
copy encrypted keyfile -> VC volume (FAT) => OK
copy unencrypted keyfile -> VC volume (FAT) => OK
copy encrypted keyfile -> TC volume (NTFS) => Incorrect function
copy unencrypted keyfile -> TC volume (NTFS) => OK
copy encrypted keyfile -> local regular volume (FAT or NTFS) => OK
copy unencrypted keyfile -> local regular volume (FAT or NTFS) => OK

Furthermore copying unencrypted file to VC or TC NTFS volume and set it encrypted then succeeds but trying to access it results again in Incorrect function error. In short there seems to be some incompatibility between TC/VC NTFS encryption and Windows 10 NTFS encryption. Disk info shows me system drive NTFS version still 3.01. All the Windows 10 filesystem is very weird, In encrypted private folder setting/unsetting encrypted attribute for .bat files results in access denied error while I still can edit/delete them and can still change encryption for other files, WTF?
Using same personal certificates as on Windows 8, and can copy encrypted files between Windows 10 ↔ Windows 8 local drives also
Aug 2, 2015 at 6:35 AM
Can someone confirm problem of NTFS encrypted files transferability between VC and regular volume, or is only appearing on my PC?
Aug 2, 2015 at 6:20 PM
LOL so I installed Windows 10 again, all clean, let create new personal certificate and imported old cert, made encrypted folder inside user profile, put all keyfiles from reliable backup into it, configured VC along TC, assigned favs, marked for automount on logon. The diff is now VC and TC both try automount their favs but randomly on start TC also VC ask for nonexisting password due their keyfike gets altered. Either or both, chances are 50/50. So I guess it's Windows timing problem rather than Vera.
Can anybody verify if this scheme is making problem? Win10, mount against EFS encrypted keyfile at logon.
Coordinator
Sep 5, 2015 at 2:49 PM
You didn't mention the fact that your keyfiles are encrypted using EFS...Unfortunately, not mentioning such details wastes your time and ours since no one could replicate your issue.
Not only you but other also forget to mention key elements in their configuration and this makes any analysis not reliable.

Anyway, in your case, it is just a matter of Windows not decrypting your EFS encrypted folder on time for TC/VC to access the keyfiles their. By design, Windows doesn't guarantee in which order programs the autorun will execute. One solution in your case if to create a task in Windows Task Scheduler to run the exacte VeraCrypt command after 1 minute or so after your session opens and remove VeraCrypt entry from the registry.