libsmbclient: Browsing and a URI spec?

Richard Sharpe sharpe at
Sun Dec 31 14:53:34 GMT 2000

At 06:37 AM 12/31/00 -0600, Christopher R. Hertel wrote:
>> Hi,
>Hello, Richard,
>A good writeup.  Having thought a lot about this issue I have, of course, 
>some comments.
>> A very clear approach is:
>>    smb://              means list all servers in the current workgroup.
>>    smb://server/       means list all shares on server.
>>    smb://server/share  means list all directories in share on server.
>The general thinking has been along these lines:
>   smb://              is the top of the tree; list all workgroups
>   smb://server/       server and workgroup names are mutually exclusive,
>                       in a properly configured network so, if <server>#1D
>                       resolves then ennumerate the browse list and if
>                       <server>#20 resolves, then ennumerate the share
>                       list.  More on this below.

Hmmm, OK, thanks for re-iterating ... These seem reasonable ... The
dentries returned will have to indicate the type of object returned:


>   smb://server/share  means list all directories in share on server.
>The advantage of this approach is that it represents the full hierarchy, 
>starting at the workgroup/domain level and drilling down.  It also 
>conforms to people'e expectations of how UNCs behave and how URLs behave.
>The "shoehorning" occurs at the smb://server/ level.  The server, at this
>level, is taken to mean either a browse list server (LMB or backup
>browser) or a file server.  On a "properly configured network", these will
>have mutually exclusive NetBIOS names.
>An improper configuration, as described in rfc1001/1002, occurs when some
>nodes on a local LAN use B mode name resolution and others use M or H mode
>resolution.  In this case it is possible, though unlikely, that both
><server>#1D and <server>#20 will resolve.  That is, there will be a remote
>server with a NetBIOS name that is the same as a workgroup name on the
>local LAN.  This should never happen, since both workgroup#00 and
>server#00 must be registered and these would conflict.  It can only occur
>if there is a client that can see two separate NetBIOS name spaces. 
>In this unlikely and misconfigured case, the simple work-arounds are:
>  a) to list just the shares on <server>#20,
>  b) to list both the browse list and the shares.
>The latter might look like this:
>Listing of FOOBAR:
>    ARG     == smb://arg/
>    FOOBAR  == smb://foobar/
>    GOOB    == smb://goob/
>    C       == smb://foobar/c/
>    D       == smb://foobar/d/
>    CDROM   == smb://foobar/cdrom/
>As shown, it is not difficult to combine the two results.  Due to the
>misconfiguration, the URL smb://foobar/ is overloaded but the results are
>not problematic.  Further, depending upon how you build your library, an 
>application programmer who uses your library could decided to
>  a) return the list as shown,
>  b) return only the share listing (second half of the above),
>  c) return an error explaining that the network is broken.
>(so, okay, I added a third work-around).
>In any case, the above allows us to recreate all of the functionality of 
>Microsoft's Network Neighborhood tool.
>> As an aside, we should conform to RFC2396 and its URI syntax. This leads to
>> a very natural addition of authentication information, as RFC2396 provides
>> for 'userinfo', and provides a natural mechanism for specifying a username
>> and password, although it cautions against passing such information over
>> the wire [see below for comments on security].
>> A more complete form of the syntax, then might be:
>>   smb://[userinfo@][server[:port]][/share[/path[/file]]]
>  smb://[[userinfo@]server[:port][/share[/path][/file]]]

Hmmm, OK ...

>or possibly even
>  smb://[[userinfo@]server[:port]/[share/[path/][file]]]
>...though now I'm splitting hairs.
>> where <userinfo> could be:
>>   [user[:password]]
>> Unless I have misinterpreted RFC2396, my suggestions would be:
>>   [user[;domain][:password]]
>> or
>>   [user[+domain][:password]]
>The consensus on the list was leaning towards:
>  [domain;]user[:password]

Hmmm, OK ...

>  smb://[[[domain;]user[:password]@]server[:port]/[share/[path/][file]]]

OK ...

>> But I am open to suggestions.
>Me too.
>> Finally, however, the issue of workgroups/domains intrudes. These would be
>> most naturally accomodated by supplanting the server down one level, eg:
>>   smb://[userinfo@][workgroup[/server[/share[/path[/file]]]]]
>> but this seems unnatural and the objection can be made that DNS-style
>> domains are not browsed in this way with a normal URI, other mechanisms
>> must be used to obtain the relevant list of domains.
>There is an additional problem.  The server field has special syntax:
>  [[domain;]user[:password]@]server[:port]
>If the server field can be in the first *or* second position following the
>double slashes, then how would one know which field contains the server? 
>By (slightly) overloading the server field, allowing it to indicate either
>a file server or a browse list server (a browser), this problem is solved. 
>> Thus, my preference now is to exclude workgroups/domains from the URI
>> syntax, and to use the URI syntax listed above, but I am prepared to listen
>> to argument.
>...and I am grateful to be able to provide it.  ;)
>As you point out (and I was not aware--but I just checked it with an 
>Ethereal trace and you are correct), the ennumeration of the browse list 
>is an SMB call.  The overloading, then, is quite natural.  Here is the 
>syntax in greater detail:
>   smb://              is the top of the tree; list all workgroups.
>   smb://workgroup/    list the servers within the workgroup.
>   smb://server/       list the shares on the server.
>   smb://server/share  means list all directories in share on server.
>where workgroup means either a workgroup or an ntdomain.
>> I would like to provide additional routines to list workgroups, but this
>> itself may require the provision of authentication information, as the
>> process of listing the workgroups requires a connection (NetBT) to the
>> backup browser, and a TCON to the IPC$ share.  This may require a
>> SessionSetup&X with a valid username and password pair.
>Really?  Interesting.  I thought that ennumerating shares could be done 

They can, but the server might not allow null sessions, or some such ...

>No matter.  If the username and password are required then
>smb://workgroup/ can also expand to smb://[userinfo@]server[:port]/
>Indeed, smb://server/ and smb://workgroup/ are syntactically the same and
>semantically very similar. 
>> An open question at this stage is whether or not this authentication
>> information should be provided using the callback facility already
>> provided, or whether or not they should be passed in via parameters.
>Since you are writing a library, I believe that it makes sense to offer a 
>the tools to allow the application programmer to make that choice.  The 
>URL parser will be able to parse out these fields:
>user, domain, password,
>share, path, file
>It is the application programmer's responsibility to assure that all 
>required information is collected.  (Will port ever be used?  Should be 
>included anyway, I s'pose.)

I left [:port] in because of the use of NetBIOS-less stuff in later NT4
service packs and Win2K.

>> NetBIOS names are becoming increasingly obsolete. They are only required by
>> older Microsoft OSes. Samba does not care about NetBIOS names (but does use
>> them for virtual servers), and NT 4.0 (I believe) and certaily Win2000
>> allows the use of *SMBSERVER as the called name.
>This is not entirely true, as the browsing system is entirely based on
>NetBIOS names.  It is true that DNS names can be used to reference file
>servers, but on any NBT system the use of the DNS for name resolution is a

Yes, this is true. I was thinking of browsing servers and down and
accessing resources ...

>> Thus, <server> should be allowed to be a DNS name, with CALLED names being
>> set to *SMBSERVER, or the first component of the DNS name, or perhaps with
>> each being tried in turn.
>MS tries each in turn, and I agree that this must be done.  IP addresses 
>must also be allowed.  Note, though, that the browse list can only be 
>accessed using the workgroup name (which is a NetBIOS name).
>One further note regarding W2K and SMB native over TCP:
>Under this new system, NetBIOS is not used at all.  Name resolution is 
>DNS based, browsing is completely different, etc.  In one discussion here 
>on the list the idea was put forth to use cifs:// to access SMB native 
>over TCP.  Thus, the smb:// URI would indicate the use of NBT-based SMB, 
>while cifs:// would indicate the use of W2K CIFS protocols.  This 
>distinction makes sense to me and I recommend it.

Hmmm, OK, that is a good idea as well.

>Chris -)-----

Hmmm, you must still have that shoehorn, and it bites :-)

Happy New Year ... it has been 2001 here for a while now.

Richard Sharpe, sharpe at
Samba (Team member,, Ethereal (Team member,
Contributing author, SAMS Teach Yourself Samba in 24 Hours
Author, Special Edition, Using Samba

More information about the samba-technical mailing list