F36: virt-install coreos fails: "Cannot access backing file", permission denied

On Fedora 36 (upgraded), following instructions from Getting Started with Fedora CoreOS, subsection “Booting on a local hypervisor (libvirt example)”.

No matter what, virt-install fails with:

ERROR Cannot access backing file '/home/user/.local/share/libvirt/images/fedora-coreos-35.20220424.3.0-qemu.x86_64.qcow2' of storage file '/var/lib/libvirt/images/fcos-test-01.qcow2' (as uid:107, gid:107): Permission denied

I have tried to add the current user to the kvm group (as the instructions in the link mention), to the qemu group, or both. No luck.
Those uid:107, gid:107 in the error message correspond to the qemu user and group. But even if that backing image has full permissions (ugo=rw) still does not help.

But for a long time I have been able to create with virt-install all kinds of other VMs, fedora or other distros (ubuntu, debian, etc.), for the last 5 or 6 fedora versions, including the current f36, so that does not seem to be the problem.

Any hints on what is going on ?

Which part of the manual do you refer to? this one:
https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/#_booting_on_a_local_hypervisor_libvirt_example >> Booting on a local hypervisor (libvirt example)

Did you take this in consideration?

Depending on your version of virt-install , you may not be able to use --os-variant=fedora-coreos-* and will get an error. In this case, you should pick an older Fedora variant ( --os-variant=fedora31 for example). You can find the variants that are supported by you current version of virt-install with osinfo-query os | grep '^\s*fedora' .

Yes, that one.

Yes, I tried that. I tried fedora35 and even fedora31, resulting in the same error. (BTW, that ‘31’ betrays the age of the documentation).

But, on my system (Fedora 36), fedora-coreos-stable is available:

$ osinfo-query os | grep -e 'coreos-stable'
 fedora-coreos-stable | Fedora CoreOS   | Stable   | http://fedoraproject.org/coreos/stable

The group you need to add your user too is libvirt. At least that is what I added my user to.

My current user is already member of libvirt, it has already been for years (below the actual user login was replaced with XXX) :

$ groups
XXX wheel libvirt

And like I said, currently I can run virt-install as a normal user and I can create VMs; for some reason it is the coreos flavor that causes the permission problem.

OK, some solution to this.

First of all, the error message – Cannot access backing file '/path/to/some/image/file' is hugely, terribly misleading. There might be some kind of “Permission denied” situation, alright, but is not clear the file has anything to do with it.
(I was also able to reproduce the error by attempting to virt-install using a regular self-contained image, without a backing file involved – case when the error message changes to Cannot access storage file '/image/path/here', and worse still, complains about permissions on ALL the directories’ paths up from that file).

Instead the culprit was the --connect="qemu:///system" argument mentioned in the CoreOS “Getting Started” instructions.

I can replace that with --connect="qemu:///session" – or leave it out completely – and the virt-install will work.

(and BTW, you might want to leave out --graphics=none; with it, the coreos will boot and use your terminal as output, including almost a couple of thousand boot messages; without it, virt-install will launch a graphical console, e.g. virt-viewer, for a more cleaner experience).

Now, that worked on my fedora 36 system. YMMV.

I made a pull request to change system to session.