The error you're encountering is a permission denied issue when QEMU (via libvirt) tries to access the disk image file (lineage-22.1-20250202-UNOFFICIAL-virtio_arm64only.img). Even though the file has 777 permissions, there are additional layers of security and access control in Linux that could be causing this issue. Here’s how to diagnose and resolve it:
Even with 777 permissions, the ownership of the file and its parent directory matters. QEMU/libvirt typically runs as the libvirt-qemu user and group.
Ensure the file is owned by the user running the VM (e.g., admin) or the libvirt-qemu group.
Run:
bashls -la /home/admin/lineage-22.1-20250202-UNOFFICIAL-virtio_arm64only.img
If the owner is admin, ensure the libvirt-qemu user/group has access.
Fix ownership (if needed):
bashsudo chown admin:libvirt-qemu /home/admin/lineage-22.1-20250202-UNOFFICIAL-virtio_arm64only.img
Or, if you want to allow the libvirt-qemu group to access it:
bashsudo chown :libvirt-qemu /home/admin/lineage-22.1-20250202-UNOFFICIAL-virtio_arm64only.img sudo chmod g+rw /home/admin/lineage-22.1-20250202-UNOFFICIAL-virtio_arm64only.img
The parent directory (/home/admin/) must also be accessible to the libvirt-qemu user/group.
bashls -la /home/admin/
libvirt-qemu group has execute (x) permission on /home/admin/:
bashsudo chmod g+x /home/admin/
/home/admin/ is owned by admin, add the libvirt-qemu group to the directory:
bashsudo chgrp libvirt-qemu /home/admin/ sudo chmod g+rx /home/admin/
If SELinux or AppArmor is enabled, it might block QEMU from accessing files in /home/.
Check SELinux status:
bashsestatus
If enabled, temporarily set it to permissive mode to test:
bashsudo setenforce 0
If the VM starts, SELinux is the issue. You can either:
bashsudo chcon -t svirt_image_t /home/admin/lineage-22.1-20250202-UNOFFICIAL-virtio_arm64only.img
Check AppArmor status:
bashsudo aa-status
If AppArmor is enforcing, check the logs for denials:
bashsudo dmesg | grep -i apparmor
You may need to adjust the AppArmor profile for QEMU.
Libvirt may restrict access to files outside specific directories (e.g., /var/lib/libvirt/images/).
Option 1: Move the image to the default libvirt directory:
bashsudo mv /home/admin/lineage-22.1-20250202-UNOFFICIAL-virtio_arm64only.img /var/lib/libvirt/images/ sudo chown libvirt-qemu:libvirt-qemu /var/lib/libvirt/images/lineage-22.1-20250202-UNOFFICIAL-virtio_arm64only.img
Update the VM configuration to point to the new path.
Option 2: Configure libvirt to allow access to /home/admin/:
Edit /etc/libvirt/qemu.conf and add:
iniuser = "admin" group = "libvirt-qemu"
Then restart libvirt:
bashsudo systemctl restart libvirtd
Ensure the libvirt-qemu user/group exists and is correctly configured:
bashsudo usermod -aG libvirt-qemu admin sudo systemctl restart libvirtd
If /home is on a separate filesystem (e.g., NFS, ext4 with noexec), it might block QEMU.
bashmount | grep /home
noexec or nodev, remount with:
(Permanent fix: updatebashsudo mount -o remount,exec /home
/etc/fstab.)qemu-system-aarch64 DirectlyRun QEMU manually to isolate the issue:
bashqemu-system-aarch64 -m 4G -cpu cortex-a72 -machine virt -blockdev file,filename=/home/admin/lineage-22.1-20250202-UNOFFICIAL-virtio_arm64only.img,node-name=test -device virtio-blk-device,drive=test
If this fails with the same error, the issue is file access. If it works, the problem is libvirt-specific.
Check libvirt logs for more details:
bashsudo journalctl -u libvirtd -f
Or:
bashsudo tail -f /var/log/libvirt/qemu/*.log
chown admin:libvirt-qemu + chmod g+rwchmod g+x /home/admin/setenforce 0 (test) or chcon -t svirt_image_tdmesg for denials/var/lib/libvirt/images/ or edit qemu.conf/home with execVibe can make mistakes. Check answers. Learn more