smbc_opendir() returns -1 but sets errno to 0

Christopher R. Hertel crh at
Tue Nov 25 22:40:21 GMT 2003

On Tue, Nov 25, 2003 at 09:59:53AM -0500, Derrell.Lipman at wrote:
> I encountered an "error" (-1 returned) from libsmbclient's smbc_opendir()
> function with an errno value of 0 (success).  As is intended, if you browse
> the network with smbc_opendir("smb://WORKGROUP") to enumerate the servers,
> a connection to the master browser for WORKGROUP (call it MB) is established.
> If, however, the local name server provides an IP address for MB which is
> different than the machine with netbios name MB, the connection is made to the
> incorrect machine.  If that machine happens to be running samba or is a
> windows machine, it will respond to the enumServers query with a successful
> response, but with a count of zero servers.

...which indicates that the network is not set up correctly.  If you ask
for workgroup name "MB<1D>" then you should get the IP address of the
interface on which "MB<1D>" is registered.  If some other system is 
providing incorrect results, then there is a misconfiguration in the 

> Granted, all of this is likely considered a configuration error at the name
> server, two questions arise:

No, because a WINS-compatible name server will always return a name not 
found error when queried for a <1D> name.  This is a browsing service 
kludge built into WINS.  Samba must comply to be compatible.

> 1. Trying to leave "cleanliness of design" issues aside, might there be any
>    legitimate reason to have a machine with netbios name MB, and a different
>    machine with hostname MB configured in the name server? 

Ah, you're talking about DNS name servers...  Yes, there are certainly 
reasons why the DNS name might not match the NetBIOS name.

- What if I have two machines with DNS names and (perhaps in separate departments within the 
  organization).  Which of those two machines would use the base name 
  "this"?  If they are in the same NetBIOS namespace, they can't both have 
  that same base name.

- In your case it's the workgroup name, not the machine name, that's at 
  issue.  Since the LMB is elected, there is no way (within the protocols)
  to know which of the nodes on your local IP LAN will be elected to LMB
  status, and thus answer to THAT<1D>.  The name THAT<1D> will belong to 
  whichever node is the LMB.  If the name "THAT" is registered in the DNS 
  then which IP address should it point to?  (...and how do you get it to 
  point to the correct IP address unless the LMB does a Dynamic DNS 
  registration every time it wins the election?)

So, the workgroup<1D> name should not be getting resolved via the DNS at
all.  As a workgroup name, and there is no assumption that it will match
the host name of any host on your network.  From the smb.conf(5) man page:

    Note that this method is only used if the NetBIOS name type being
    queried is the 0x20 (server)  name type, otherwise it is ignored.

The same is true for the <1B> name (the Domain Master Browser name).  
This should not be resolved via the DNS because, again, the NetBIOS name
is not going to match the DNS hostname of the system that registered it.

Another thing to note (yeah, I know I'm full of this stuff...):
Many Windows systems register both the machine<00> unique name and the 
workgroup<00> group name.  If the workgroup name matches a machine name 
then there will be a name registration conflict.


> 2. Given that smbc_opendir() is returning -1, should errno be set to something
>    other than 0 to help identify the problem -- even though the NT errno from
>    which errno is being derived was "success"?

Dunno.  Would have to check the workings of that function.  If those 
values indicate an empty list, then it's behaving correctly.

Chris -)-----

"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team --     -)-----   Christopher R. Hertel
jCIFS Team --   -)-----   ubiqx development, uninq.
ubiqx Team --     -)-----   crh at
OnLineBook --    -)-----   crh at

More information about the samba-technical mailing list