search

AlexSSD7 / linsk

📂 Access Linux-native file systems (including LVM and LUKS) on Windows and macOS with help of a lightweight Alpine Linux VM. x86/ARM supported.
GNU General Public License v3.0
303 stars 13 forks source link

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

Closed dosssman closed 1 year ago

dosssman commented 1 year ago

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.

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:

image

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.

Thanks a lot for your time. Best regards.

AlexSSD7 commented 1 year ago

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 commented 1 year ago

I added a double-mount warning here: https://github.com/AlexSSD7/linsk/commit/9ccd820e7193a761d7abb86f6140e28c5bc6bb65.

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 :sweat_smile:

dosssman commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

dosssman commented 1 year ago

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 commented 1 year ago

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: https://github.com/AlexSSD7/linsk/commit/94fe9e95c9f4abb72a62459d55697ba96584aa44

dosssman commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Here is what I got, after doing:

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

image

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

dosssman commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 < 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, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

dosssman commented 1 year ago

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 :sweat_smile:

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 commented 1 year ago

You're most welcome!

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

dosssman commented 1 year ago

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 commented 1 year ago

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