Unable to mount Windows encrypted system partition on NVME from Linux

[gv5470]

Hello,
I recently bought a Samsung SSD 960 EVO M.2 PCIe NVMe disk, and proceeded to use it as my system disk for both Windows 10 and Linux Ubuntu 16.04. I successfully installed Windows 10 and encrypted its partition using Veracrypt 1.21; after that I managed to set up the dual boot with Ubuntu.
However I can't access my Windows 10 system partition from Ubuntu, using Veracrypt 1.21 for Linux, and I get the following error message: "Partition device required".

After some investigation, it appears that the fact the windows partition is located on a nvme disk, thus having an unusual block device name (/dev/nvme0n1p2), is the cause of the problem. Indeed in order to get the block device name of the hosting drive, the FilesystemPath::ToHostDriveOfPartition () method currently only removes the trailing number of the block device name of the partition. In the case of this particular naming scheme, we get a "/dev/nvme0n1p", instead of the expected "/dev/nvme0n1".
I found a little workaround, adding 4 lines inside the #ifdef TC_LINUX block in FilesystemPath::ToHostDriveOfPartition ():

#ifdef TC_LINUX
        path = StringConverter::StripTrailingNumber (StringConverter::ToSingle (Path));

        // WORKAROUND BEGIN
        string pathStr = StringConverter::ToSingle (path);
        size_t t = pathStr.find("nvme");
        if(t != string::npos)
            path = pathStr.substr (0, pathStr.size() - 1);
        // WORKAROUND END

#elif defined (TC_MACOSX)

Do you think this fix is valid/reliable ? And if so, would it be possible to include it in the next release ?

[Matthew Adie]

Did you ever recieve any feedback on this, or was another workaround suggested? I'm having the exact same problem. I'd really like to be able to access my windows encrypted system drive from linux...

Matthew

[gv5470]

Hello,

I submitted this as a pull request on Github, but I didn't get feedback thus far, nor have I seen any other workaround being reported to the community.

I would actually be interested in knowing whether this workaround behaves as expected on another computer, so if you are motivated enough to build VeraCrypt by yourself, feel free to clone the fork repository I created for the occasion at https://github.com/gv5470/VeraCrypt .
The workaround is on the patch branch (to directly retrieve this branch, use: git clone https://github.com/gv5470/VeraCrypt.git -b patch).

What Linux distribution do you use?

[Matthew Adie]

I'm currently using Ubuntu 17.10. I'm on vacation right now, but I'll try building it when I get back and I'll let you know how it goes.

[Dominik]

I was experiencing the same issue while trying to mount a partition residing on a loop device(/dev/loop1p1 with /dev/loop1 as the hosting drive).

Your workaround adresses the right issue: The assumption how the hostdrive can be found based on the partiton device is not general enough and fails if a device class with a different naming convention is used.

Your workaround works for me, if I replace the string "nvme" with "loop". I am very thankful for your investigation since it pointed in the right direction and saved me a lot of time!

However, I think that this should be classified as a quick fix rather than a production ready patch. For the latter someone should review the ToHostDriveOfPartition method from scratch and implement it more general but also make it consistent with the documentation(e.g. which device types are supported on which systems)

[gv5470]

Hello,
Thanks for the feedback. I agree on the quick fix aspect, this is just a first step.

Since then, I seem to have discovered a way to get the host drive name using sysfs. This more elaborate fix is more general and would allow to mount any volume not following the old /dev/sda naming scheme (nvme drives, loop devices, SD memory cards...). I would like to get some feedback on it however, in order to check that it works on several distros.
If you want to try it out, you can find said fix here: https://github.com/gv5470/VeraCrypt/tree/patch-233

EDIT: The said fix has been merged to upstream, you can now download it from one of the official VeraCrypt repositories.