When/why is a WORKGROUP; specification needed? - SMB

This is a discussion on When/why is a WORKGROUP; specification needed? - SMB ; I'm trying to understand SMB/CIFS generally. My specific situation is that I am writing an application that runs under Mac OS X 10.3 and accesses SMB shares on a Windows network. It mounts the shares by calling a UNIX shell ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: When/why is a WORKGROUP; specification needed?

  1. When/why is a WORKGROUP; specification needed?

    I'm trying to understand SMB/CIFS generally. My specific situation is
    that I am writing an application that runs under Mac OS X 10.3 and
    accesses SMB shares on a Windows network. It mounts the shares by
    calling a UNIX shell and performing a command like

    mount_smbfs -N "//ELASMOBRANCH;MAKO/SRVINFO" /Volumes/SRVINFO

    Here's what I'm puzzled about. Simply using the bare server name, MAKO

    mount_smbfs -N "//MAKO/SRVINFO" /Volumes/SRVINFO

    seems to work exactly as well as including the workgroup,
    ELASMOBRANCH;MAKO.

    What is even stranger is that I seem to connect even if I supply an
    explicit WORKGROUP; specification that is actually _wrong_, e.g.

    mount_smbfs -N "//TELEOST;MAKO/SRVINFO" /Volumes/CtServer-MAKO-SRVINFO

    when MAKO is not in workgroup TELEOST. In other words, it almost
    appears that the WORKGROUP; portion of the specification is simply
    being ignored.

    This seems to be true in every system context where a workgroup could
    appear, for example the Finder's Go, Connect to Server... command.

    As I understand it, SMB requires all server names to be unique, even
    if they are in different workgroups, so a workgroup specification is
    not logically needed to disambiguate the server name.

    Oddly enough, this all seems to be true even if (as is usually the
    case on our network!) the network browsing mechanism is clunky,
    unreliable, and slow to update. If the server MAKO is on the network I
    seem to be able to connect to it just as well by using "MAKO" as by
    using "ELASMOBRANCH;MAKO" _even if I cannot "see" the ELASMOBRANCH
    workgroup_ in the Mac OS X finder, and even if my colleague on the
    same network hub cannot see the ELASMOBRANCH workgroup in his Windows
    NT explorer._

    Why is there a provision for a WORKGROUP; qualifier? When is a
    WORKGROUP; specification needed, where is it used, and under what
    circumstances would its inclusion make a difference?

  2. Re: When/why is a WORKGROUP; specification needed?


    "Daniel P. B. Smith" wrote in message
    news:cb079247.0410060731.284772f7@posting.google.c om...
    > I'm trying to understand SMB/CIFS generally. My specific situation is
    > that I am writing an application that runs under Mac OS X 10.3 and
    > accesses SMB shares on a Windows network. It mounts the shares by
    > calling a UNIX shell and performing a command like
    >
    > mount_smbfs -N "//ELASMOBRANCH;MAKO/SRVINFO" /Volumes/SRVINFO
    >
    > Here's what I'm puzzled about. Simply using the bare server name, MAKO
    >
    > mount_smbfs -N "//MAKO/SRVINFO" /Volumes/SRVINFO
    >
    > seems to work exactly as well as including the workgroup,
    > ELASMOBRANCH;MAKO.
    >
    > What is even stranger is that I seem to connect even if I supply an
    > explicit WORKGROUP; specification that is actually _wrong_, e.g.
    >
    > mount_smbfs -N "//TELEOST;MAKO/SRVINFO" /Volumes/CtServer-MAKO-SRVINFO
    >
    > when MAKO is not in workgroup TELEOST. In other words, it almost
    > appears that the WORKGROUP; portion of the specification is simply
    > being ignored.
    >
    > This seems to be true in every system context where a workgroup could
    > appear, for example the Finder's Go, Connect to Server... command.
    >
    > As I understand it, SMB requires all server names to be unique, even
    > if they are in different workgroups, so a workgroup specification is
    > not logically needed to disambiguate the server name.
    >
    > Oddly enough, this all seems to be true even if (as is usually the
    > case on our network!) the network browsing mechanism is clunky,
    > unreliable, and slow to update. If the server MAKO is on the network I
    > seem to be able to connect to it just as well by using "MAKO" as by
    > using "ELASMOBRANCH;MAKO" _even if I cannot "see" the ELASMOBRANCH
    > workgroup_ in the Mac OS X finder, and even if my colleague on the
    > same network hub cannot see the ELASMOBRANCH workgroup in his Windows
    > NT explorer._
    >
    > Why is there a provision for a WORKGROUP; qualifier? When is a
    > WORKGROUP; specification needed, where is it used, and under what
    > circumstances would its inclusion make a difference?


    It's optional. I think it's used to specify where the authentication
    happens. If you specify a username/password, you can also specify a
    workgroup. This means nothing to a normal windows peer workgroup as all
    authentication happens on the system you are referencing, but it you have
    domain authentication, it would determine what server will handle the
    authentication.

    As far as the delays, in a SMB network, there are browser lists that keep
    track of the computers and shares in a workgroup. The task is delegated to
    one computer (local master browser) in the workgroup. The other computers
    update their lists (Network Neighborhood) from there. Each computer has a
    cached list so it takes a while for a new computer to appear in the list. I
    think there also is a master browser that compiles a list from all the local
    master browsers. However, if you're trying to access a share in a different
    workgroup, it would have to contact the master browser or local master
    browser of that workgroup for the information which would cause a delay. I
    not sure of the process, but I can see the local master browser doing some
    broadcasting in the local workgroup for the request before the master
    browser is consulted.

    That also brings up the idea of unique computer names. The reason is obvious
    in a local workgroup. However I can't access a computer in a different
    workgroup with a name that is the same as one in my workgroup. I can if I
    use the IP address, but if I do a search by name, I always get the one in
    the workgroup I belong to. The other computer with the duplicate name acts
    the same way within it's own workgroup.




+ Reply to Thread