Years ago, Microsoft and IBM came up with the SMB (Server Message Block) protocol to compete with Novell's IPX-based file and print sharing. Though it's hard to believe now, there was a time when pretty much all corporate networks were running IPX and Novell Netware servers. The relatively few home networks were running IPX, while military and research networks used TCP/IP. SMB was the first protocol to run over multiple network protocols: TCP/IP, NetBEUI, and IPX/SPX. In other words, an SMB server could replace a Novell server without need of changing the rest of the network infrastructure. The promise was that of an open system—one where any server that could speak SMB could serve any SMB-speaking clients, over any of several network protocols. Bear in mind, though, that this promise would go pretty much unfulfilled for quite some time. The only servers that spoke SMB were OS/2 and MS Windows. When OS/2 failed to gather much market share, Joe User was left with an "open" solution that was available from only one vendor.
Note, as well, that this "open" solution (which, to the best of my knowledge, was never marketed as such) had nothing for Unix users. SMB was strictly PC stuff, and PC stuff was shunned by Unix users as being too dinky, too underpowered, and incapable of running a "real OS." As MS Windows quickly became a de facto standard, so did the SMB protocol. Users began using MS Windows' built-in (SMB) file and print sharing to offer new levels of data sharing. When Windows 95 came along, it got even easier. Using the standard GUI approach, anyone with a mouse and a finger to click it could set up file shares, shared printers, password-protected shares, and even drive mappings. Gone was the need for the arcane batch files required by earlier versions of Windows and by contemporary versions of Novell Netware. So today, we are left with a single great divide: the Microsoft, PC, SMB world, on the one hand, and the Unix, big iron, NFS world on the other. So what are the differences? There are quite a few, and we'll start by looking at naming.
Every machine on a Windows network is identified by a NetBIOS name, which is similar to a Linux hostname. NetBIOS names are at most 15 characters and are case-insensitive. Unlike hostnames, they also contain a resource-type byte, which describes the role or roles of the machine on the network. Multiple names and multiple types can be associated with a single physical machine. As an example, here is a listing of the NetBIOS names associated with the primary Linux box on my home network:
HOMER <00> - B
HOMER <03> - B
HOMER <20> - B
__MSBROWSE__ <01> - B
WORKGROUP <00> - B
WORKGROUP <1d> - B
WORKGROUP <1e> - B
The NetBIOS names are on the left, and the hex value of the resource-type byte is shown in angle brackets. Type <00> means a standard workstation, type <03> means a WinPopup service, and type <20> means a file and print server. So my computer HOMER advertises itself as a workstation and a file server and as capable of receiving WinPopup messages.
The other name, __MSBROWSE__, is Microsoft's way of identifying a domain master browser. A master browser is responsible for periodically checking what machines and shares are available on a network and caching that information. Then when another computer wants to "explore" the network, it needs to ask only the master browser what is available instead of doing a network-intensive broadcast request.
What about the WORKGROUP entries? These describe the workgroups, or domains, to which my machine belongs. I only have one workgroup on my network, WORKGROUP, and HOMER advertises itself as a workstation (type 00) in that domain. The other two lines refer to the machine's role as a master browser.
Every machine that understands SMB advertises itself as providing certain services. These services do not have to be limited to file sharing; in a typical Windows network they include print sharing, remote administration capabilities, popup messaging, and other features. Every service has a name unique to the machine where it is offered. On a network, a service is identified with the following syntax:
\\machine-name\service-name
This notation is called the universal naming convention (though it's hardly universal!). Since backslashes are shell metacharacters under Linux, most of the Samba utilities will conveniently accept UNCs using forward slashes and automatically convert them to backslashes as necessary.
On a Windows file server, any directory can be defined as the root of a file-sharing service. There is no dependence on the physical layout of the file system, and the directory being shared can itself be connected to a file share on a third machine. All subdirectories of the file-sharing root are accessible through a share. Access to a share is controlled both by the permissions on the share and by the permission on the underlying file system, if applicable.
A Windows print share allows network access to a locally connected printer. The service does not provide drivers for a printer, only the ability to send a pre formatted print job from a remote machine. As a result, if you intend to use a Windows printer from a Linux machine, you must have Linux drivers available to generate the appropriate control language for the printer. The Ghostscript package is included with most Linux distributions, and it provides a wide variety of filters to convert PostScript to proprietary printer-control languages. A list of directly supported printers and third-party-supported printers are available at the Ghostscript Web site.
On my machine KEARNEY, for example, the following services are available. We'll see how to list these services in the next section.
\\KEARNEY\CDROM maps to E:\
\\KEARNEY\ZIPLIB maps to D:Ziplib\
\\KEARNEY\CANON print service for a Canon BJ-200
\\KEARNEY\IPC$ special OS service
Source of information : Addison Wesley - Multitool Linux - Practical Uses for Open Source Software
