On 10/17/2012 08:15 PM, Itamar Heim wrote:
On 10/16/2012 04:38 PM, Keith Robertson wrote:
On 10/16/2012 10:33 AM, Neil wrote:
Hi Keith,
On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson <kroberts@redhat.com> wrote:
Neil,
I suspect that you are having the same issue described in [1].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=858880 I unfortunately don't have access to view this bug...
"You are not authorized to access bug #858880."
Is there any progress on repairing it, or do you know if there is a work round in the meantime? AFAIK, there is no work-a-round for the issue and, I think that the engine team is having a hard time reproducing the issue.
As a work-a-round you could try 'chmod -R 644 /path/to/iso/domain' . This gives all files in the ISO domain world read privs. (not what you want) but I think it will fix the engine issue.
You should know that the ISO uploader uploads files as 36:36 and 640 perms. This is the correct behavior and, based on your previous emails I can see that your files do appear to match that ACL.
the output of vdsClient was an empty list of iso's, so it seems like a vdsm issue rather than engine? It could be. We have two similar cases now and this most recent case appears to have resolved the issue by creating the group 'kvm' on the 'node' (I think).
Based, on that information I suspect that there could be a problem in VDSM wherein they are attempting to resolve the user/group by name (ie. vdsm/kvm) and are getting blocked when either that user doesn't exist or exists with a name != vdsm or kvm. It might be apropos to have a look at the code and see if/where they're resolving uid/gid 36 and/or vdsm:kvm. Neil, - Can you explain where you created the 'kvm' group name? Was it on the node, oVirt engine, or the NFS server? - After you created this group did were the permisions on the files in the ISO domain (vdsm:kvm 0640) or were they (vdsm:kvm 0644 <- notice world read)