Bug 539369
| Summary: | virt-manager fails to set security for path to iso image | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jonathan Underwood <jonathan.underwood> |
| Component: | virt-manager | Assignee: | Cole Robinson <crobinso> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 12 | CC: | berrange, crobinso, hbrock, jforbes, markmc, virt-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-11-20 19:27:40 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Thanks for the report What does: $> tune2fs -l $my_home_logical_volume | grep options show? Is it missing the 'acl' option? Does 'tune2fs -o acl,user_xattr $my_home_logical_volume' fix it? See bug #530210 (In reply to comment #1) > Thanks for the report > > What does: > > $> tune2fs -l $my_home_logical_volume | grep options > > show? Is it missing the 'acl' option? > Aha... # tune2fs -l /dev/mapper/vg_withnail-LogVol02 | grep options Default mount options: (none) > Does 'tune2fs -o acl,user_xattr $my_home_logical_volume' fix it? > After running that command: # tune2fs -l /dev/mapper/vg_withnail-LogVol02 | grep options Default mount options: user_xattr acl However, I still get the dialogue "Errors were encountered changing permissions for the following directories: /home/xxx : setfacl: /home/xxx: Operation not supported" presumably because /home/xxx is not owned by root (but by xxx). This is probably not a bug I am guessing. Moving the isntall media iso to /home/root which IS owned by root fixes things and the install happens. > See bug #530210 It does seem to be a manifestation of the same problem, yeah. (In reply to comment #2) > After running that command: > > # tune2fs -l /dev/mapper/vg_withnail-LogVol02 | grep options > Default mount options: user_xattr acl > > > However, I still get the dialogue > > "Errors were encountered changing permissions for the following directories: > /home/xxx : setfacl: /home/xxx: Operation not supported" You probably need to reboot for it to be mounted with the 'acl option > presumably because /home/xxx is not owned by root (but by xxx). This is > probably not a bug I am guessing. No, the issue is that it needs to be readable by the 'qemu' user; after rebooting, it should work fine in your homedir thanks for the update, marking as a dup of bug #530201 *** This bug has been marked as a duplicate of bug 530210 *** (In reply to comment #3) > No, the issue is that it needs to be readable by the 'qemu' user; after > rebooting, it should work fine in your homedir > Right, gotcha, of course. Can't reboot right now to test it, but I am sure you're right. > thanks for the update, marking as a dup of bug #530201 OK - thanks for taking the time to look at it. |
Description of problem: When, as root, creating a new guest from an iso image which is *not* located in /var/lib/libvirt/images, after selecting the path to the iso file, I get a dialogue box saying: "The emulator may not have search permissions for the path '/home/xxx/w32/WindowsXP/WindowsXP.iso'. Do you want to correct this now? so I click OK, and then I get another dialogue box saying: "Errors were encountered changing permissions for the following directories: /home/xxx : setfacl: /home/xxx: Operation not supported" Note that /home/xxx is on an ext4 formatted filesystem. I then click OK and carry on until I get a dialogue box with: "Unable to complete install: 'internal error unable to start guest: qemu: could not open disk image /home/xxx/w32/WindowsXP/WindowsXP.iso: Permission denied '" And in the details part of that dialogue box: "Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: qemu: could not open disk image /home/xxx/w32/WindowsXP/WindowsXP.iso: Permission denied Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 1575, in do_install dom = guest.start_install(False, meter = meter) File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 628, in start_install return self._do_install(consolecb, meter, removeOld, wait) File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 726, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1077, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: internal error unable to start guest: qemu: could not open disk image /home/xxx/w32/WindowsXP/WindowsXP.iso: Permission denied ' " Note also that: # ls -ldZ /home/xxx/w32/WindowsXP/ drwxr-xr-x. xxx xxx unconfined_u:object_r:virt_image_t:s0 /home/xxx/w32/WindowsXP/ # ls -lZ /home/xxx/w32/WindowsXP/WindowsXP.iso -rw-rw-r--. qemu qemu system_u:object_r:virt_content_t:s0 /home/xxx/w32/WindowsXP/WindowsXP.iso Version-Release number of selected component (if applicable): libvirt-client-0.7.1-15.fc12.x86_64 virt-manager-0.8.0-7.fc12.noarch python-virtinst-0.500.0-5.fc12.noarch libvirt-python-0.7.1-15.fc12.x86_64 libvirt-0.7.1-15.fc12.x86_64 # rpm -qa | grep qemu qemu-system-sh4-0.11.0-11.fc12.x86_64 gpxe-roms-qemu-0.9.7-6.fc12.noarch qemu-common-0.11.0-11.fc12.x86_64 qemu-user-0.11.0-11.fc12.x86_64 qemu-system-x86-0.11.0-11.fc12.x86_64 qemu-system-sparc-0.11.0-11.fc12.x86_64 qemu-system-mips-0.11.0-11.fc12.x86_64 qemu-kvm-0.11.0-11.fc12.x86_64 qemu-system-arm-0.11.0-11.fc12.x86_64 qemu-system-m68k-0.11.0-11.fc12.x86_64 qemu-kvm-tools-0.11.0-11.fc12.x86_64 qemu-img-0.11.0-11.fc12.x86_64 qemu-0.11.0-11.fc12.x86_64 qemu-system-cris-0.11.0-11.fc12.x86_64 qemu-system-ppc-0.11.0-11.fc12.x86_64