"Cannot access storage file" using Veracrypt?

Hey guys,

So I’m finally getting back to my New Year’s Resolution of using all free software (i.e., TRULY free), and decided to switch from Virtualbox to KVM. Unfortunately, I’m having problems. I used Patrick’s instructions alongside those suggested by another member of this forum and ran into problems from the get-go due to having a separate root partition I had allotted just 10 GB :-. So you see what happened there.

Anyway, I had a light bulb go off and say, “hey! You know what you could do? Instead of editing the XML files (because you don’t know how to do that, Gregg), you can use a program to mount the directory with the qcow files from my home folder to /var/lib/blahblah!” And so I did. I knew Veracrypt was capable of doing this, so I installed that and boys, I mounted it like a majestic stallion, right where the XML file said to. You should’ve seen it.

But lo, 'twas not to be. Now, every time I hit “play” I get the following:

Error starting domain: Cannot access storage file '/var/lib/libvirt/images/Whonix-Gateway.qcow2' (as uid:118, gid:128): Permission denied

Under “Details,” I get this:

[code]Error starting domain: Cannot access storage file ‘/var/lib/libvirt/images/Whonix-Gateway.qcow2’ (as uid:118, gid:128): Permission denied

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 91, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 127, in tmpcb
callback(*args, **kwargs)
File “/usr/share/virt-manager/virtManager/domain.py”, line 1355, in startup
File “/usr/lib/python2.7/dist-packages/libvirt.py”, line 999, in create
if ret == -1: raise libvirtError (‘virDomainCreate() failed’, dom=self)
libvirtError: Cannot access storage file ‘/var/lib/libvirt/images/Whonix-Gateway.qcow2’ (as uid:118, gid:128): Permission denied

“Permission denied.” Pretty clearly a permission problem, right? So I started virt-manager as root (I know, I know–shame on me) and tried to start Whonix that way. Nope. Same exact thing. So is this an issue anyone else has had? My first guess was that this was due to my maverick, out-of-the-box thinking with respect to the Veracrypt thing: I know Veracrypt does, after all, have some permission problems of its own unless one uses NTFS formatting [url=http://sourceforge.net/p/veracrypt/discussion/technical/thread/e7e51852/]VeraCrypt / Forums / Technical Topics: Can´t write to mounted volume as regular user, but I did use NTFS formatting, and I’ve never had a problem with it before.

Any and all help would be greatly appreciated.

Oh, I’m also on Debian as host.

P.S. Just out of curiosity (this isn’t an important enough question to start a new thread over): has anyone had luck getting Whonix to run under a BSD system?

Symlinking the directories messed up the permissions in ways difficult to figure out. There are many reasons why images should be moved under the proper libvirt directory - anything else will give you problems because of the way libvirt isolation works. My suggestion for you is to resize your root partition to something sensible with gparted. Backup your data first!

That’s depressing. One of the reasons I stuck with VirtualBox for so long is that I could keep the VMs folder encrypted using Truecrypt. But that isn’t possible with KVM, I’m guessing?

It is possible. Try the solution in the last answer on here:


Hmmm…looks promising! I will try it out and report back with my results.

Ok. I probably should have added in my original post that I’m not actually all that sophisticated with things like this. I don’t actually seem to have a pool right now. I do virsh pool-list and I got nothin’. And when I do virsh pool-dumpxml default > pool.xml I get error: failed to get pool 'default' error: Storage pool not found: no storage pool with matching name 'default'.

Any ideas (other than my being an idiot)?

OK let’s try something else. First move the images to your home folder or preferred location then edit your machines’ XML by typing:

sudo su

EDITOR=nano virsh edit Whonix-Workstation

Go down to where it describes the file path of the qcow2 image and change it from /var/lib/libvirt/images to the new location in the home folder.

Save changes

Ctrl x
Ctrl m

Repeat steps for the gateway VM.

Try to boot the VMs.

Thanks for the reply! I’ll post results as soon as I’ve had a chance to give this a go.

I do not have space to resize my root partition without having to do an entire system install from scratch. I’m simply not willing to do that so I used the free space on another HDD to create a mountpoint at /usr/local/VMs for holding any/all virtual machine images. I then deleted the images subdirectory from /var/lib/libvirt and created a symlink to /usr/local/VMs. I ALMOST get the whole thing working - I can get both workstation and gateway to START to boot (I get past the bootloader) but after a certain point in the process, long before any X session is possible (before any internet connection is made too, I believe) I get a kernel panic for both.

I cp’d the two qcow2 files to /usr/local/VMs using the --sparse=always switch too. Is this setup simply impossible? Why would it allow the kernels to START to boot only to fail after a certain point rather than bar any bootup at all if the described setup is not valid/workable?

I’m thinking of changing the mount point from /usr/local/VMs to /var/lib/libvert/images directly but if I can avoid it I will. It’s the only way I can use such huge images (100gb each is massive - much bigger than the Virtualbox images. Isn’t there a way to make kvm more efficient spacewize than it is?

I looked at Qubes but it’s a nonstarter because it cannot be run from within linux, instead requiring a full re-install on my system first of Qubes, THEN linux into Qubes, THEN Whonix into Qubes. Then if you want to run Whonix for a quick session, you have to leave linux (or windows) and start Whonix, do your thing, leave Whonix, restart linux (or windows). Same as having each separately installed via a normal bootloader, just with more security but greater incompatibility issues vis a vis hardware.

I do not have this problem using Truecrypt 7.1a. So this is a Veracrypt problem.

That’s not correct. You can install Qubes to partition and dual boot. Once in Qubes you simply download Whonix. You then boot Qubes and run Whonix and that’s it. One my SSD the entire process takes less than a minute. One doesn’t install Linux into Qubes.

I don’t know why you insist on mounting your other drive thru /var/lib/libvirt you can use the image even if its in any other location. For problems with mounting I can’t really help with that and its out of scope of KVM - its a general Linux question that you will need assistance with elsewhere.

Your setup seems to work but the kernel panic could be a sign of image corruption. I suggest you untar the .xz archives straight in your new location instead of moving around the qcow2 images directly.

I had the same problem, this is how I make it work:

-Edit the final path (the decrypted path) “/run/mount/user/decrypt/Whonix-*.qcow2”

EDITOR=vi virsh edit Whonix-Workstation
EDITOR=vi virsh edit Whonix-Gateway

-Now decrypt the images and set permissions:

cryptsetup open --type tcrypt /run/mount/user/usb/encrypteddisk decrypted && chmod +x /run/mount/user

And thats all