I'm running Deepin 15.3 x64 and i have an external HDD with EXT4 file system. whereat i store things like VM images. Oracle VM VirtualBox and VMware Workstation Player works just fine with this config, but KVM can't read files from it. I've tried to chown the files, the container directory and even chmod -R 0777 on the entire drive. But KVM still complains that it can't access the directory. However KVM can create images there, but KVM won't be able to access the image file as soon as it gets created. Here's a video of this (in case something's not clear). Note that I can't move the images to /var/lib/libvirt/images because i don't have enough space on my SSD for any of them.

7 Answers 7


This is because the Qemu requires execution permission along the image file's path. If the image is in the mounted disk, it requires +x permission in the /media/$username

For me, I fixed this issue by this command:

sudo chmod a+x /media/houcheng/

For rest of the detail, please see this.

  • 1
    no one seeing this ? it's works great on my RHEL 8 system just move any qcow2 & iso to /home folder. Thanks a lot :)
    – haidarvm
    Aug 9, 2019 at 18:38
  • 1
    worked well on ubuntu 20.04
    – Sokolokki
    Oct 31, 2020 at 10:03

Solution: Run Virtmanager as root, choose create a new VM -> select 'Import existing disk image' and browse it. After clicking continue it will ask whether you want it to fix permission issues or not for that path. After choosing 'Yes', it fixes the permission issue and will work when it's running as a normal user too.


The problem I was having was that my system (Fedora 27) automatically mounts new drives (external HDDs, USB, SD) to

/run/media/(username)/(device name)

For whatever reason this causes the permissions issue. What I did to fix the issue was unmount the drive from that location as root, and then mount it to /mnt. My USB thumb drive is /dev/sdc1 on my system so I did the following.

# su  -     (then enter root password)
# umount  /run/media/yourusername/devicename
# mount  /dev/sdc1 /mnt        (mount usb to /mnt)

After that I just made sure to have symbolic links from the original location of the qcow2 drives to the new location (still as root)

# cd  /var/lib/libvirt/images
# ln  -s  (new target)  (link name)   

so if your vm is named MyVM

# ln  -s  /mnt/Myvm.qcow2  MyVm.qcow2

Once I saw that my VMs were now working, I edited /etc/fstab to automatically mount the drive at /mnt. The folders and qcow2 drives were owned by my standard user account and group. I am sure there are better ways to do it, but this is what worked for me.


This a permission issue for qemu accessing the folder where VMs are stored.

I had an issue who looks like this, I resolved it by giving qemu access permissions to the folder (it was /home/mos in my case):

$ sudo setfacl -m u:qemu:x /home/mos

KVM uses libvirt, which requires images to be in a defined pool. You can do this with Virsh by copying the config of the default pool

virsh pool-dumpxml default > new_pool.xml
edit new_pool.xml ## use a different name & path
virsh pool-create new_pool.xml
virsh pool-refresh name

KVM should then be able to pick up images on your additional drive.

  • virsh pool-dumpxml default > new_pool.xml error: failed to get pool 'default' error: Storage pool not found: no storage pool with matching name 'default' Also virsh pool-list list shows no pools. Feb 10, 2017 at 20:27
  • Ok, default pool created and is active. It points to the directory where i store the images. Permissions: mode: 0777, owner: 119, group: 128. Still access denied. Feb 12, 2017 at 21:20
  • The above has worked for me in the past. I'm not sure what the issue could be other than ownership without seeing your setup. an alternate method you could try, is a symlink on the additional storage directory to /var/lib/libvirt/images directory: ln -sf /path/to/additional/storage /var/lib/libvirt/images Permissions/ownership will need to be identical for that to work, but I can't vouch for that working definitely, as I haven't tested it myself Feb 13, 2017 at 15:37
  • It's still not working. There's a video link in the question so you can see this part of my setup. For some reason it won't play from Google Drive so you have to download it but don't worry, it's only 17,1 MB. Feb 14, 2017 at 6:15

I found these answers when trying to run off an external hard drive and was having no luck. Then I remembered that selinux was a thing. To see if that was preventing access, I tried with

sudo setenforce permissive

And it worked! In my case the hdd was ntfs, which doesn't match the problem as described, but it is still important to remember that selinux must be happy for anything to go well. I hope this helps someone in a similar situation.

Of course running with permissive defeats the point of selinux, so the 'right way' to make an exception for selinux should be used as a final fix on a system that is using selinux. But those details are a bit out of scope for this question.

  • Turning off selinux is not an actual answer. It's like when you want to shutdown your machine by pulling off the power plug.
    – annahri
    Oct 6, 2020 at 23:17
  • 1
    Well, not quite "not an actual answer".... Running this command did allow me to access the images... so it is technically an answer. However, I agree you really should only do this to debug the issue and then put in an actual fix. I'll add a note to this affect.
    – poleguy
    Oct 18, 2020 at 4:47

For all who are using SELinux be aware of the right context of the images folder.

The context should be system_u:object_r:svirt_image_t

To change files or folder to this context just use:

chcon -t svirt_image_t -u system_u /newimages You can use -R for recursive and -L for following symbolic links, or both.

If you are just using links then be aware the link and the real file needs to be in this context.

NOTE: To check the context use e.g `ls -lZd /newimages

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.