Bug 596672 - Directory storage pool created with permissions 700
Directory storage pool created with permissions 700
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-27 05:46 EDT by Matthew Booth
Modified: 2012-01-24 16:55 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-24 16:55:15 EST
Type: ---
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 Matthew Booth 2010-05-27 05:46:39 EDT
Description of problem:
virt-manager creates new directory storage pools with permissions 700, owned by root. qemu started by libvirt, running as user qemu, is not able to read the contents of this directory, so any domain with storage in the new pool will not start.

Changing the permissions to 711, the same as /var/lib/libvirt/images, allows domains to start.

Version-Release number of selected component (if applicable):
virt-manager-0.8.4-1.fc13.noarch
Comment 1 Cole Robinson 2010-05-27 10:13:08 EDT
What libvirt version are you using?
Comment 2 Matthew Booth 2010-05-27 10:59:17 EDT
libvirt-0.8.1-1.fc13.x86_64
Comment 3 Cole Robinson 2010-05-27 15:30:22 EDT
Hmm, is this definitely the case with that libvirt version? restart libvirtd and all that? I thought this was fixed upstream.

virt-manager doesn't explicitly set permissions when creating the default pool, libvirt might be doing it by accident (we previously had an issue with owner/group like this). Reassigning to rawhide/libvirt since you are using rawvirt packages.
Comment 4 Bug Zapper 2010-07-30 07:43:31 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Fedora Admin XMLRPC Client 2011-09-22 13:56:50 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 6 Fedora Admin XMLRPC Client 2011-09-22 14:00:07 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 7 Fedora Admin XMLRPC Client 2011-11-30 14:56:20 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Fedora Admin XMLRPC Client 2011-11-30 14:57:46 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 9 Fedora Admin XMLRPC Client 2011-11-30 15:02:38 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 10 Fedora Admin XMLRPC Client 2011-11-30 15:03:31 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Cole Robinson 2012-01-24 16:55:15 EST
Closing as INSUFFICIENT_DATA (F14 is EOL anyways)

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