On Wed, 25 Mar 2026 10:44:17 +0100 john doe <[email protected]> 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/
