I created a snapshot of a virtual machine. The VM runs fine. But when I
went to run the snapshot, I got the following error:

Error starting domain: internal error: process exited while connecting
to monitor: 2026-03-24T19:09:42.247626Z qemu-system-x86_64: -blockdev {"driver":"file","filename":"/crc/isos/debian/weekly/debian-testing-amd64-netinst.iso","node-name":"libvirt-3-storage","read-only":true}:
Could not open
'/crc/isos/debian/weekly/debian-testing-amd64-netinst.iso': Permission
denied

Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 71, in cb_wrapper callback(asyncjob, *args, **kwargs)
~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 107, in
tmpcb callback(*args, **kwargs)
~~~~~~~~^^^^^^^^^^^^^^^^^
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py",
line 57, in newfn ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/domain.py", line
1384, in startup self._backend.create()
~~~~~~~~~~~~~~~~~~~~^^
File "/usr/lib/python3/dist-packages/libvirt.py", line 1390, in create
raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: internal error: process exited while connecting
to monitor: 2026-03-24T19:09:42.247626Z qemu-system-x86_64: -blockdev {"driver":"file","filename":"/crc/isos/debian/weekly/debian-testing-amd64-netinst.iso","node-name":"libvirt-3-storage","read-only":true}:
Could not open
'/crc/isos/debian/weekly/debian-testing-amd64-netinst.iso': Permission
denied

I had previously gotten an error on the permissions of a storage file
(?) in the same directory, debian-testing-amd64-netinst.1774376356. It
had been 0600; I changed it to 0644 and that at least lead to the
current error.

Directory permissions are drwxrwxr-x or drwxr-xr-x all the way up and
all are owned by root:root.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 25 Mar 2026 10:44:17 +0100
john doe <johndoe65534@mail.com> wrote:

Virsh uses the "libvirt-qemu" ownership, you need to give read and
write access to where Libvirt should have access to.
I would assume that this is the same for Virt-manager.

I believe so. So:

-rw------- 1 libvirt-qemu libvirt-qemu 196624 Mar 24 17:02 debian-testing-amd64-netinst.1774393345
-rw-rw-r-- 1 libvirt-qemu libvirt-qemu 994050048 Mar 1 23:07 debian-testing-amd64-netinst.iso

Virt Manager runs as a user, and accesses virsh (running as
libvirt-qemu) via ssh, so everything should be as done as or
owned by libvirt-qemu. Except /etc/libvirt, which appears to be all
root:root. So I conjecture that something is running as root and issuing
orders to something else running as libvirt-qemu.

To test you could try to set the path to "0777"

Did not work.

or use
"/var/lib/libvirt". This is the path where images should be located
and the "disks".

That worked. I copied the files in rather than sym link to them. (A
hard link wouldn't work as they are on different file systems.) I had to
allow all to read the images directory, and then it worked.

Here's a curiosity: the backing file for the iso, debian-testing-amd64-netinst.iso, is an ISO 9660 file, as I would
expect. However, debian-testing-amd64-netinst.1774393345 is a QEMU QCOW
image (V3)! Its backing file is still /crc/isos/debian/weekly/debian-testing-amd64-netinst.iso. So I needn't
have copied in the .iso file. But, given that an ISO 9660 file is not
writable, why did virsh bother to create a working file for the
snapshot?

Yup, I deleted the .iso file from /var/lib/libvirt/images, and the VM
still works correctly.

Thanks.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- PyGate Linux v1.5.13
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)