Bug 868415 - Can't put a VM image on removable media
Can't put a VM image on removable media
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
17
x86_64 Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-19 14:46 EDT by John Morris
Modified: 2012-10-19 21:18 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-19 21:18:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Morris 2012-10-19 14:46:13 EDT
Description of problem:

I wanted to move a VM image to the extra drive in my laptop's dock.  It is mounted via an icon and the (whatever today's flavor is) magic desktop stuff when I click it to /run/media/jmorris/Mystash.  The vm is in virtual_machines/ in that filesystem, which is ext4 btw.  Now when I try to launch it I get this:

qemu-kvm: -drive file=/run/media/jmorris/Mystash/virtual_machines/Model6.img,if=none,id=drive-virtio-disk0,format=qcow2: could not open disk image /run/media/jmorris/Mystash/virtual_machines/Model6.img: Permission denied

Stat says this:

stat /run/media/jmorris/Mystash/virtual_machines/Model6.img 
  File: `/run/media/jmorris/Mystash/virtual_machines/Model6.img'
  Size: 25830948864	Blocks: 50450840   IO Block: 4096   regular file
Device: 821h/2081d	Inode: 15204354    Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-10-19 13:28:54.210695036 -0500
Modify: 2012-10-19 10:12:12.867881297 -0500
Change: 2012-10-19 13:28:54.611702978 -0500
 Birth: -

SELinux is already turned off.  So what else is left?  If I umount it and manually do (as root) 'mount /dev/sdb1 /mnt' it runs.


Version-Release number of selected component (if applicable):

libvirt-0.9.11.6-1.fc17.x86_64

How reproducible:

Always.
Comment 1 Dave Allan 2012-10-19 15:09:39 EDT
You should mention this situation on the libvirt-users mailing list, as not everybody on the list follows bugzilla.  What happens if you mount it where the automount magic mounts it?  I'm guessing this is a permissions problem higher up the directory tree.
Comment 2 John Morris 2012-10-19 16:54:41 EDT
First off, you must mount it and unmount it once via the desktop because until you do that /run/media/jmorris doesn't exist.  Then I had to make MyStash again, which was kinda expected.  Didn't work.  Running stat on each directory going up the chain doesn't show anything odd.  Odds are it is some of this new non-UNIX cruft that isn't discoverable via the UNIX command line tools.  /run is mounted nosuid,nodev but I don't think you need either of those abilities for a VM image.

So the questions becomes a) which package does this bug need to be reassigned to and b) how fast the desktop gods will decree it not to be a bug anyway.  Nah, best to deal with it in qemu/libvirt and just make it able to run an image sans whatever capability they have removed (for our benefit) since argument with desktop people is kinda pointless these days.
Comment 3 Dave Allan 2012-10-19 17:19:18 EDT
Sorry if I'm being pedantic, but in case I missed something, the uid/gid of the qemu process seem to have rights to the tree all the way down?
Comment 4 John Morris 2012-10-19 21:18:30 EDT
Ok, I wasn't paying close enough attention.  /run/media/${USER} is set to disallow any access by other than ${USER}.  From the complaints I see in various mail archives it seems a lot of folks aren't exactly happy with that but it is pointless for a lowly user to argue desktop policy.  And apparently at some point recently qemu stopped running this part as root so can't see into the mount point anymore.  Although it does see vm images in my home that only my account and root should be able to read.  Eh?

Anyway, for anyone else hitting this there is a way around it.  Put a small shell script into the startup of your desktop session to make the directory and ensure it has world execute.

#!/bin/bash
sudo mkdir /run/media/${USER}
sudo chmod +x /run/media/${USER}

Note You need to log in before you can comment on or make changes to this bug.