Bug 1025355 - permission denied when starting a domain with a disk image in home directory
permission denied when starting a domain with a disk image in home directory
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
:
: 1016657 1021615 1027038 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-31 10:26 EDT by Lukas Brabec
Modified: 2013-11-16 02:14 EST (History)
15 users (show)

See Also:
Fixed In Version: virt-manager-0.10.0-5.git1ffcc0cc.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-16 02:14:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lukas Brabec 2013-10-31 10:26:07 EDT
Description of problem:
In Fedora 20 Beta TC6, I'm unable to create virtual machine in virt-manager. I only get error:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1959, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 388, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 453, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2897, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error: process exited while connecting to monitor: Warning: option deprecated, use lost_tick_policy property of kvm-pit instead.
qemu-system-x86_64: -drive file=/home/brrab/Fedora-20-Beta-TC6-x86_64-netinst.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw: could not open disk image /home/brrab/Fedora-20-Beta-TC6-x86_64-netinst.iso: Permission denied


Version-Release number of selected component (if applicable):
virt-manager-0.10.0-4.git79196cdf.fc20
libvirt-client-1.1.3-2.fc20.x86_64
libvirt-gobject-0.1.7-2.fc20.x86_64
libvirt-daemon-driver-secret-1.1.3-2.fc20.x86_64
libvirt-daemon-driver-nwfilter-1.1.3-2.fc20.x86_64
libvirt-daemon-config-network-1.1.3-2.fc20.x86_64
libvirt-daemon-1.1.3-2.fc20.x86_64
libvirt-glib-0.1.7-2.fc20.x86_64
libvirt-daemon-driver-storage-1.1.3-2.fc20.x86_64
libvirt-python-1.1.3-2.fc20.x86_64
libvirt-daemon-driver-qemu-1.1.3-2.fc20.x86_64
libvirt-gconfig-0.1.7-2.fc20.x86_64
libvirt-daemon-driver-nodedev-1.1.3-2.fc20.x86_64
libvirt-daemon-driver-interface-1.1.3-2.fc20.x86_64
libvirt-daemon-kvm-1.1.3-2.fc20.x86_64
libvirt-daemon-driver-network-1.1.3-2.fc20.x86_64


Steps to Reproduce:
1. click on create new virtual machine
2. select local install media
3. use iso image, browse and select local iso
4. set system type and version
5. adjust ram, cpu, disk
6. click on finish

Actual results:
Error/traceback

Expected results:
New virtual machine
Comment 1 Ján Tomko 2013-10-31 10:48:51 EDT
The actual error is:
qemu-system-x86_64: -drive file=/home/brrab/Fedora-20-Beta-TC6-x86_64-netinst.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw: could not open disk image /home/brrab/Fedora-20-Beta-TC6-x86_64-netinst.iso: Permission denied

Does the qemu user (qemu unless you changed it) have read permission to that file / execute permission to your home directory?
Comment 2 Lukas Brabec 2013-11-01 04:01:26 EDT
I tried to add qemu user to group brrab (my user's group) and tried to add read and execute (o+rx) permissions to my home folder. Both with no success.
Comment 3 Laine Stump 2013-11-01 06:04:02 EDT
virt-manager attempts to automatically correct any permission problems for the ISO used during an install though. Did you not get a dialog box asking:

  "The emulator may not have search permissions for the path
   '/home/brrab/Fedora-20-TC6-x86_64-netinst.iso'.
   Do you want to correct this now?"

??

If you answer yes to that, it is supposed to take care of any permission problems for you.

HOWEVER, I just did a similar experiment on my F20 system and encountered the same error message. When I did chmod 755 to my home directory, the guest was able to boot.

Oddly, if I added the qemu user to my user's group, then not only did boot fail when my home directory was 710, it *still* failed if my home directory was 755.

So, the immediate solution to your problem is to chmod 755 your home directory, *and* remove the qemu user from your user's group.

Beyond that, since virt-manager has some sort of code that tries to resolve this problem, I think this bz should be moved to virt-manager to see why that code is failing.
Comment 4 Laine Stump 2013-11-06 04:08:21 EST
*** Bug 1027038 has been marked as a duplicate of this bug. ***
Comment 5 Lukas Brabec 2013-11-06 04:20:24 EST
After trying fix the problem by reinstalling everything that has something to do with libvirt or virt-manager and failing, I finally tried chmod 755 to my home directory and that works.

However, I really don't like the idea of having read permissions on my home dir for everyone. And there is another bug marked as duplicate of this one, so it seems that this is not only my problem.
Comment 6 Cole Robinson 2013-11-06 08:17:09 EST
(In reply to Lukas Brabec from comment #5)
> After trying fix the problem by reinstalling everything that has something
> to do with libvirt or virt-manager and failing, I finally tried chmod 755 to
> my home directory and that works.
> 
> However, I really don't like the idea of having read permissions on my home
> dir for everyone. And there is another bug marked as duplicate of this one,
> so it seems that this is not only my problem.

Indeed that shouldn't be required. What virt-manager typically offers to do is use ACLs to allow the 'qemu' user search permissions on your home dir, which is all it should need and is fairly safe and restrictive. That's not working now for some reason, I'll investigate today.
Comment 7 Cole Robinson 2013-11-06 13:30:07 EST
*** Bug 1021615 has been marked as a duplicate of this bug. ***
Comment 8 Cole Robinson 2013-11-10 11:06:37 EST
Okay, the root issue here is the same as 1016825, basically that our app configuration is busted in the current F20 version, so virt-manager doesn't know that we should be setting ACLs for the 'qemu' user. So this is fixed upstream.
Comment 9 Cole Robinson 2013-11-10 11:47:08 EST
*** Bug 1016657 has been marked as a duplicate of this bug. ***
Comment 10 Fedora Update System 2013-11-10 12:10:50 EST
virt-manager-0.10.0-5.git1ffcc0cc.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/virt-manager-0.10.0-5.git1ffcc0cc.fc20
Comment 11 Fedora Update System 2013-11-11 19:32:17 EST
Package virt-manager-0.10.0-5.git1ffcc0cc.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing virt-manager-0.10.0-5.git1ffcc0cc.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-21095/virt-manager-0.10.0-5.git1ffcc0cc.fc20
then log in and leave karma (feedback).
Comment 12 Fedora Update System 2013-11-16 02:14:49 EST
virt-manager-0.10.0-5.git1ffcc0cc.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

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