Can't open partition created on windows disk in linux, but when doing this with USB drive everything is good

[napolegend]

Unable to mount encrypted volume between Linux and Windows.
TL;DR

If I encrypt a partition in Windows I'm unable to mount it in Linux, and vice versa. Yet they both mount on the OS they were created on just fine. What am I doing wrong?

The details.

I have a dual-boot encrypted setup (Grub has two options: One for Window which loads the VeraCrypt boot loader and one for Linux Mint which loads the LUKS magic. Therefore both my OSs are encrypted and launch just fine. they are not on same disks). But I also want a VeraCrypt encrypted partition/volume that I can load from either side to dump common files in to. I have a partition set aside for this.

The problem is, if I encrypt the partition in Windows I'm able to mount it within Windows and create files just fine. But when I try to mount this volume from within VeraCrypt in Linux by selecting the partition, I get the below error.

And the same problem goes from the Linux side: I can create the encrypted volume using the partition (I even select the "will be used by other system" option) and mount and use it just fine from within Linux. But trying to mount it from Windows chucks out the same error.

If I encrypt an external USB device, I'm able to mount this in either OS just fine. Why would a partition be treated differently? What am I missing here?

The error.

Operation failed due to one or more of the following:

• Incorrect password.
• Incorrect Volume PIM number.
• Incorrect PRF (hash).

[idrassi]

This looks like an MBR whole system drive encryption case.

If Windows was encrypted with "Encrypt the whole drive", then the shared partition is already within the key scope of VeraCrypt system encryption. It isn't mounted on Windows as a separate VeraCrypt volume: it becomes visible because the Windows VeraCrypt driver has already decrypted the disk after pre-boot authentication.

On Linux, mounting /dev/sdXN as a normal VeraCrypt volume will fail because the VeraCrypt header is not at the start of that partition. You need to mount that partition using the system-encryption mode:

GUI: Options > Mount partition using system encryption (preboot authentication)

CLI example:

veracrypt -t --mount-options=system /dev/sdXN /media/veracrypt1

Use the Windows pre-boot password/PIM/hash. Also note that this mode is supported only for primary partitions: MBR extended/logical partitions cannot be mounted this way.

The "will be used by other systems" option only concerns filesystem portability. It does not compensate for the outer Windows while disk system encryption layer. If you created the partition from Linux, Linux wrote to header to the partition, which explains why Windows then cannot mount it since it thinks it is in whole-disk encryption mode.

@napolegend can you please confirm that you are indeed using MBR boot with whole drive encryption?

[napolegend]

I use GPT partition mode. Yes, I indeed have chosen the option for full system encryption in veracrypt for windows and have created the common partition on the disk where windows is stored. When I try to open the windows partition /Dev/sda2 with system option in veracrypt it opens normally, but /Dev/sda3 (common partition ) says there's no NTFS header or smth like that.
@idrassi

[idrassi]

@napolegend
Thank you for the details. In GPT/EFI, there is no whole drive encryption, only Windows system partition can be encrypted. This means that the common partition was encrypted separately after Windows system partition was encrypted, right?

I insist on this because it is important to be clear on how and when the common partition was encrypted.

I will need to investigate this further by creating a similar setup on VM. This needs some time but your answer to my question will help during this process so I can follow your exact steps chronologically.

[napolegend]

@napolegend
Thank you for the details. In GPT/EFI, there is no whole drive encryption, only Windows system partition can be encrypted. This means that the common partition was encrypted separately after Windows system partition was encrypted, right?

I insist on this because it is important to be clear on how and when the common partition was encrypted.

I will need to investigate this further by creating a similar setup on VM. This needs some time but your answer to my question will help during this process so I can follow your exact steps chronologically.

Yes, I created (by shrinking the system partition) and encrypted the common partition after encrypting the system partition.

[idrassi]

@napolegend

Yes, I created (by shrinking the system partition) and encrypted the common partition after encrypting the system partition.

So you performed shrinking before starting system encryption, then you encrypted the system partition and then you encrypted the common partition. right?

I am also checking whether there is a Linux offset/scope issue in your case. Please provide the output of:

sudo lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,PARTTYPENAME,PARTUUID,MOUNTPOINTS
sudo blockdev --getss /dev/sda /dev/sda2 /dev/sda3
cat /sys/block/sda/sda2/start /sys/block/sda/sda3/start
sudo fdisk -l /dev/sda

[napolegend]

@napolegend

Yes, I created (by shrinking the system partition) and encrypted the common partition after encrypting the system partition.

So you performed shrinking before starting system encryption, then you encrypted the system partition and then you encrypted the common partition. right?

I am also checking whether there is a Linux offset/scope issue in your case. Please provide the output of:

sudo lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,PARTTYPENAME,PARTUUID,MOUNTPOINTS
sudo blockdev --getss /dev/sda /dev/sda2 /dev/sda3
cat /sys/block/sda/sda2/start /sys/block/sda/sda3/start
sudo fdisk -l /dev/sda

No, i performed shrinking after encrypting the system and then encrypted the partition

sudo lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,PARTTYPENAME,PARTUUID,MOUNTPOINTS
NAME                  PATH                          SIZE TYPE  FSTYPE      PARTTYPENAME                 PARTUUID                             MOUNTPOINTS
sda                   /dev/sda                    894.3G disk                                                                                
├─sda1                /dev/sda1                      16M part              Microsoft reserved           f14ba4c5-1233-456c-93d5-56405d58005c 
├─sda2                /dev/sda2                     799G part              Microsoft basic data         129554a8-440b-48f9-9f39-e5f298e3a533 
├─sda3                /dev/sda3                      94G part              Microsoft basic data         04cda02f-fa63-4250-860c-0e2995c4d25a 
├─sda4                /dev/sda4                     511M part  vfat        EFI System                   0614d7a2-0ce2-407e-88ef-245be0b80ae6 
└─sda5                /dev/sda5                     781M part  ntfs        Windows recovery environment 3780d276-48c6-497e-bb87-25e5dc4d68a4 
zram0                 /dev/zram0                      8G disk  swap                                                                          [SWAP]
nvme0n1               /dev/nvme0n1                953.9G disk                                                                                
├─nvme0n1p1           /dev/nvme0n1p1                951G part  crypto_LUKS Linux LVM                    a1e47e53-5c57-4964-b88b-7020c98f0e6f 
│ └─cryptlvm          /dev/mapper/cryptlvm          951G crypt LVM2_member                                                                   
│   ├─MyVolGroup-root /dev/mapper/MyVolGroup-root   200G lvm   ext4                                                                          /
│   └─MyVolGroup-home /dev/mapper/MyVolGroup-home   751G lvm   ext4                                                                          /home
└─nvme0n1p2           /dev/nvme0n1p2                2.9G part  vfat        EFI System                   26887789-8bac-4cbf-bdb4-d310d08f56d0 /boot

sudo blockdev --getss /dev/sda /dev/sda2 /dev/sda3
512
512
512

cat /sys/block/sda/sda2/start /sys/block/sda/sda3/start
34816
1675640832

sudo fdisk -l /dev/sda
Disk /dev/sda: 894.25 GiB, 960197124096 bytes, 1875385008 sectors
Disk model: KINGSTON SA400S3
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: DD6AB481-684B-4953-B66C-690C0AF00210

Device          Start        End    Sectors  Size Type
/dev/sda1        2048      34815      32768   16M Microsoft reserved
/dev/sda2       34816 1675640831 1675606016  799G Microsoft basic data
/dev/sda3  1675640832 1872732159  197091328   94G Microsoft basic data
/dev/sda4  1872734208 1873780735    1046528  511M EFI System
/dev/sda5  1873782784 1875382271    1599488  781M Windows recovery environment

[idrassi]

@napolegend Thank you, this chronology is important. The important point is that you shrank the Windows partition after system encryption had already been enabled.

Your /dev/sda3 starts at sector 1675640832, immediately after the current /dev/sda2. Since the Windows system partition was originally larger before the shrink, the VeraCrypt system encryption header still describes the original encrypted area. So the sectors that are now /dev/sda3 are still inside the Windows system-encryption key scope.

This means that after resizing, the recorded system encryption area still covers sectors that now belong to the new common partition. Since you encrypted /dev/sda3 from Windows, Windows wrote the normal non-system VeraCrypt header through the active system encryption driver. So the raw disk would contain:

SystemEncryption( non-system VeraCrypt header )

not the non-system VeraCrypt header directly.

That would explain why:

1. The common partition works on Windows the driver decrypts the header before it reaches the non-system mount logic
2. A normal VeraCrypt mount of /dev/sda3 on Linux fails since the header is encrypted using Windows system encryption
3. Mounting /dev/sda3 with the system option reaches a “no NTFS header” type error: after removing the system-encryption layer, the first bytes are a VeraCrypt volume header, not an NTFS boot sector.

Please try this diagnostic test from Linux, read-only first:

sudo mkdir -p /mnt/vc-common

sudo veracrypt -t --filesystem=none -m system,readonly --slot=1 /dev/sda3

sudo veracrypt -t -l

After the first mount, check the “Virtual Device” path shown by veracrypt -t -l. It will probably be /dev/mapper/
veracrypt1. Then try mounting that virtual device as the normal common VeraCrypt volume:

sudo veracrypt -t -m readonly --slot=2 /dev/mapper/veracrypt1 /mnt/vc-common

For the first command, enter the Windows pre-boot/system password.
For the second command, enter the common partition password.

If this two stage mount works, then it would confirm that /dev/sda3 is still physically inside the encrypted area recorded in the Windows system-encryption header.

Currently, VeraCrypt doesn't intercept a shrink/layout change and so it doesn't adjust the system-encryption header accordingly: the header keeps the encrypted-area start/length that existed when system encryption was configured. Thus, shrinking the Windows partition after encryption leaves the newly created partition inside the old system-encryption key scope.

I will analyze if shrinking and growing of the system partition can be handled correctly so that the offset/length of the partition stored in the system-encryption header is updated

[napolegend]

@napolegend Thank you, this chronology is important. The important point is that you shrank the Windows partition after system encryption had already been enabled.

Your /dev/sda3 starts at sector 1675640832, immediately after the current /dev/sda2. Since the Windows system partition was originally larger before the shrink, the VeraCrypt system encryption header still describes the original encrypted area. So the sectors that are now /dev/sda3 are still inside the Windows system-encryption key scope.

This means that after resizing, the recorded system encryption area still covers sectors that now belong to the new common partition. Since you encrypted /dev/sda3 from Windows, Windows wrote the normal non-system VeraCrypt header through the active system encryption driver. So the raw disk would contain:

SystemEncryption( non-system VeraCrypt header )

not the non-system VeraCrypt header directly.

That would explain why:

1. The common partition works on Windows the driver decrypts the header before it reaches the non-system mount logic
2. A normal VeraCrypt mount of /dev/sda3 on Linux fails since the header is encrypted using Windows system encryption
3. Mounting /dev/sda3 with the system option reaches a “no NTFS header” type error: after removing the system-encryption layer, the first bytes are a VeraCrypt volume header, not an NTFS boot sector.

Please try this diagnostic test from Linux, read-only first:

sudo mkdir -p /mnt/vc-common

sudo veracrypt -t --filesystem=none -m system,readonly --slot=1 /dev/sda3

sudo veracrypt -t -l

After the first mount, check the “Virtual Device” path shown by veracrypt -t -l. It will probably be /dev/mapper/
veracrypt1. Then try mounting that virtual device as the normal common VeraCrypt volume:

sudo veracrypt -t -m readonly --slot=2 /dev/mapper/veracrypt1 /mnt/vc-common

For the first command, enter the Windows pre-boot/system password.
For the second command, enter the common partition password.

If this two stage mount works, then it would confirm that /dev/sda3 is still physically inside the encrypted area recorded in the Windows system-encryption header.

Currently, VeraCrypt doesn't intercept a shrink/layout change and so it doesn't adjust the system-encryption header accordingly: the header keeps the encrypted-area start/length that existed when system encryption was configured. Thus, shrinking the Windows partition after encryption leaves the newly created partition inside the old system-encryption key scope.

I will analyze if shrinking and growing of the system partition can be handled correctly so that the offset/length of the partition stored in the system-encryption header is updated

Big thanks! It have opened after that all. I see all my files. Now, how can i manage the system encryption so it takes my partition out of it's encryption scope and decrypts it from the system encryption?
Also I have also seen some proof of that when I saw that my windows partition size is 793Gb and Veracrypt encrypted system part was ~880Gb.

[idrassi]

@napolegend
Thank you for the confirmation.

As for the solution, we cannot fix your case by only changing the system-encryption header. The existing bytes in /dev/sda3 are still encrypted by the outer system-encryption layer, so reducing the recorded system-encryption scope without removing that layer first would make the common partition appear corrupted.

The safest recovery path is:

1. Back up the data from the common partition first
2. Dismount the common partition
3. Permanently decrypt the Windows system encryption. Because the current VeraCrypt header still records the old larger encrypted area, this will remove the outer system-encryption layer from the sectors now used by /dev/sda3
4. Verify that /dev/sda3 mounts as a normal VeraCrypt partition from both Linux and Windows
5. Enable Windows system encryption again. It should then record the current Windows system partition size, leaving the common partition outside the system-encryption scope

I will keep this issue open because VeraCrypt should handle this situation better. The Windows driver currently keeps the encrypted-area scope from the system header, and after a live shrink the header is not resynchronized with the new system partition length. A proper fix needs to handle the Windows shrink path safely, including FSCTL_SHRINK_VOLUME / IOCTL_DISK_GROW_PARTITION, update both the system header volume size and encrypted-area length when appropriate, or block unsafe shrink operations until this is implemented.