veewee: qemu-kvm: could not open disk image ' ': Permission denied

SOLVED: found a way. Changing /etc/libvirt/qemu.conf to make things work. Uncomment user/group to work as root. Then restart libvirtd

# The user for QEMU processes run by the system instance. It can be
# specified as a user name or as a user id. The qemu driver will try to
# parse this value first as a name and then, if the name doesn't exist,
# as a user id.
#
# Since a sequence of digits is a valid user name, a leading plus sign
# can be used to ensure that a user id will not be interpreted as a user
# name.
#
# Some examples of valid values are:
#
#       user = "qemu"   # A user named "qemu"
#       user = "+0"     # Super user (uid=0)
#       user = "100"    # A user named "100" or a user with uid=100
#
user = "root"

# The group for QEMU processes run by the system instance. It can be
# specified in a similar way to user.
group = "root"

# Whether libvirt should dynamically change file ownership
# to match the configured user/group above. Defaults to 1.
# Set to 0 to disable file ownership changes.
#dynamic_ownership = 1

[root@dev1 ~]# service libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]

Using Terraform with the libvirt Provider, I got the same error. But the problem was Apparmour: https://github.com/dmacvicar/terraform-provider-libvirt/issues/97

For testing purpose, I simply set security_driver = "none" in /etc/libvirt/qemu.conf and restart the service service libvirtd restart.

Encountered same issue, after digging ACL issue, I have to grant supplementary right on my HOME

murlock@asus:~/kubernet $ sudo getfacl -e /home/murlock
getfacl: Removing leading '/' from absolute path names
# file: home/murlock
# owner: murlock
# group: murlock
user::rwx
user:libvirt-qemu:--x		#effective:---
group::---			#effective:---
mask::---
other::---

murlock@asus:~/kubernet $ sudo setfacl -m u:libvirt-qemu:rx /home/murlock

murlock@asus:~/kubernet $ sudo getfacl -e /home/murlock
getfacl: Removing leading '/' from absolute path names
# file: home/murlock
# owner: murlock
# group: murlock
user::rwx
user:libvirt-qemu:r-x		#effective:r-x
group::---			#effective:---
mask::r-x
other::---

If you copy your ISO image to /var/lib/libvirt/images (and access it from there) all the problems will go away.

I don’t think it is wise to make such edits letting qemu running as root. You should put the ISO file in a directory that is readable by qemu user, for example /tmp

Simply add your username to libvirt group and then instead of root replace with your username and group in /etc/libvirt/qemu.conf file.

user = "howdy"
group = "rowdy"

No need to mess with acl or run it as root. After making necessary changes simply execute systemctl restart libvirtd and ta-da

The qemu user needs search permissions all the way up the path, that means chmod a+x. For me the issue was I had ACL’s set which blocked qemu… to remove them run “setfacl -b offending-dir/”

You can tell if that’s your problem when unix permissions are correct but you can’t ls every upstream dir with sudo su -s /bin/bash qemu and ls with an account that does have access yields a result with a permission line that contains a dot such as drwxrwxr-x. meaning extended ACL permissions.

Tnx @codingenesis . Exactly what i needed! 😃

sudo groupadd --system libvirt
sudo usermod -a -G libvirt $(whoami)
newgrp libvirt
id $(whoami)
sudo vim /etc/libvirt/libvirtd.conf
unix_sock_group = "libvirt"
unix_sock_rw_perms = "0770"
sudo vim /etc/libvirt/qemu.conf
user = "howdy"
group = "rowdy"
sudo systemctl restart libvirtd.service

I have my images in a drive mounted in /media/user/Data sudo setfacl -m u:libvirt-qemu:rx /media/user fixed it.

Murlock’s suggestions fixed the same issue for me as well. Only difference was the user was named “qemu” instead of “libvirt-qemo”

If none above worked for you (not even having qemu run as root:root; crazy uh?), here’s another workaround that did the trick for me: instead of using the libvirt volume provider for your disks, in your machine XMLs, use plain files instead.

E.g., instead of this: <disk type='volume' device='disk'> ... </disk> Use this: <disk type='file' device='disk'> .... </disk>

Edit: turns out it was AppArmour, denying accessing the volume through the libvirt pool interface as stated here https://github.com/jedi4ever/veewee/issues/996#issuecomment-497976612

After trying almost all of the above, a very simple “chmod all” fix appeared when someone over at StackExchange explain what kind of perms Qemu needs.

sudo chmod a+x [path_to_volume_pool]

Explanation given:

Qemu requires execution permission along the image file’s path

Hi, Check my comments above for the rough instructions. 3 things can go wrong, User and group filesystem permissions (libvirt and KVM runs as it’s own user) Apparmor or SELunix permissions. Some ACL. Since you are placing the disk inside your home, it’s probably security. Try placing it in the same directory as the first disk or /var/lib/libvirt/images alternatively. If that gives a permission error check you pool config in libvirt and place the disk in the correct location.

Thanks friend, I managed to solve it by changing the user and group to root in the /etc/libvirt/qemu.conf file and also changing the permissions of the folder where the disks are with chmod a+x

https://github.com/jedi4ever/veewee/issues/996#issuecomment-536519623

mrcloudhacker had the best an easiest solution.

Using Terraform with the libvirt Provider, I got the same error. But the problem was Apparmour: dmacvicar/terraform-provider-libvirt#97

For testing purpose, I simply set security_driver = "none" in /etc/libvirt/qemu.conf and restart the service service libvirtd restart.

If anybody is still looking to fix this and it’s neither acl, perms or apparmor, Ubuntu 22.04 now has selinux. So disabling security_driver here is mandatory

@vap0rtranz In my case file was /media/username/4TBBackup/testMech.raw setfacl or security_driver = "none" did not resolve it but

sudo chmod a+x /media
sudo chmod a+x /media/username
sudo chmod a+x /media/username/4TBBackup
sudo chmod a+x /media/username/4TBBackup/testMech.raw 

Indeed solved it libvirtd needs execution permissions along the path

But … Why the hell it needs it ?

Using Terraform with the libvirt Provider, I got the same error. But the problem was Apparmour: dmacvicar/terraform-provider-libvirt#97

For testing purpose, I simply set security_driver = "none" in /etc/libvirt/qemu.conf and restart the service service libvirtd restart.

This is what worked for me. Thanks.

then,reboot