Description of problem: It's not possible to create snapshot with virsh when dynamic_ownership set to 0 . I tested this on CentOS 7 with SELinux set to permissive mode and on Arch Linux without SELinux. root@shiva /home/virtkick/hdd # virsh snapshot-create-as --domain 1_kwiat-test_cc789778-ea62-44a9-ac04-fc4a136131d4 snapshot-kwiat --diskspec vda,file=/home/virtkick/hdd/snapshot-1_kwiat-test_cc789778-ea62-44a9-ac04-fc4a136131d4.qcow2 --disk-only --atomic error: internal error: unable to execute QEMU command 'transaction': Could not create file: Permission denied Logs indicate that file is actually being created. /var/log/libvirt/qemu/1_kwiat-test_cc789778-ea62-44a9-ac04-fc4a136131d4.log: Formatting '/home/virtkick/hdd/snapshot-1_kwiat-test_cc789778-ea62-44a9-ac04-fc4a136131d4.qcow2', fmt=qcow2 size=26843545600 backing_file='/home/virtkick/hdd/1_kwiat-test_cc789778-ea62-44a9-ac04-fc4a136131d4.qcow2' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off However qemu process can't open it: open("/home/virtkick/hdd/snapshot-1_kwiat-test_cc789778-ea62-44a9-ac04-fc4a136131d4.qcow2", O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 EACCES (Permission denied) open("/home/virtkick/hdd/snapshot-1_kwiat-test_cc789778-ea62-44a9-ac04-fc4a136131d4.qcow2", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0644) = -1 EACCES (Permission denied) Version-Release number of selected component (if applicable): Tested on: - CentOS7 with libvirt-1.2.17-13.el7_2.5.x86_64, qemu-2.0.0-1.el7.6.x86_64 - Arch Linux with libvirt 2.0.0-1, qemu 2.6.0-1 How reproducible: Always Steps to Reproduce: 1. In /etc/libvirt/qemu.conf set dynamic_ownership=0. 2. Create new virtual machine 3. Try to create snapshot of that virtual machine using virsh snapshot-create-as command Known workaround is to touch the snapshot file before creating the snapshot, and chown it to user and group defined in qemu.conf. Actual results: Snapshot is not created due to EACCESS error. Expected results: Snapshot is created.
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.