How to attach loop device to Windows qube? The system does not see it

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.

  1. 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
  2. After that I see device myqube:loop0 in dom0 using command qvm-block list
  3. I have win10 qube, with installed Windows 10 Pro + QWT based on guides.
  4. I attach myqube:loop0 to this win10 qube.
  5. 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.

What can be wrong?

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?

(to test, do the losetup with -r).

1 Like

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.

1 Like

P.S. Consider creating a separate question about read-only attaching, because unfortunately I’ve already marked this one solved.

1 Like

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.

1 Like

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.

1 Like

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.

1 Like