I think I've mounted my iny internal hard drive exactly wrong...

[bill...@gmail.com]

I have installed Qubes 4 rc3 on a usb external hard drive. I have Neon linux and Windows on my internal hard drive. I decided I wanted to copy some files from my home directory on my internal hard drive to my Qubes home directory in the fedora26vm.

Unfortunately, I simply can't figure out how to make my internal drive visible to my FedoraVM template.

Oddly, I can go to dom0 and find /dev/sda8 and mount it there, making all the stuff on the internal drive accessible to dom0 -- but I still can't see it in the template vms. This seems to me to be exactly wrong with respect to security, at least after reading the docmentation about making it as hard as possible to copy files to and from dom0. Any bad stuff on my old internal hard drive is easily accessible to dom0, but not to the templates.

I clearly don't get it. So, what do I need to do? How can I make /dev/sda8 visible to my template VM, but not have to mount it on dom0? Or, if I have to mount it on dom0, how do I then make it visible to the templates?

Thanks,
billo

[Yuraeitha]

It may be important not to mount in dom0 when using the widget explained below. Just to be safe, dismount it in dom0 first so nothing happens (no eject though, need it to be visible still). Although I believe the widget-tool can do this itself automated, but it might not be implemented yet similar to how it's not automated on VM shutdown. I suspect this might be automated in the future? Anyhow.

Do you see the little yellow icon up near notifications/clock/sound-widget icons? If you click on that, does your internal drives partition and partition appear here? If it does not, then perhaps there is a design-flaw/bug that disrupts this new Qubes 4 tool when installed on an external drive. IF the bug is there, then my guess is that it was not taken into account in the considerations when designing the tool.

However, whether it's a bug or not remains to be seen first. Try check if you can see the internal drive in the little widget.

If it indeed turns out to be either a bug or design flaw that disallows connecting to internal devices when system is installed on an external drive, then, go to github, find the Qubes OS group in seach. Search in issues and see if you can find a similar issue. If you can, then post your results in the same post you found. If you don't find any, post a new one and explain the issue first briefly so an overview can be established of the issue, and then all the details below.

Having it on github in this way allow the developers to easier find this issue, track it, and over time get it fixed. It might? get a lot priority though, if there are many things more critical to work on than getting internal SATA devices to work while the system is installed on an external drive. After all, Qubes is first and foremost about security, it might take a while to fix something like this that may be considered lower priority. But then again, who knows, and it may even be quite quick and fast to fix, at which point, it might be fixed quickly.

Also this widget is still being developed and updated too, this bug may be caused by another bug, which may be be updated for another reason althother (a possibility). The widget still has some quirks, although it works somewhat nicely after being fully updated compared to its first version.

Currently you need to reverse the process before you can move it to another VM, and it seems to "bug" if you just shutdown the VM without reversing the proces first, at which point the only solution is unplug the device, and if not possible to unplug then restart all of Qubes. I think this might be fixed in the future, i.e. when shutting down a VM, perhaps it'll reverse the proces automatically.

Also I believe there is a way to automate the mounting to an AppVM/Template in Qubes 4, but I haven't had the need yet, so I did not explore this yet. It might not be developed yet either?

But in any case, you can easily write a script, place it in dom0, keybind it in dom0 in System-Tools --> keyboard ---> Shortcuts tab --> "Add". Then in the keybind, execute a script located in dom0. (This is important, dom0 first).
In the dom0 script, write the command the widget uses, to tie the drive. Then put a timer, so it doesn't execute the next step too fast. Thereafter write something like "qvm-run 'AppVM-name' bash path-to-your-scrupt-in-the-VM", which will mount the drive inside the VM you tied the drive to in the previous step.

If done properly, this should work pretty nicely. You can make a keybind/script for each drive or external devices you got, it's easy to copy once you got the first one down, and you can back it up so you can easily set it up again if you ever re-install Qubes.

[Yuraeitha]

On Monday, January 29, 2018 at 3:30:40 AM UTC+1, bill...@gmail.com wrote:

oh btw, only VM's that are currently running will appear in the widget, and only devices that are currently visible to Qubes will appear too. So any turned-off VM's, or any devices not working or blocked from Qubes, will not appear. Start the needed VM first, before you tie the device to the VM.

[bill...@gmail.com]

Thanks for you help --- again. Your widget discussion is what did it. In KDE, I didn't see the widget for adding disks to VMs, but it's there in the XCFe desktop. So instead of using the widget in KDE, I did everything by hand from the command line. Since the SATA disk partitions (sda1-sda8) were in /dev in dom0, I could manually mount them (even though I get I'm not supposed to -- I'm playing with it, after all). However, those devices simply were not visible in the other VMs.

But... when I logged in using the default desktop, there is was. And all of the SATA drives are available, and it works fine.

So, I gotta figure out a) how to find and get the widget showing in KDE, and/or what the qvm-whatever command is for doing this, because it's clearly there and it clearly works, and there's no bug.

Thanks for the pointer!

billo

[Yuraeitha]

Glad you got closer :) apologies for late reply too.
I'm not sure about KDE, unfortunately I've only been using XFCE my self.

Perhaps the --persistent flag can provide a solution here? I've only recently started using this my self, so I haven't discovered any quirks with the persistent flags yet, but so far it seems nice.

What I'm pondering about is whether it will work problem-free by having persistent on multiple AppVM's, and when closing one, and starting the other, automatically switches the device to this new AppVM. The limit being the inability to having both AppVM's open simultaneously.

If the hardware does require the PCI reset to swtich between VM's though, then there is a need for an extra flag. I believe I remember seeing a recent released guide for it somewhere in the official Qubes community, I haven't had a chance to go look for it again though. But it's something along the lines of --persistent, just with the something along the lines of allow-if-no-reset, or so abouts.