[cobalt-users] SAMBA Security on the NASRaQ

[Lennart Henäng <lennart.henang@xxxxxxxxxxxxx>]

> Hello!
>
> I've got a serious problem with the NASRaQ leaving us with no access
> to shares.

> The following happens:
>
> 1. We have four shares and hence four groups in /etc/group
> 2. We add a share called "Kurt" and specify a NASRaq group called
> "support" as the group with full access
> 3. So, now we have five groups in /etc/group and the group related to
> "Kurt" have the members of the "support" group in it
> 4. We add another NASRaQ group to have full access to the "Kurt" share
>
> 5. Everything is OK
> 6. We add a new user and add her to the NASRaQ "support" group
>
> Now, all the user id's listed for the NASRaQ related groups in
> /etc/group are now gone (except for the group that relates to the
> NASRaQ "everyone" group.
>
> This is extremely frustrating to us. I think the way NASRaQ handles
> the group security is very strange.
>
> Why couldn't it have a one-to-one relationship between the NASRaQ
> groups and the UNIX groups in /etc/group?
> Why can't we specify which groups should be able to have read only
> access as we can specify which groups can have full access to a share?
>
> Do you recommend us to completely skip the group security facility of
> the admin user interface and handle it by using ordinary UNIX groups,
> or how can we get rid of this problem?

> I've been investigating some more to make it work even though the
> NASRaQ seems buggy. We created own groups like "all", "teachers" and
> "pupils", and we tried to use the SAMBA force group = zzzz parameter
> for some of the shares. But, it doesn't work the way we want it. SAMBA
> neglect the force group and always forces the NASRaQ generated group
> name (like "50005") which is based on 'share number'. We also
> specified our own groups in the write lists and it doesn't  work the
> way we expect.

> This is extremely annoying to us and we would like someone to shed
> some light on this.
>

Regards, Lennart Henang, Vibyskolan, Sweden