samba - Jan 2005 - Any danger in having two shares with same name?

Hi, 

Don't ask why I'm posing this question -- actually, I WILL explain below
--
but is there any danger in having two shares in Samba with the same name? 

Here's our situation. We have a bunch of production machines out in the 
field. On those machines, we are constantly setting up "special project
shares" for
each user (different from the user's Home directory) that refer to private 
directories only accessible by that user. We define those "special project 
shares" in a series of "smb.username.conf" files, where we also
define which of
hundreds of other shares are accessible to that user particular user. The whole 
process of setting up shares is highly automated from the point of view of the 
end user. 

By the way, we reference those "smb.username.conf" files in the
general
smb.conf file with the statement: 

include = smb.%U.conf

... so each user sees all the shares listed in their own
"smb.username.conf"
file as well as all the browseable shares listed in the general
"smb.conf"
file. 

This arrangement was working perfectly, until we were asked to turn some of 
the systems into Primary Domain Controllers and give hundreds of users roaming 
profiles. Our users now want the "special project share" for each user
to be
automatically mapped as the "P Drive" in Windows whenever a user logs
on to a
client system. 

However, we have found that Windows won't process any shares listed in the 
"smb.username.conf" directories while it executes the logon.bat script
during
log on. We know the logon.bat file IS being executed -- it syncs the client time
with the server time, and it maps any shares we specify in the general 
smb.conf file. But it won't map any shares defined in those
smb.username.conf files.

Curiously, if we run the logon.bat file again about 10 seconds after log on 
has completed, it will map the shares listed in the smb.username.conf file!. 

As a workaround, we decided to take an alternate approach to defining the 
"special project shares". For each of the "special project
shares" (that all
users have) we put a listing in the general smb.conf file as follows: 

[Special Project Share A]
    Comment = Special Folder A
    path = /home/theboss/%U/Special Folder A
    read only = No
    write list = %U
    guest ok = Yes
    create mask = 0775
    directory mask = 0775
    

So now, we have two listings for "Special Project Share A" -- one in
the
user's smb.username.conf file, and one in the general smb.conf file. 

The question is, is there any danger of Samba or the Windows workstations 
getting confused? Each of these duplicate shares has the SAME NAME, and refers
to
the EXACT SAME DIRECTORY on the Linux box. And has the same access and 
read/write settings. It's probably the same as if you accidentally created
the same
share twice in your smb.conf file. 

I would love to hear from a knowledgeable authority on this. 

The best solution, of course, would be to stop defining the "Special
Project
Shares" in the user's "smb.username.conf" files. However, we
would have to
make many changes in the underlying program that is creating these shares and
for
the next few months it's not practical to update the programs on so many 
individual user's machines. It's much more practical to simply send out
a new
smb.conf file to every user. 

Regards, 
Andy Liebman

AndyLiebman@aol.com wrote:
> Hi, 
> 
> Don't ask why I'm posing this question -- actually, I WILL explain
below --
> but is there any danger in having two shares in Samba with the same name? 
> 
> Here's our situation. We have a bunch of production machines out in the
> field. On those machines, we are constantly setting up "special
project shares" for
> each user (different from the user's Home directory) that refer to
private
> directories only accessible by that user. We define those "special
project
> shares" in a series of "smb.username.conf" files, where we
also define which of
> hundreds of other shares are accessible to that user particular user. The
whole
> process of setting up shares is highly automated from the point of view of
the
> end user. 
> 
> By the way, we reference those "smb.username.conf" files in the
general
> smb.conf file with the statement: 
> 
> include = smb.%U.conf
> 
> ... so each user sees all the shares listed in their own
"smb.username.conf"
> file as well as all the browseable shares listed in the general
"smb.conf"
> file. 
> 
> This arrangement was working perfectly, until we were asked to turn some of
> the systems into Primary Domain Controllers and give hundreds of users
roaming
> profiles. Our users now want the "special project share" for each
user to be
> automatically mapped as the "P Drive" in Windows whenever a user
logs on to a
> client system. 
> 
> However, we have found that Windows won't process any shares listed in
the
> "smb.username.conf" directories while it executes the logon.bat
script during
> log on. We know the logon.bat file IS being executed -- it syncs the client
time
> with the server time, and it maps any shares we specify in the general 
> smb.conf file. But it won't map any shares defined in those
smb.username.conf files.
> 
> Curiously, if we run the logon.bat file again about 10 seconds after log on
> has completed, it will map the shares listed in the smb.username.conf
file!.
> 
> As a workaround, we decided to take an alternate approach to defining the 
> "special project shares". For each of the "special project
shares" (that all
> users have) we put a listing in the general smb.conf file as follows: 
> 
> [Special Project Share A]
>     Comment = Special Folder A
>     path = /home/theboss/%U/Special Folder A
>     read only = No
>     write list = %U
>     guest ok = Yes
>     create mask = 0775
>     directory mask = 0775
>     
> 
> So now, we have two listings for "Special Project Share A" -- one
in the
> user's smb.username.conf file, and one in the general smb.conf file. 
> 
> The question is, is there any danger of Samba or the Windows workstations 
> getting confused? Each of these duplicate shares has the SAME NAME, and
refers to
> the EXACT SAME DIRECTORY on the Linux box. And has the same access and 
> read/write settings. It's probably the same as if you accidentally
created the same
> share twice in your smb.conf file. 
> 
> I would love to hear from a knowledgeable authority on this. 
> 
> The best solution, of course, would be to stop defining the "Special
Project
> Shares" in the user's "smb.username.conf" files.
However, we would have to
> make many changes in the underlying program that is creating these shares
and for
> the next few months it's not practical to update the programs on so
many
> individual user's machines. It's much more practical to simply send
out a new
> smb.conf file to every user. 
I dont mean to be nosy, but why would every user need a copy of 
smb.conf? Do they also run their own samba servers? It sounds like a 
very interesting setup you have - what is the program that makes your 
shares? Does it rewrite your smb.conf? Could you not just remove the 
line "include = smb.%U.conf"? That way they would still get the
project
share, and it would not matter about the customised smb.user.conf file.

PS I dont think duplicate entries in smb.conf will hurt. I just 
discovered a duplicate in one of our include confs, and it was not 
giving any errors. (include = %L.conf - for different netbios names) It 
seems that the "last read" one is the one that is used.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url :
http://lists.samba.org/archive/samba/attachments/20050127/f6487a71/signature.bin

On 26 Jan 2005 , AndyLiebman@aol.com entreated about
 "[Samba] Any danger in having two shares with same":
> Hi, 
> 
> Don't ask why I'm posing this question -- actually, I WILL explain
> below -- but is there any danger in having two shares in Samba with
> the same name? 
probably.  
I *DO* know that having a share with the saem name as a user is a bad 
idea as the user will not get his home share properly but instead get 
the named share.


--
       DA Fo rsyth            Network Supervisor
Principal Technical Officer  -- Institute for Water Research
http://www.ru.ac.za/institutes/iwr/