Launchpad has imported 36 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=517304.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2009-08-13T12:58:22+00:00 Tim wrote: Description of problem: When trying to install a guest from an ISO file in an NFS-mounted directory I get this from virt-manager: Error Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: libvir: QEMU error : cannot set ownership on /mnt/cyberelk/Fedora-11-x86_64-DVD/Fedora-11-x86_64-DVD.iso: Read- only file system Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 1489, 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: libvir: QEMU error : cannot set ownership on /mnt/cyberelk/Fedora-11-x86_64-DVD/Fedora-11-x86_64-DVD.iso: Read-only file system ' Version-Release number of selected component (if applicable): virt-manager-0.8.0-1.fc12.noarch libvirt-0.7.0-3.fc12.x86_64 How reproducible: 100% Steps to Reproduce: 1.Mount NFS directory with '-ocontext="system_u:object_r:virt_content_t:s0" 2.Install guest from ISO in that directory. Actual results: Error message. Additional info: $ mount | grep virt cyberelk:/mnt/archive/rh on /mnt/cyberelk type nfs (rw,context="system_u:object_r:virt_content_t:s0",addr=192.168.2.1) $ ls -l /mnt/cyberelk/Fedora-11-x86_64-DVD/ total 4172188 -rw-rw-r--. 1 twaugh twaugh 1620 2009-06-17 07:44 Fedora-11-x86_64-CHECKSUM -rw-rw-r--. 1 root root 4268124160 2009-06-18 00:06 Fedora-11-x86_64-DVD.iso drwxr-xr-x. 2 root root 4096 2009-07-22 17:04 loop Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/0 ------------------------------------------------------------------------ On 2009-08-13T13:09:42+00:00 Tim wrote: Hacky workaround: export the NFS directory with 'rw,no_root_squash'. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/1 ------------------------------------------------------------------------ On 2009-08-13T13:31:18+00:00 Tim wrote: Actually I'm not so sure that even does work around it. When booting a guest I get: Booting from CD-Rom... CDROM boot failure code : 0003 Boot failed: could not read the boot disk FATAL: No bootable device. (Of course, the ISO checksum is correct..) Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/2 ------------------------------------------------------------------------ On 2009-08-13T13:37:45+00:00 Daniel wrote: A quick summary of what's going on here for the benefit of anyone using NFS - libvirt now runs QEMU as a 'qemu:qemu' user/group pair, instead of root:root - libvirt will chown() disk images to this user pair when starting a guest to ensure they're accessible (similar to it setting SELinux labels) Now for the problems you've exposed - If the NFS share is read-only, clearly we can't change ownership at all - If the NFS share is read-write, but root-squash, a libvirtd won't be able to change ownership because it gets squashed. So - If the disk already has correct ownership, there's nothing for us todo, we should skip this chown step entirely - If the guest disk is read-only, we should treat this as non-fatal. The disk quite likely has world-read permission set which is more than sufficient. - If the guest disk is read-write, and has incorrect ownership, we have to try and change it, but if it fails there's nothing we can do. The admin will have to fix it. There is one further problem wrt to NFS and the storage capabilities. Since libvirtd run as root, if you're using a libvirt storage pool based on NFS then its neccessary to have root squash disabled at this time We need to figure out a way to let libvirt create files on NFS storage pools with the correct UID right from start, so that we don't ever need to chown things. Since libvirtd runs as root, this probably means we need to spawn a small helper program to create NFS files, which can change its UID to the desired target, avoiding the root squash issue. In the mean time, there are two workarounds: - Use a writable NFS export with root squash disabled Or - Edit /etc/libvirt/qemu.conf and set it to run guest as user="root" and group="root", instead of qemu/qemu (ie reverting to < F11 behaviour) The choice is yours based on whether security of host OS more important (change the NFS server), or security of NFS server more important (change QEMU to run as root). Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/3 ------------------------------------------------------------------------ On 2009-08-14T18:58:22+00:00 Mark wrote: dan: should we split some of this up into separate bugs? Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/4 ------------------------------------------------------------------------ On 2009-08-15T09:03:45+00:00 Tim wrote: Neither work-around works for me actually. Use writable NFS export with no_root_squash: see comment #2 Run guest as root:root: see bug #517619. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/5 ------------------------------------------------------------------------ On 2009-09-15T10:47:26+00:00 Daniel wrote: WRT to comment #5, if you re-configured libvirtd to run qemu as root:root, we now automatically set directory ownership correctly. WRT to comment #2, I believe that one is the bug caused by accidentally using virtio for CDROMs also now fixed. So at least the two workarounds ought to be operational now. Leave this one open to track improving the logic in libvirtd though as per comment #3 Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/6 ------------------------------------------------------------------------ On 2009-10-02T15:33:34+00:00 Mark wrote: *** Bug 526199 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/7 ------------------------------------------------------------------------ On 2009-10-09T12:59:33+00:00 Mark wrote: *** Bug 527102 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/8 ------------------------------------------------------------------------ On 2009-11-08T07:28:36+00:00 Yanko wrote: *** Bug 533649 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/9 ------------------------------------------------------------------------ On 2009-11-19T13:13:58+00:00 Mark wrote: *** Bug 538527 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/10 ------------------------------------------------------------------------ On 2009-11-19T13:31:05+00:00 Mark wrote: Note, the reporter of bug #538527 was having similar problems, but with using a samba mount Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/11 ------------------------------------------------------------------------ On 2009-11-19T14:28:05+00:00 Rubin wrote: Hi, I'm the reporter of #538527 (my first bugreport using abrt - I had not realized the coolness of abrt until now ;-). I've tested the behaviour on my samba share and on an nfs share. Behaviour is indeed the same. When I copy the images to my desktop system you can see that libvirt changes the ownership of the files: [rubin@inden Desktop]$ ls -l total 6584024 -rw-r--r-- 1 qemu qemu 3204427776 2009-11-19 11:29 Fedora-12-i386-DVD.iso -rw-r--r-- 1 qemu qemu 3537600512 2009-11-19 11:37 Fedora-12-x86_64-DVD.iso The owner was previously rubin:users. The mode was previously 664. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/12 ------------------------------------------------------------------------ On 2010-01-01T23:41:38+00:00 Albert wrote: It's clear to me that libvirt should _not_ be changing the permissions of the source installation ISO image in the first place and this is the real bug. By all means, change the ownership of the destination VM image (disk) being created, but not the source installation image or ISO. A simply use case would be installing a VM from two or more different systems sharing an NFS based ISO image, in this case who owns the ISO image assuming the uid/gid differ on those systems. The ISO image should have sufficient privileges to start with as set by the ADMIN otherwise contact your administrator (most likely yourself) My guess is that the libvirt code just blindly sets the both the source and destination image permissions without much thought. The Solution: Don't set the destination permissions from libvirt (or anything else) and if libvert cannot read the source image display a error message that humans can understand like "access denied" and not what it currently displays and I quote "Unable to complete install: 'internal error unable to start guest: libvir: QEMU error : cannot set ownership on /datadisk/ISO/AsteriskNOW-1.5.0-i386-1of1.iso: Invalid argument" The above message indicates another bug altogether, it implies I'm trying to start the image which I am not, I'm simply setting it up in virt-manager. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/13 ------------------------------------------------------------------------ On 2010-01-06T11:22:28+00:00 Richard wrote: I have to agree with comment 13 that libvirt(d) really shouldn't be in the business of chowning files. Even checking file permissions is dubious, since to do a check you have to know everything about how file permissions, SELinux, POSIX ACLs etc work. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/14 ------------------------------------------------------------------------ On 2010-01-06T12:06:06+00:00 Daniel wrote: *** Bug 552858 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/15 ------------------------------------------------------------------------ On 2010-01-18T01:32:27+00:00 Jens wrote: Any update? Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/16 ------------------------------------------------------------------------ On 2010-03-15T12:45:49+00:00 Bug wrote: This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/17 ------------------------------------------------------------------------ On 2010-03-28T17:34:21+00:00 John wrote: I fully agree with comment #14 and comment #13. It's very common to have a local mirror of the ISOs shared via NFS (or Samba) so that repeated downloads aren't necessary for everyone at that site. My work around for now is to make a copy on the local host in /tmp from the NFS share, which is just plain silly, sad, and embarrassing. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/18 ------------------------------------------------------------------------ On 2010-04-30T02:16:04+00:00 Jens wrote: Any chance of a fix in the F13 timeframe? This is quite a pain point IMHO. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/19 ------------------------------------------------------------------------ On 2010-04-30T02:19:04+00:00 Jens wrote: (Updating summary based on preceding comments.) Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/20 ------------------------------------------------------------------------ On 2010-07-02T14:22:25+00:00 Frank wrote: (In reply to comment #3) > - Edit /etc/libvirt/qemu.conf and set it to run guest as user="root" and > group="root", instead of qemu/qemu (ie reverting to < F11 behaviour) > This didn't work for me. same permission problem. libvirt-0.7.7-5.fc13.x86_64 virt-manager-0.8.4-1.fc13.noarch The nfs server is a NAS Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/21 ------------------------------------------------------------------------ On 2010-07-07T01:40:25+00:00 Gary wrote: Don't know if this is apparent to all people having this issue, but user qemu and group qemu MUST exist on the NFS server, or you can't set the permissions, even as root on a no_root_squash share. I don't know if that is the way NFS is SUPPOSE to work or not. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/22 ------------------------------------------------------------------------ On 2010-07-07T08:22:43+00:00 Frank wrote: (In reply to comment #22) > Don't know if this is apparent to all people having this issue, but user qemu > and group qemu MUST exist on the NFS server, or you can't set the permissions, > even as root on a no_root_squash share. I don't know if that is the way NFS > is > SUPPOSE to work or not. Once I did that I was fine: Using the nas (nfs server) web-interface created user=qemu groups=qemu\kvm also created a secure folder for qemu. Transferred all ~/Torrents to this new folder. Adjusted virt-host /etc/fstab to suit. virthost$ su chown -R qemu:kvm /new_path/to/Torrents. no permission problems since Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/23 ------------------------------------------------------------------------ On 2010-07-07T14:32:53+00:00 Marc wrote: Why should the iso need to have special permissions for qemu or kvm? Isn't it pretending the ISO is a CD? As long as it can read the ISO, there should be no need to change ownership of it. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/24 ------------------------------------------------------------------------ On 2011-01-31T13:33:15+00:00 TakIchikawa wrote: I was embarrassed, too. However, I was able to 'not to change ownership' by editing the following parameter. vi /etc/libvirt/qemu.conf 139 # Whether libvirt should dynamically change file ownership 140 # to match the configured user/group above. Defaults to 1. 141 # Set to 0 to disable file ownership changes. 142 #dynamic_ownership = 1 143 dynamic_ownership = 0 But, where this side effect occurs is not understood. Is it good in this? Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/26 ------------------------------------------------------------------------ On 2011-06-02T17:50:27+00:00 Bug wrote: This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/27 ------------------------------------------------------------------------ On 2011-06-03T08:01:45+00:00 Jens wrote: Still happens with F15 as far as I can tell. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/28 ------------------------------------------------------------------------ On 2011-06-14T22:09:05+00:00 Laine wrote: Please test this on F15 with libvirt-0.9.2 when it is available (the virt-preview repo for F15 is still at 0.9.1). The following commit may solve your problem: commit 62ed801c13787cc844e75db7cd2d4c8a42454fcc Author: Laine Stump <[email protected]> Date: Fri Jun 3 11:59:09 2011 -0400 security driver: ignore EINVAL when chowning an image file This fixes: https://bugzilla.redhat.com/show_bug.cgi?id=702044 https://bugzilla.redhat.com/show_bug.cgi?id=709454 Both of these complain of a failure to use an image file that resides on a read-only NFS volume. The function in the DAC security driver that chowns image files to the qemu user:group before using them already has special cases to ignore failure of chown on read-only file systems, and in a few other cases, but it hadn't been checking for EINVAL, which is what is returned if the qemu user doesn't even exist on the NFS server. Since the explanation of EINVAL in the chown man page almost exactly matches the log message already present for the case of EOPNOTSUPP, I've just added EINVAL to that same conditional. As long as the qemu user/group has permission to read the ISO file with its existing user/group/mode on the server, any errors while attempting to chown/chgrp the file will be ignored, and libvirt will allow qemu to use the image (you don't even have to set dynamic_ownership=0). If you're unfamiliar with the virt-preview repo, please check here: http://fedoraproject.org/wiki/Virtualization_Preview_Repository Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/29 ------------------------------------------------------------------------ On 2011-09-22T17:54:30+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/30 ------------------------------------------------------------------------ On 2011-09-22T17:58:20+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/31 ------------------------------------------------------------------------ On 2011-11-30T20:05:34+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/32 ------------------------------------------------------------------------ On 2011-11-30T20:05:50+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/33 ------------------------------------------------------------------------ On 2011-11-30T20:09:29+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/34 ------------------------------------------------------------------------ On 2011-11-30T20:09:38+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/35 ------------------------------------------------------------------------ On 2012-02-22T17:23:42+00:00 Laine wrote: This bug was actually fixed and verified quite a long time ago. Reply at: https://bugs.launchpad.net/ubuntu/+source/virt- manager/+bug/696908/comments/36 ** Changed in: virt-manager Status: Unknown => Fix Released ** Changed in: virt-manager Importance: Unknown => Medium ** Bug watch added: Red Hat Bugzilla #702044 https://bugzilla.redhat.com/show_bug.cgi?id=702044 ** Bug watch added: Red Hat Bugzilla #709454 https://bugzilla.redhat.com/show_bug.cgi?id=709454 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/696908 Title: Can't create guests from ISOs on Samba share and NTFS - "search permissions" error To manage notifications about this bug go to: https://bugs.launchpad.net/virt-manager/+bug/696908/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
