Michel;
>When I build an smb.conf using a line like:
>
>include = /usr/local/samba/lib/%G.conf
>
>then it works beautifully for the shares that are listed in the
>appropriate <primary group>.conf files, that is, I can connect to them
>and all...
>
>However, I can only _browse_ the shares listed in the main smb.conf
>file, not the ones in the <primary group>.conf files that should
>be included, even though those shares are accessable to me..
>
>I can only explain this by the browser-daemon not evaluating the %G
>variable (just like "testparm" ignores this). Is this fixable ?
>
>I would very much like a group-dependant browselist...
You are mixing up two different things: browsing the share list and mounting of
a share.
In other words: When your PC requests a share list it will receive an answer
from sambe. At this moment samba does
not know about you being user A or user B, it just offers a list of share namess
known when it started up. As it has
no connection to any special user at this moment, it can absolutely not know
about this users permissions or even
its groups. This means: samba can and will not substitute anything like %G in
smb.conf when being asked for a share
list. I bet it will report something like "cant open
/usr/local/samba/lib/.conf" when started with higher debug
levels. Anyway ... same with NT: it offers you a share list with lots of shares
you are not allowed to connect to.
Another situation when connecting ("mounting") the share: For each
connection from any user (comparable to some kind
of login) smbd parses smb.conf. At this moment the user is known (or is made
known by insisting on the correct
password) as well as his primary group. smbd will include the correct %G.conf
after substituting %G and then know
about the shares configured in that file.
Now for some implementation thoughts: Consider a machine with 200 plus some more
shares (so probably some more than
500 users) and also consider a situation where the user name is already known to
samba. To offer you a list of
permitted shares it had to hold this list in memory for each user or to evaluate
this list every moment the user
requests one. Lots of memory or lots of disk activity, huh?
After all this one more advice: Think of some newly invented share being
mountable by groupA as well as by groupB.
You had to configure the same stuff in groupA.conf and groupB.conf. You'd
better try to have both groups in smb.conf
and define:
valid users = @groupA, groupB
and (just to be on the safe side):
create mask = 771
force group = groupA
Stability paranoids configure:
force user = <some_user_in_groupA>:
to let users change permissions of files not created by themselves ...
Regards,
Robert
--
---------------------------------------------------------------
Robert.Dahlem@frankfurt.netsurf.de
Radio Bornheim - 2:2461/332@fidonet +49-69-4930830 (ZyX, V34)
2:2461/326@fidonet +49-69-94414444 (ISDN X.75)
---------------------------------------------------------------