Thanks very much for taking the trouble to write, Dave.
Yes, I understand what [homes] does, and I am using it for private
directory structures.
The problems with [homes] are that :-
1) It defines a directory mapping (and browse visibility) on a user basis,
not a group basis, and gives the share the name of that particular user, and
2) There can only be one of them, requiring that everything I want to
control must go under that private tree, and therefore everything under
that user tree is private, whether I like it or not, unless I create a
spiderweb of new mounts or links into various parts of that tree. That is
difficult to document and manage.
The problem is that I don't want a single directory tree with my name on it
just visible to me, or any other single person. I want a series of shares
VISIBLE to a GROUP of people, but INVISIBLE to people outside that group.
If there was a group equivalent of [homes] it would be something.
If I could use a psuedo C statement like
browseable = ((%u == fred) | (%u == jim) | (%g == @engineering));
that would work,
Or, if there was a "browse list" like there is a "write list", then I could
do this :-
[stuff_for_grownups_only]
path = /usr/adult_stuff
read list = @parents
write list = @parents
browse list = @parents
Anybody in the group "parents" can see and access the share, while anyone
not in the group can't even see it, let alone access it.
I've investigated [homes], %u, %m, read list, and chmod. None of these do
what I need. All these tools work on the issue of accessibility. My issue
is visibilibty, not accessibility.
To reiterate one more time ...
I want to make a SERIES of individual shares with their own
USER_INDEPENDANT names VISIBLE "browseable" (or not) as a function of the
identity or group membership of whoever is logged on.
I don't want to map a SINGLE directory tree available with the name of the
particular user. I don't want shares to be visible but not accessible.
See ?
Many thanks again :-)
julian.
===================================
At 07:35 AM 12/15/01 -0600, you wrote:
>I finally hit upon a similar idea this morning. The generic [Homes]
>share, as defined by Samba, is created on the fly for each particular
>user when they login, and is only visible to that user. It automatically
>maps to the user's Linux account and home directory. Thus, when I login
>on my laptop to my home network, I can see two shares on my Linux Samba
>server: a "Public" share for me and my wife, and a "Dave" share that is
>my home directory. My wife Carrie will never see the Dave share (unless
>she logs in as me), and I will never see the Carrie share (unless I log
>in as her).
>
>Since the Dave share is my own home directory, I can create
>subdirectories, etc. and have them all private for myself. Likewise for
>Carrie. If I want to make a file or directory public to everyone, I can
>just copy or move it to the Public share, and then delete it or move it
>back to my home (Dave) share when I want it to become private again.
>
>Here's my [Homes] definition smb.conf from my server:
>
>[homes]
> comment = Home Directories
> browseable = no
> writable = yes
> guest ok = no
>
>Notice that I do not need to define a path. Samba knows that the share
>definition [Homes] is supposed to point to /home/username, where
>username is the Windows (and Linux) login user name. All I need to do is
>create a Linux user account that matches each Windows user account (name
>and password), and then each Windows user will have a home share that is
>private. Also notice that I do not need to list valid users. Again, this
>is because Samba automatically knows that the only valid user for a
>particular home share is the one user to whom the home directory
>belongs.
>
>Dave
>
>On Sat, 2001-12-15 at 03:54, Jose M. Sanchez wrote:
> > The "solution" is plainly documented, but often overlooked as a
> > result...
> >
> > So here is ONE way of doing what you want easily...
> >
> > You probably have smb.conf share headers already defined in the file...
> > Such as
> >
> > [Bill]
> > Path = /home/bill
> > public = no
> > valid users = bill
> > [Mary]
> > Path = /home/mary
> > public = no
> > valid users = mary
> > [Mark]
> > Path = /home/mark
> > public = no
> > valid users = mark
> >
> > What you've done is effectively defined things which YOU WANT
> > "advertised" by Samba discreetly...
> >
> > -WRONG-!
> >
> > Instead what you want is
> >
> > [home]
> > path = /home/%m
> > public = no
> > writeable = yes
> > valid users = bill mark mary @validgroup
> >
> > BTW: Samba will create the directories for you automatically as the
> > users attach, if they don't exist.
> > BTW: The @validgroup definition is another way to define valid users...
> >
> > That's it!
> >
> > Huh? (I hear the scratching of the head from here...)
> >
> > Yes the %m is a Samba "on the fly" substitution macro, which gets
> > replaced when the user attempts to attach to the share...
> >
> > So when Mark attaches to the \\SAMBABOX\HOME share he only sees
> > /home/mark
> >
> > Likewise when Mary attaches to it, she only sees /home/mary. Etc.
> >
> > Samba provides MANY easy ways to skin the cat. Microsoft provides one.
> >
> > Don't mistake Microsoft's restrictions for EASE OF USE. Your familiarity
> > with Microsoft's metaphors came at a cost. A newbie would be just as
> > clueless with Microsoft's way of doing things as they would be with
> > Samba.
> >
> > Microsoft doesn't make it inherently easy, rather you are used to their
> > way of thinking.
> >
> > Samba/Linux does not require rope tricks, just the same "devotion" to
> > reading the manual (or playing with things) that you at one point
> > underwent with MS$'s products.
> >
> > Linux can sing, the 800lb gorilla can only grunt.
>
>--
>In the broad and final sense all institutions are educational in the
>sense that they operate to form the attitudes, dispositions, abilities
>and disabilities that constitute a concrete personality...Whether this
>educative process is carried on in a predominantly democratic or non-
>democratic way becomes, therefore, a question of transcendent importance
>not only for education itself but for its final effect upon all the
>interests and activites of a society that is committed to the democratic
>way of life.
>- John Dewey (1859-1953), American philosopher
>
>
>Want to buy your Pack or Services from MandrakeSoft?
>Go to http://www.mandrakestore.com
==============================
Julian A. Opificius.
802 Fawn Road, Elk River, MN 55330.
Home: 763.441.1291, Cell: 763.360.5919
[EMAIL PROTECTED] ICQ: 3268206
==============================
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
