5

Environment

  • SMB network share temp is mounted as follows, logged-in user dave:
    sudo mount -t cifs -o username=dave,vers=3.11,uid=dave,gid=dave //nas/temp /media/nas/temp
    
  • Effective temp mount folder permissions:
    $ ls -al /media/nas/
    drwxr-xr-x 2 dave dave    0 Nov 30 10:14 temp/
    
  • libvirtd runs as root:
    $ ps aux | grep libvirt 
    root         902  0.0  0.2 1559756 42420 ?       Ssl  Nov29   0:06 /usr/sbin/libvirtd
    
  • virt-manager (my used libvirt frontend) runs with user dave permission:
  • vanilla, untouched QEMU config
  • User dave already has been added to groups libvirt and kvm as described here (OS is Ubuntu 20.04):
    sudo adduser `id -un` libvirt
    sudo adduser `id -un` kvm
    
  • libvirt URI is qemu:///system

Problem

I can write/read as dave to temp directly from the shell or Files application. The share owner is set to uid=dave,gid=dave, which is the user belonging to kvm and libvirt. Running VMs with local .qcow2 disk image path is no problem. In virt-manager, I am able to define /media/nas/temp as storage pool (the directory containing the images).

But as soon as I want to place or create this disk image file in /media/nas/temp, there is a "Permission denied" error triggered. As far as I know, virtual machines with qemu:///system are instantiated and run as root. This should not affect the configured network share owner in any way. I event tried sudo su and checked, that I am able to write to /media/nas/temp as root.

Another way to trigger the error directly (copied from virt-manager output) is:

/usr/bin/qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts /media/nas/temp/ubuntu20.04 20971520K

Question

I really would like to understand the permission issue and how to fix it. What is the problem here?

Error message in detail

Trying to create a new .qcow2 disk images triggers:

Error creating vol: Couldn't create storage volume 'ubuntu20.04': 'internal error: Child process (/usr/bin/qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts /media/nas/temp/ubuntu20.04 20971520K) unexpected exit status 1: qemu-img: /media/nas/temp/ubuntu20.04: Could not write qcow2 header: Permission denied '

Traceback (most recent call last): File "/usr/share/virt-manager/virtinst/storage.py", line 682, in install vol = self.pool.createXML(xml, createflags) File "/usr/lib/python3/dist-packages/libvirt.py", line 3535, in createXML if ret is None:raise libvirtError('virStorageVolCreateXML() failed', pool=self) libvirt.libvirtError: internal error: Child process (/usr/bin/qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts /media/nas/temp/ubuntu20.04 20971520K) unexpected exit status 1: qemu-img: /media/nas/temp/ubuntu20.04: Could not write qcow2 header: Permission denied

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/createvol.py", line 339, in _async_vol_create vol.install(meter=meter) File "/usr/share/virt-manager/virtinst/storage.py", line 691, in install raise RuntimeError("Couldn't create storage volume " RuntimeError: Couldn't create storage volume 'ubuntu20.04': 'internal error: Child process (/usr/bin/qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts /media/nas/temp/ubuntu20.04 20971520K) unexpected exit status 1: qemu-img: /media/nas/temp/ubuntu20.04: Could not write qcow2 header: Permission denied '

Update: What I further tried

  • searched for other error types via journalctl -xf (nothing else than above message)
  • searched for denied operations via cat /var/log/syslog | grep DENIED | grep libvirt (nothing)
  • Experimentally disabled AppArmor via systemctl stop apparmor - no effect
  • created an image successfully in other local folders than /var/lib/libvirt/images/

Update 2: Using nobrl mount option

If I use the nobrl mount option (thanks to rudib) with owner still uid=dave,gid=dave as follows:

sudo mount -t cifs -o username=dave,vers=3.11,uid=dave,gid=dave,nobrl //nas/temp /media/nas/temp

, the storage volume can be successfully created (step 4/5 in virt-manager wizard). Though in step 5/5, I now get another "Permission denied" error:

Unable to complete install: 'internal error: qemu unexpectedly closed the monitor: 2020-12-01T06:03:01.710704Z qemu-system-x86_64: -blockdev {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null}: Could not reopen file: Permission denied'

Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/createvm.py", line 2089, in _do_async_install guest.installer_instance.start_install(guest, meter=meter) File "/usr/share/virt-manager/virtinst/install/installer.py", line 542, in start_install domain = self._create_guest( File "/usr/share/virt-manager/virtinst/install/installer.py", line 491, in _create_guest domain = self.conn.createXML(install_xml or final_xml, 0) File "/usr/lib/python3/dist-packages/libvirt.py", line 4034, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2020-12-01T06:03:01.710704Z qemu-system-x86_64: -blockdev {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null}: Could not reopen file: Permission denied

Not specifying uid and gid leads to following permissions:

$ ll /media/nas/
drwxr-xr-x 2 root  root     0 Dez  1 07:01 temp/

, the error being the same as before.

9
  • I think this is a selinux issue. I'm not sure if you can use selinux with smb, but I think I've had the same error before.
    – rudib
    Commented Nov 30, 2020 at 12:46
  • I think you can set context="virt_image_t" in the mount options. That might work (but will apply for the whole mount; I guess you'd need a dedicated mount for vm images...).
    – rudib
    Commented Nov 30, 2020 at 12:53
  • 1
    Also qemu:///system does not run as your user, you might have to change the share user to root (as in /var/lib/libvirt/images, which is the default directory for the system images)
    – rudib
    Commented Nov 30, 2020 at 13:10
  • 1
    Have you tried uid=qemu,gid=root and uid=root,gid=root as mount options yet? Other ideas: do you have enough free space on the server? you could try enabling cifs debugging maybe there's a hint to be found there. When I find the time, I'll see if I can get it working on my selinux setup.
    – rudib
    Commented Nov 30, 2020 at 19:31
  • 1
    I think I've unraveled the mystery: try using the nobrl mount option: mount -t cifs -o username=dave,vers=3.11,nobrl //nas/temp /media/nas/temp
    – rudib
    Commented Nov 30, 2020 at 20:01

1 Answer 1

4

Note: An active volume that is mounted remotely can cause some problems and add latency

It seems that qemu-img can't deal with the byte range locks that are a default mount option for cifs. The flag nobrl should fix that:

mount -t cifs -o username=dave,vers=3.11,nobrl,uid=libvirt-qemu //nas/temp /media/nas/temp

During image creation with qemu:///system uid=libvirt-qemu doesn't seem to be required as virt-manager seems to run qemu-img create as root. However, as qemu:///system machines are started under the qemu user (libvirt-qemu [Ubuntu, Debian] or qemu [Fedora]), you will get another permission denied error when the share is just mounted as root.

nobrl
Do not send byte range lock requests to the server. This is
necessary for certain applications that break with cifs style
mandatory byte range locks (and most cifs servers do not yet support
requesting advisory byte range locks).

When you are using selinux, you might need to set the sebool virt_use_samba.

8
  • 1
    Glad it worked! Not to worry, I'm not doing it for the points - I don't mind them either though ;).
    – rudib
    Commented Nov 30, 2020 at 22:25
  • 2
    Somebody else had written as comment, that libvirtd runs as root, but actually starts VMs as libvirt-qemu user. For the local system it can change the user dynamically, but for the mount point, it doesn't seem to work, as this is determined/fixed by uid, gid. I am not sure, why the comment has been deleted, as this was very helpful information (hope I have remembered it correctly). This at least explains, why libvirt-qemu is needed (no custom user created by me, but by libvirt installation).
    – A_blop
    Commented Nov 30, 2020 at 22:39
  • 1
    Yes, setting uid to libvirt-qemu has been absolutely necessary for me (not sure about/didn't play with gid though). If I leave out uid, there is a second "permission denied" error - see question update 2 for the message. Do you want to add this info as well concerning libvirtd being under root permission, running VMs as libvirt-qemu and that this user name may vary dependent on distribution (for Ubuntu, it is libvirt-qemu)? I find all this hints to be super useful, yet you can find hardly anything about it on the net (or google failed me :).
    – A_blop
    Commented Dec 1, 2020 at 6:43
  • 1
    It might have worked for me because I was running qemu-img create as root. Ah yes, I get an error too - permission denied. But not on the image creation (probably because virt-manager can run commands as root), but when starting the vm (which is under the qemu user).
    – rudib
    Commented Dec 1, 2020 at 10:47
  • 1
    Then everything starts to make sense again! I guess, the error I get is also in the course of the VM starting (even if the installation wizard is still shown), as virt-manager starts the VM immediately if everything is configured fine.
    – A_blop
    Commented Dec 1, 2020 at 11:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .