LUKS device opened successfully but failed to mount | Suggestions for usage instructions on windows about linsk HOT 19 CLOSED

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 😅

from linsk.

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

from linsk.

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

from linsk.

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.

from linsk.

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.

from linsk.

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\.

from linsk.

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.

from linsk.

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

from linsk.

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

from linsk.

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 ?

from linsk.

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.

from linsk.

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 ...

from linsk.

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.

from linsk.

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.

from linsk.

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.

from linsk.

from linsk.

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.

from linsk.

You're most welcome!

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

from linsk.

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 ?

from linsk.