The "Permission Denied" error when running
sudo virt-install with a qcow2 disk typically stems from SELinux security contexts or incorrect file ownership that prevents the libvirt-qemu user from accessing the image. Running commands as root bypasses these checks initially but fails during execution because the underlying QEMU process lacks the necessary permissions. Resolving this requires aligning the disk file's ownership and security labels with the libvirt daemon rather than changing them to root, which would break virtual machine access entirely.
Understanding the Root Cause
When you invoke
sudo virt-install, the command itself runs as the root user, but the actual virtualization work is delegated to the libvirt daemon. The libvirt service operates under a dedicated system user, typically named
libvirt-qemu. This user is responsible for spawning QEMU processes and managing their resources. If the qcow2 disk image resides in a directory where
libvirt-qemu does not have read and write permissions, the QEMU process will fail immediately with a permission denied error.
This issue is distinct from general sudo misconfigurations. It is specifically about the separation of privileges between the installation tool and the runtime environment. Many users attempt to fix this by changing the file owner to root using
chown root. This approach is dangerous and incorrect. As discussed in our analysis of how
chmod usage can inadvertently break sudo access, improper permission changes can destabilize system security. More importantly, setting the VM disk to be owned by root often breaks the ability of the
libvirt-qemu user to write to the disk during operation, causing the VM to crash or become unbootable.
The Role of SELinux
On systems like RHEL, CentOS, Fedora, or Rocky Linux, SELinux plays a critical role in this failure. Even if the file permissions (rwx) are correct for
libvirt-qemu, SELinux may block access based on security contexts. By default, SELinux expects VM images to be stored in specific directories like
/var/lib/libvirt/images/ or
/home//virt-images/. If you store your qcow2 file in a custom location, such as
/home/user/downloads/, SELinux will likely deny access unless the context is explicitly set.
You can verify if SELinux is the culprit by checking the audit log. Run the following command to see if there are recent denials:
sudo ausearch -m avc -ts recent
If you see entries related to
qemu or
virt-image being denied access, SELinux is the primary blocker.
Correcting File Ownership and Permissions
The first step in resolving this issue is ensuring that the file system permissions allow the libvirt user to interact with the disk. You should change the ownership of the qcow2 file to the
libvirt-qemu user and the
kvm group. Do not use root as the owner.
Use the
chown command to update the ownership:
sudo chown libvirt-qemu:kvm /path/to/your/disk.qcow2
Next, ensure the file has appropriate read and write permissions. The standard secure permission level is 640, which allows the owner to read/write and the group to read.
sudo chmod 640 /path/to/your/disk.qcow2
This configuration ensures that
libvirt-qemu can manage the disk while preventing other regular users from modifying it. For more insights on managing permissions safely, refer to our guide on
how to block sudo for specific applications, which highlights the importance of granular access control.
Fixing SELinux Contexts
If you are on an SELinux-enabled system, correcting ownership is not enough. You must also assign the correct security context to the file. The correct context for libvirt images is usually
virt_image_t.
You can check the current context using
ls -Z:
ls -Z /path/to/your/disk.qcow2
If the type is not
virt_image_t, you can restore the default context using the
restorecon command. This command reads the policy and applies the correct label based on the file's path.
sudo restorecon -v /path/to/your/disk.qcow2
Alternatively, if you want to manually set the context, you can use
chcon:
sudo chcon -t virt_image_t /path/to/your/disk.qcow2
Note that
chcon changes are not persistent across reboots if the filesystem is relabeled.
restorecon is preferred because it respects the permanent policy definitions.
Using the Correct Storage Pool Path
To avoid these issues entirely, consider storing your VM images within the standard libvirt storage pool directories. Libvirt automatically manages permissions and contexts for files in these locations.
You can list existing pools with:
virsh pool-list --all
And inspect the volume directory of a pool:
virsh pool-dumpxml default
Creating new volumes inside these managed pools ensures that libvirt handles the backend permissions correctly. If you must use external paths, always apply the ownership and SELinux fixes described above before launching the VM.
Verifying the Fix
After applying the ownership and context changes, test the installation again without relying on sudo for the entire session if possible, or simply retry the
sudo virt-install command. If the error persists, check the libvirt logs for detailed error messages:
sudo journalctl -u libvirtd -n 50
Look for lines containing "Permission denied" or "EACCES". These logs will pinpoint exactly which resource is failing access, allowing you to adjust permissions further if needed.
Frequently Asked Questions
Why did changing the owner to root break my VM?
Setting the disk owner to root prevents the
libvirt-qemu user from writing to the disk during runtime. Since QEMU needs to modify the qcow2 file to record snapshots and changes, it will fail if it does not own the file or have group write access. This results in immediate crashes or inability to start the guest OS.
Can I disable SELinux to fix this error?
Disabling SELinux is not recommended as it compromises system security. Instead, you should configure the correct SELinux contexts using
restorecon or
chcon. Properly labeling files allows the security model to function while granting necessary access to virtualization tools.
What is the difference between chown and chcon?
chown changes the Unix file ownership (user and group), controlling who can read or write the file at the operating system level.
chcon changes the SELinux security context, controlling whether security policies allow processes to access the file. Both are often required for VM disks to function correctly.
How do I find the libvirt-qemu user name?
The user is typically named
libvirt-qemu on most distributions. You can verify its existence by checking the /etc/passwd file or using
id libvirt-qemu. If the user does not exist, it means libvirt was not installed correctly or uses a different naming convention for your specific distribution.
Does this issue affect raw disk images too?
Yes, the same permission and SELinux context rules apply to raw disk images. Whether you use qcow2, raw, or qed formats, the underlying QEMU process requires appropriate file system permissions and security labels to access the storage backend.