How to attach loop device to Windows qube? The system does not see it.
How I try it:
I have Qubes OS R4.1, all updates installed.
I have qube myqube (appvm with template that is based on fedora-37-minimal) with a file of 10GiB size, that I convert to a loop device with a command: sudo losetup --find --show file-10GiB.bin
After that I see device myqube:loop0 in dom0 using command qvm-block list
I have win10 qube, with installed Windows 10 Pro + QWT based on guides.
I attach myqube:loop0 to this win10 qube.
Windows does not show the new disk even in disk manager (but shows un-partitioned 2GiB and 10GiB devices, that are not related to topic).
What I tried:
attaching using GUI widget and using qvm-block attach in dom0. The same result.
using --persistent flag for qvm-block (while win10 qube was turned off). The same result.
connecting myqube:loop0 to other linux qube, creating MBR partition table on it and 1 primary NTFS partition. It works perfectly well in linux qube, but in Windows there is no sign of disk. . The same result.
Closing my question myself.
The solution was to install QWT with Xen PV Storage driver checkbox being set (which is not a case by default). After re-installation of QWT with this checkbox being set - I see the NTFS disk in the Windows 10.
I have noticed on windows 7, even with QWT installed, that you cannot attach a read only device onto windows and have it work. (Read/write works fine.)
I wonder if Windows 10 is the same way? Would you be willing to check now that you have it working for read/write?
Thank you for this information, it is also true for Win10.
Win10 does not see the attached drive in all this cases:
losetup --read-only
qvm-block attach --ro
losetup --read-only and qvm-block attach --ro
The only working combination is: no read-only flags at all.
I do not know how to mount something read-only this way, if somebody knows - please post it here.
Yes, this is an annoyance. I went to a LOT of trouble to figure out split-veracrypt but I have to remember not to try to attach a read-only decrypted volume to Windows. If I forget I have to undo everything and start over.
I don’t know if this is a bug beyond control of the folks who wrote QWT, or not. Or it may even have been a deliberate design decision for (likely good) reasons I am unaware of.
In the meantime, you can at least attach things to Windows, which is 90 percent of the battle won.
Do you mean that attaching container that is mounted in VC using read-only flag to a Windows qube will somehow allow changing container’a content? I though that the disk will simple “not appear” inside Windows qube.
No, I guess I wasn’t clear. The disk won’t show up. So then I go “grrr” and re-lock the disk, take down and delete the vm that decrypted it, check it back in…and repeat the whole decryption process without the read-only flag.
I have scripts that automate this but it still takes actual time to restart the decryption qube, and I’ve got to type the password in again. Granted, this is a “first world” problem. (And I could solve it by disabling the read-only option in the front end gui…for windows VM destinations.)
As an aside, I experimented once with doing the original losetup (to pass the container to the decryptor) readonly, but then passing it along as read-write downstream–the decrypted container for instance. It “fooled” downstream linux qubes (I don’t recall how windows reacted). You could write to the disk–apparently. But when I gave up the disk and then re-did the process the changes weren’t there. That’s actually worse in some respects; you could “save” a lot of work without realizing you weren’t saving a damned thing. But on the other hand, you also can’t damage the disk even if you do an rm -rf in its top level directory, though it will certainly look as if you trashed it at the time.