On 10/18/2012 07:06 PM, Keith Robertson wrote:
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(a)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)
If using NFSv4 what is sent through the network is the user/group name,
not the numeric user/group id. In this case the NFS server was sending
the string "vdsm" as the group name. When this arrives to the NFS client
(the hypervisor in this case) it is translated to a numeric group id,
but as there is no "vdsm" group in the client it is translated to the
numeric user id of "nobody".
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.