LUKS device opened successfully but failed to mount | Suggestions for usage instructions on windows

[dosssman]

Hello there.
Thanks a lot for making this tool and publishing it.
I have been looking for this kind of features for a while now, the WSL based alternative I found was not really cutting it.

Failing to mount LUKS device

Thought I would give it a try, but I stumbled upon this error I could not solve, so I was wondering if you had any idea on what might be the cause.

1. How it was installed
   Following INSTALL_WINDOWS.md:

• Grabbed the pre-built binaries from github, linsk v0.1.0 Initial release for amd64
• Installed QEMU and OpenVPN.

2. What I ran
   Following USAGE_WINDOWS.md, and running commands in cmd.exe started as administrator.

• building using linsk build
• Identified the device of interest: \\.\PhysicalDrive3
• Listing detected partitions using linsk ls returns:

linsk ls dev:\\.\PhysicalDrive3
time=2023-09-06T19:37:43.107+09:00 level=WARN msg="Using raw block device passthrough. Please note that it's YOUR responsibility to ensure that no device is mounted in your OS and the VM at the same time. Otherwise, you run serious risks. No further warnings will be issued." caller=vm
time=2023-09-06T19:37:43.156+09:00 level=INFO msg="Booting the VM" caller=vm
time=2023-09-06T19:37:58.318+09:00 level=INFO msg="The VM is up, setting it up" caller=vm
time=2023-09-06T19:38:05.043+09:00 level=INFO msg="The VM is ready" caller=vm
NAME     SIZE FSTYPE      LABEL
vda        1G
├─vda1   300M ext4
├─vda2   256M swap
└─vda3   467M ext4
vdb    931.5G
├─vdb1   250G ntfs        ELECOM USBH
└─vdb2 681.5G crypto_LUKS
time=2023-09-06T19:38:06.475+09:00 level=WARN msg="Canceling the VM context" caller=vm
time=2023-09-06T19:38:06.525+09:00 level=WARN msg="Sending poweroff command to the VM" caller=vm
time=2023-09-06T19:38:06.536+09:00 level=INFO msg="Shutting the VM down safely" caller=vm

• Attempt at mounting the LUKS partition:

linsk run -l dev:\\.\PhysicalDrive3 vdb2 ext4
time=2023-09-06T19:39:57.966+09:00 level=INFO msg="Created network tap" name=LinskTap-1693996797477168400
time=2023-09-06T19:39:57.998+09:00 level=INFO msg="Configured network tap" name=LinskTap-1693996797477168400 cidr=fe8f:5980:3253:7df4:f4b:6db1:a1d8:fc66/127
time=2023-09-06T19:39:58.046+09:00 level=WARN msg="Using raw block device passthrough. Please note that it's YOUR responsibility to ensure that no device is mounted in your OS and the VM at the same time. Otherwise, you run serious risks. No further warnings will be issued." caller=vm
time=2023-09-06T19:39:58.096+09:00 level=INFO msg="Booting the VM" caller=vm
time=2023-09-06T19:40:13.228+09:00 level=INFO msg="The VM is up, setting it up" caller=vm
time=2023-09-06T19:40:19.957+09:00 level=INFO msg="The VM is ready" caller=vm
time=2023-09-06T19:40:20.598+09:00 level=INFO msg="Mounting the device" dev=vdb2 fs=ext4 luks=true
time=2023-09-06T19:40:20.641+09:00 level=INFO msg="Attempting to open a LUKS device" caller=file-manager vm-path=/dev/vdb2
Enter Password:
time=2023-09-06T19:40:26.933+09:00 level=INFO msg="LUKS device opened successfully" caller=file-manager vm-path=/dev/vdb2
time=2023-09-06T19:40:32.577+09:00 level=ERROR msg="Failed to mount the disk inside the VM" error="run mount cmd: run cmd (log: 'mount: /mnt: can't read superblock on /dev/mapper/cryptmnt.\\n       dmesg(1) may have more information after failed mount system call.'): Process exited with status 32"
time=2023-09-06T19:40:32.577+09:00 level=WARN msg="Canceling the VM context" caller=vm
time=2023-09-06T19:40:32.624+09:00 level=WARN msg="Sending poweroff command to the VM" caller=vm
time=2023-09-06T19:40:32.634+09:00 level=INFO msg="Shutting the VM down safely" caller=vm
time=2023-09-06T19:40:33.889+09:00 level=INFO msg="Deleted network tap" name=LinskTap-1693996797477168400

For reference, I can mount that partition on a native linux machine with:

cryptsetup open /dev/sdXY cryptmnt
mount /dev/mapper cryptmnt /mnt

I tried to mount the ntfs device vdb1 instead.
While the mounting did succeed, I could not access the network share.
After entering the address into Windows Epxloror, it prompts for the username (linsk) and password (randomly generated one), but even after entering those two as per instructions, it shows:

I am not that familiar with Network Shares, so maybe I am doing it completely wrong.
Would appreciate any feedack or additional instructions on how to do this.

Suggestion for INSTALL_WINDOWS

After installing qemu using the link provided, the install path of qemu-img had to be added to the PATH environment variable of Windows, otherwise, running linsk build would throw an error along the line of could not find 'qemu-img' in %PATH%.
It might be worth mentioning to make the downstream usage experience smoother.

Suggestion for USAGE_WINDOWS

Around here, after identifying the disk of interest, it might be worth adding a note for the user to make sure that drive is not mounted by Windows.
One way to do it is to start diskmgmt, select the corresponding drive, and putting it "Offline".
There might be an equivalent wmic command, but not much time to look it up sorry.

Others

Not sure if those features are already there, or on the roadmap, but here are some things I thought would be a nice addition while trying to get it running.

• Ability to specify or fix the SMB Network share address, as well as login username and password for more persistent usage. (Namely,, I would like to keep that vdb2 partition available all the time at a fixed location. Having to log in every time with different credential is not really convenient for this use case.)

Thanks a lot for your time.
Best regards.

[AlexSSD7]

Hi @dosssman!

Thanks for reaching out.

Please try running linsk shell and see whether you can mount the drive like it's a regular Linux machine. I have a feeling that you are specifying wrong file system, causing superblock reads to fail.

As for the failure connecting to the SMB share, it seems like Windows is complaining because some of the SMB security features were disabled. It was done intentionally as Linsk is never exposed to anything but the host machine itself. Unfortunately they don't tell you exactly what is missing, so you have multiple options to try: https://answers.microsoft.com/en-us/windows/forum/all/you-do-not-have-permission-to-access-pcname/704f39f0-a03e-4f1c-bead-a45df97e455d.

[AlexSSD7]

I added a double-mount warning here: 9ccd820.

As for the qemu-img issue, could you please hint me at the exact path you had to add? To my memory it's C:\Program Files\qemu\bin, but I am not sure. And at this point rebooting to Windows just to find this out would be a real pain 😅

[dosssman]

Thanks for the prompt answer.

Regarding the filesystem, I have tried to mount it manually inside the VM (--vm-debug as well as linsk shell), but I get the same superblock error.

Ran linsk -l dev:\\.\PhysicalDrive3 vdb2 ext4 --vm-debug and got an interactive shell.

From there, I unlocked the device manually, and check the type with blkid and it does seem to be ext4.

/dev/mapper/cryptmnt: UUID=<xxxxxxx> BLOCK_SIZE="4096" TYPE="ext4"

but manually mounting with mount /dev/mapper/cryptmnt /mnt still throws the same error "can't read superblock".

Doing the same on my native linux system works without problem though.
I am not familiar with Alpine, but could it maybe due to old version of some binaries ?

As for the qemu-img issue, could you please hint me at the exact path you had to add? To my memory it's C:\Program Files\qemu\bin, but I am not sure. And at this point rebooting to Windows just to find this out would be a real pain 😅

I feel the pain. The path is C:\Program Files\qemu in my case.

[AlexSSD7]

You need to add -t ext4 to the mount command. This is a specific of Alpine Linux inherited from Busybox. It doesn't support file system auto-detection.

mount -t ext4 /dev/mapper/cryptmnt /mnt

I feel the pain. The path is C:\Program Files\qemu in my case.

Can you please check and confirm to be 100% sure? I can clearly remember bin\.

[dosssman]

Can you please check and confirm to be 100% sure? I can clearly remember bin.

As of qemu-w64-setup-20230822, there does not seem to be a bin folder in there.
I have double checked.

[AlexSSD7]

That's weird, but thanks for confirming. I'll check on my end.

[dosssman]

file system auto-detection.

mount -t ext4 /dev/mapper/cryptmnt /mnt

I feel the pain. The path is C:\Program Files\qemu in my case.

Can you please check and confirm to be 100% sure? I can clearly remember bin\.

Same error even with -t ext4

[AlexSSD7]

Try running fsck on a normal Linux machine and see whether there it manages to find any issues with your ext4 file system:

fsck.ext4 /path/to/mapped/cryptmnt

Since Alpine Linux is a very lightweight Linux distribution, it could be it doesn't have built-in file system auto-correction features.

Also, you are right, it's just \qemu indeed. It's the OpenVPN tap things that are located in bin\ subdirectory. Here's an INSTALL_WINDOWS.md update: 94fe9e9

[dosssman]

Also made vdb1 into an ext4 partition instead, and ran linsk run dev:\\.\PhysicalDrive3 vdb1 ext4 to make sure it is not due to LUKS, but I also get the same error.

FS checks with e2fsck and fsck.ext4 also do not return any error.
Tried to check alignment of partition alignment too with:

parted /dev/sdc1 # Fresh ext4 partition
align-check opt 1 # because sdc1
# Output: aligned

Maybe I should try to build the whole project instead ? Will there be any significant difference compared to the pre-build binaries ?

[AlexSSD7]

No, there won't be any difference.

This is weird. Please try mounting in the shell, and after you run into the same "read superblock" error, do dmesg -T and try finding something that looks like ext4 errors. It should be right in the end of the dmesg log.

[dosssman]

Here is what I got, after doing:

cryptsetup open /dev/vdb2
mount -t ext4 /dev/mapper/cryptmnt /mnt

Also tried with another drive I got with similar structure (LUKS over LVM), but same problem ...

[dosssman]

I will give it a rest for today.
Will try again later with yet another drive, completely formated with a single ext4 partition on it.

Just for later reference, but how do you usually create the ext4 partition on your side ?
I used GParted in my case.

[AlexSSD7]

This appears to be an issue with with QEMU block device passthrough. Reads seem to be okay, but not writes. Not an ext4 problem.

Please try building and running off qemu-debug branch with --vm-debug flag. I implemented direct QEMU log passthrough, so you will see if there are any warnings emitted by QEMU in the terminal.

Link: https://github.com/AlexSSD7/linsk/tree/qemu-debug

I might suspect that it could be some sort of antivirus blocking write access to raw drives.

[dosssman]

Please try building and running off qemu-debug branch with --vm-debug flag. I implemented direct QEMU log passthrough, so you will see if there are any warnings emitted by QEMU in the terminal.

Cloned the repo, checked out into qemu-debug branch, ran go build and copied the resulting linsk.exe into C:\Users\%USERNAME%\go\bin so that it is detected, run linsk with --vm-debug and attempt to manually mount it, but the exact same error message is shown.

Also, I have no antivirus running, not even Windows Defender.

Is it maybe because I put the PhysicalDrive3 as "Offline" in diskmgmt.exe ?
It is the only thing that does not make linsk say "configure vm cmd block device passthrough: device \\.\PhysicalDrive3' seems to be already mounted in the host system".
I am curious on how you "unmount" the drive so that it is not used by Windows.

Thank you for your time.

[AlexSSD7]

Do you see additional warnings when the new version is run? And yes, I suggest bringing it online, now that you don’t have an NTFS partition to be mounted.

…

On Wed, Sep 6, 2023 at 14:13, Rousslan F.J. Dossa ***@***.***(mailto:On Wed, Sep 6, 2023 at 14:13, Rousslan F.J. Dossa <<a href=)> wrote: > Please try building and running off qemu-debug branch with --vm-debug flag. I implemented direct QEMU log passthrough, so you will see if there are any warnings emitted by QEMU in the terminal. Cloned the repo, checked out into qemu-debug branch, ran go build and copied the resulting linsk.exe into C:\Users\%USERNAME%\go\bin so that it is detected, run linsk with --vm-debug and attempt to manually mount it, but the exact same error message is shown. Also, I have no antivirus running, not even Windows Defender. Is it maybe because I put the PhysicalDrive3 as "Offline" in diskmgmt.exe ? It is the only thing that does not make linsk say "configure vm cmd block device passthrough: device \\.\PhysicalDrive3' seems to be already mounted in the host system". I am curious on how you "unmount" the drive so that it is not used by Windows. Thank you for your time. — Reply to this email directly, [view it on GitHub](#2 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AKIMUEFAUH6J5F3CTN7JPDDXZBZJJANCNFSM6AAAAAA4NFVCBA). You are receiving this because you commented.Message ID: ***@***.***>

[dosssman]

Got it. It was because it was put "Offline".
I put it online and remove Windows mounting letter from the NTFS partition it it managed to mount it.
Sorry for the trouble 😅

Still have to figure out how to access it via SMB, but I guess the main issue can be considered as solved.
Enabled SMB 1.0 in Windows Features, rebooted and now it is working as expected.
Great piece of software.

Thansk a lot for the assistance.

[AlexSSD7]

You're most welcome!

I think it's a good idea to add a note somewhere that drives should be online.

[dosssman]

Sounds good.

Do you have any recommendation on how to setup the share as something more permanent ?
Namely, fixing the network share address, username and password for access ?

[AlexSSD7]

This is something that needs to be implemented. You are welcome to open a feature-request-style issue here.