Yevgeniy Lyublev wrote:
> Dear Maarten.
>
>>
>>> Dear Owen.
>>> I have understood reason this problem.
>>>
>>> [root@se3 root]# grep ops /etc/group
>>> ops:x:45000:opssgm001
>>> opssgm:x:46001:
>>> [root@se3 root]# grep opssgm /etc/passwd
>>> opssgm:x:45000:45000:mapped user for group ID ops:/home/opssgm:/bin/bash
>>> opssgm001:x:18960:46001:mapped user for group ID
>>> ops:/home/opssgm001:/bin/bash
>>>
>>> opssgm001 in opssgm group, but directory
>>
>>
>> opssgm001 must also be in the "ops" group. Check:
>>
>> grep opssgm001 /etc/group | fold -w 77
>
>
> I absolute agree with You, but default group opssgm001 is opssgm, but
> not ops.
> .
> [root@se3 root]# groups opssgm001
> opssgm001 : opssgm ops
>
> After opssgm001 login it must execute chgrp for moving in ops group/
> I have changed opssgm001 ID group in password file, and SAM tests are
> executed successfully now.
Does PNFS not consider the secondary groups then?
Does anybody else see the same problems with their dCache SE?
I agree there is a problem if an sgm user happens to create a directory,
because it will not be writable for the rest of the VO.
Maybe we should make the normal VO group the primary group,
and the special group the secondary group?
The software area can be given the group 's' bit so that it can still be
writable only to the special group.
Comments?
> From users.conf
> [root@se3 ORIG]# grep opssgm ../*
> ../users.conf:18960:opssgm001:46001,45000:opssgm,ops:ops:sgm:
>
> ^^^^^^^^^
> Best regards. Yevgeniy.
>
>
>>
>>> [root@se3 root]# ll /pnfs/itep.ru/data/ops
>>> total 1
>>> drwxrwxr-x 1 ops001 ops 512 Apr 27 00:10 generated
>>>
>>> for ops group only.
>>
>>
>> Can you do an "su - opssgm001" and try writing into the "ops" directory?
>>
>
|