Can no longer access my libvirt virtual machine, permission.. [SOLVED]

stefano · 2022-03-25 20:37:00

The latest update to libvirt broke my existing installation, it seems. When I try to launch a machine from libvirt-manager I get a permission error:

Error starting domain: Cannot access storage file '[FILENAME AND PATH REMOVED].qcow2' (as uid:977, gid:977): Permission denied

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, 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.10/site-packages/libvirt.py", line 1353, in create
    raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: Cannot access storage file '/'[FILENAME AND PATH REMOVED].qcow2' (as uid:977, gid:977): Permission denied

I thought the issue was related to the change in user and group in libvirt that has already been discussed in this post, so I tried the following:

- Changed the user and group owners of the virtual machine images from noboby:kvm to libvirt-qemu:libvirt-qemu ---> nothing changed
- Added myself to the libvirt-qemu group --> nothing changed

What else could I try to fix the problem? I didn't see anything relevant in qemu.conf, nor did I notice any failed hooks in pacman's log.

Edit: just checked that the libvirt-qemu user has been properly added to the system. So it seems it is the problem is a mismatch between the qemu process and the image file permissions?

Edit2: I also tried changing Qemu's both user and root in qemu.conf to libvirt-qemu, to no avail

Last edited by stefano (2022-03-29 15:36:11)

Lone_Wolf · 2022-03-26 12:02:03

as uid:977, gid:977

Those IDs differ between systems, please post the output of

id 977

stefano · 2022-03-26 14:25:59

Lone_Wolf wrote:

as uid:977, gid:977
Those IDs differ between systems, please post the output of
id 977

$ id 977
uid=977(libvirt-qemu) gid=977(libvirt-qemu) groups=977(libvirt-qemu),992(kvm)

Lone_Wolf · 2022-03-26 15:54:11

makes sense, now let's check the imagefile permissiions

ls --numeric-uid-gid /path/to/imagefile

stefano · 2022-03-26 16:51:22

Lone_Wolf wrote:

makes sense, now let's check the imagefile permissiions
ls --numeric-uid-gid /path/to/imagefile

Those seem all right as well:

-rwxrwxr-x 1 977 977 175969599488 Feb  4 15:33 [PATH WITHDRAWN]

I even tried running virt-manager under sudo, but I get the same error. I guess I am not understanding the permission chain properly:
virt-manager --> libvirt ?
Different users?

Last edited by stefano (2022-03-26 16:57:01)

v2vm · 2022-03-28 20:01:17

i have exactly the same problem.

During upgrading libvirt, i had this pacman log:

700340:[2022-03-04T13:15:04-0800] [ALPM-SCRIPTLET] Creating group 'libvirt-qemu' with GID 964.
700428:[2022-03-04T13:15:04-0800] [ALPM-SCRIPTLET] Creating user 'libvirt-qemu' (Libvirt QEMU user) with UID 964 and GID 964.

One can find it out with:

tail -10000 /var/log/pacman.log | grep "libvirt"

Checking the VM image file:

$ ls -la /home/***/.local/share/libvirt/images/
...
-rw------- 1 nobody kvm  26847870976 Mar 28 12:46 Arch.qcow2
...
$  ls --numeric-uid-gid /home/***/.local/share/libvirt/images/Arch.qcow2
-rw------- 1 65534 992 26847870976 Mar 28 12:46 /home/***/.local/share/libvirt/images/Arch.qcow2

So the .qcow2 image file has user:group = nobody:kvm (65534:992)

But according to the pacman log, but libvirt created a user 964:964 and tried to access it with 964:964 (in op's case, it's 977:977).

Maybe changing the file permission of the .qcow2 can solve the problem, but i didn't do anything before upgrade, and imagine someone having many image files, so perhaps this is not a user issue but a potential bug or packaging problem?

I temporarily downgrade libvirt to v8.0.0-2:

sudo pacman -U https://archive.archlinux.org/packages/l/libvirt/libvirt-1%3A8.0.0-2-x86_64.pkg.tar.zst

And for now it continued to work, and I added it to the ignore list waiting for a fix (if ever there's going to be one).

PutridPete · 2022-03-29 01:59:20

This happened to me too, and I believe the fix that worked for me was (after adding my user to the libvirt group) to open /etc/libvirt/qemu.conf then uncomment and replace:

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

with:

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

After these changes it started working for me again.

Edit: I forgot to mention that after adding the above changes, you need to restart libvirtd.

Last edited by PutridPete (2022-03-30 03:01:31)

saddam · 2022-05-04 11:23:11

The problem is that I have different users on my system and I can't specify many users in /etc/libvirt/qemu.conf. "group = libvirt" is already in my qemu.conf.

[alex@14:15 storage]$ pwd
/home/alex/_alex/vmachine/storage
[alex@14:15 storage]$ ls -l /home/alex/_alex/vmachine/
total 16
drwxr-xr-x 4 alex alex 4096 авг 27 2020 .
drwx--x---+ 21 alex alex 4096 апр 19 00:32 ..
drwxr-xr-x 2 alex alex 4096 мая 14 2020 spice
drwxr-xr-x 2 alex libvirt 4096 апр 19 23:20 storage
[alex@14:16 storage]$ groups
libvirt-qemu libvirt input alex
[alex@14:16 storage]$ ls -l
total 145388072
drwxr-xr-x 2 alex libvirt 4096 апр 19 23:20 .
drwxr-xr-x 4 alex alex 4096 авг 27 2020 ..
-rw-r--r-- 1 alex alex 233 окт 13 2020 ext_usb_disk.xml
-rw-rw---- 1 alex libvirt 17179869184 мая 5 2021 flash-16GB.img
-rw-r--r-- 1 alex alex 192 окт 13 2020 usb_disk.xml
-rw------- 1 root root 74819567616 апр 30 06:05 win10-dbg-vol01.qcow2
-rw------- 1 root root 32874299392 апр 21 00:02 win10-dev02-vol01.qcow2
-rw-rw---- 1 libvirt-qemu libvirt 67958538240 мая 3 00:31 win10-main-vol02.qcow2
-rw-rw---- 1 libvirt-qemu libvirt 132974051328 мая 3 00:31 win10-vol.qcow2
[alex@14:16 storage]$ ls -ln
total 145388072
drwxr-xr-x 2 1000 970 4096 апр 19 23:20 .
drwxr-xr-x 4 1000 1000 4096 авг 27 2020 ..
-rw-r--r-- 1 1000 1000 233 окт 13 2020 ext_usb_disk.xml
-rw-rw---- 1 1000 970 17179869184 мая 5 2021 flash-16GB.img
-rw-r--r-- 1 1000 1000 192 окт 13 2020 usb_disk.xml
-rw------- 1 0 0 74819567616 апр 30 06:05 win10-dbg-vol01.qcow2
-rw------- 1 0 0 32874299392 апр 21 00:02 win10-dev02-vol01.qcow2
-rw-rw---- 1 963 970 67958538240 мая 3 00:31 win10-main-vol02.qcow2
-rw-rw---- 1 963 970 132974051328 мая 3 00:31 win10-vol.qcow2
[alex@14:16 storage]$ sudo virsh start win10-main
error: Failed to start domain 'win10-main'
error: Cannot access storage file '/home/alex/_alex/vmachine/storage/win10-main-vol02.qcow2' (as uid:963, gid:970): Permission denied

But as I see, all permissions are ok. So I can't realize the root of the problem.
I was forced to downgrade libvirt ((

Last edited by saddam (2022-05-04 11:42:03)

lucecca · 2022-06-19 07:16:43

Finally I fixed the issue granting to user libvirt-qemu access to my $HOME directory, under wihich there's a directory (named vm) where qcow2 files are stored.
The full path to directory where qcow2 are stored is /home/luca/vm.

Before applying a new access list rule my home directory looks like this

[root@archlinux home]# getfacl luca
# file: luca
# owner: luca
# group: luca
user::rwx
user:nobody:--x
group::---
mask::--x
other::---

After applying the setfacl command

[root@archlinux home]# setfacl -m u:libvirt-qemu:rx luca

the grants appear in this way

[root@archlinux home]# getfacl luca
# file: luca
# owner: luca
# group: luca
user::rwx
user:libvirt-qemu:r-x
user:nobody:--x
group::---
mask::r-x
other::---

Not sure if it is or not the right way to proceed.
HTH.

saddam · 2022-06-20 19:25:33

lucecca wrote:

Finally I fixed the issue granting to user libvirt-qemu access to my $HOME directory, under wihich there's a directory (named vm) where qcow2 files are stored.

Thank you, lucecca. I don't get the reason for this behavior of libvirt, and I don't understand what did libvirt forget at my HOME, but your solution works. Moreover I set 'x' permission only (not 'rx'), and it works. So, as I got, libvirt needs 'x' permission to every single directory on its path to vm's image.

Arch Linux

#1 2022-03-25 20:37:00

Can no longer access my libvirt virtual machine, permission.. [SOLVED]

#2 2022-03-26 12:02:03

Re: Can no longer access my libvirt virtual machine, permission.. [SOLVED]

#3 2022-03-26 14:25:59

Re: Can no longer access my libvirt virtual machine, permission.. [SOLVED]

#4 2022-03-26 15:54:11

Re: Can no longer access my libvirt virtual machine, permission.. [SOLVED]

#5 2022-03-26 16:51:22

Re: Can no longer access my libvirt virtual machine, permission.. [SOLVED]

#6 2022-03-28 20:01:17

Re: Can no longer access my libvirt virtual machine, permission.. [SOLVED]

#7 2022-03-29 01:59:20

Re: Can no longer access my libvirt virtual machine, permission.. [SOLVED]

#8 2022-05-04 11:23:11

Re: Can no longer access my libvirt virtual machine, permission.. [SOLVED]

#9 2022-06-19 07:16:43

Re: Can no longer access my libvirt virtual machine, permission.. [SOLVED]

#10 2022-06-20 19:25:33

Re: Can no longer access my libvirt virtual machine, permission.. [SOLVED]

Board footer