This set of free Unix utilities lets Windows clients access Unix servers.
Tom Yager
Microsoft's various versions of Windows have brought us as close to universal interoperability as we've ever been. The only problem with this otherwise appealing situation is that the key Microsoft file and printer sharing protocol -- Server Message Block, or SMB -- is viewed as proprietary. Ergo, it's commonly believed that SMB is implemented only in Windows.
Although Microsoft and Intel developed SMB, it is not proprietary. Microsoft has provided the SMB specification to The Open Group (formerly X/Open), and there's a lot of vendor support for the Common Internet File System (CIFS) standard, which is an enhancement of SMB. SMB is so well an
d so
widely documented that any programmer with enough patience and skill can implement an SMB server to which any Windows system can connect.
Andrew Tridgell did just that. He developed Samba, a well-respected suite of free software components that implement an SMB server on a Unix system. After you install and configure Samba, every Windows for Workgroups, Windows 95, Windows NT, OS/2, and DOS system will see your Unix host's files and printers. Samba is truly free and truly useful, a combination that's sadly rare in the Windows world.
What's an SMB?
The Server Message Block protocol provides transport-independent file and printer sharing, user authentication, and interprocess communications (IPC) services. You can send SMB packets over every transport that Windows supports natively. Today, that's TCP/IP, Novell's IPX/SPX, and Microsoft's NetBEUI. Transport independence means SMB is media-independent, also: SMB works as well on Ethernet or Token Ring, and it can ship
packets across WAN connections, too.
The figure
"SMB Layer"
shows where SMB fits with other networking components. It's a software layer that spares you the mechanics of accessing network services through a particular protocol. SMB boils network resource-sharing operations down to a simple set of packet exchanges. A client wanting to access a file, print, or IPC resource on a server first queries the server for supported SMB dialects. There are at least 10 dialect variants, but only three or four are in common use. The client chooses a dialect and logs onto the server. The server authenticates the user name and password and returns a user ID (UID). Windows users may recognize this as the "user-level security" model. Older SMB servers provide share-level security. Here, you can assign a password to a resource, but there's no concept of users. Everyone accessing the resource supplies the same password. More recent SMB servers, like those that are implemented in Windows NT and Windows
95, support both share- and user-level security models. User-level security is preferable because you can control a user's access to an entire network from a single host.
The rich SMB protocol includes commands for checking print queues, manipulating files and directories, and locking files and ranges of bytes in files. An application written with SMB alone would sport an impressive array of networking capabilities.
SMB for Unix
There's more than one way to get SMB onto a Unix system. Microsoft got involved in the effort years ago, working with AT&T to develop LAN Manager for Unix (LM/X for short). This ported version of Microsoft's stand-alone network OS became the foundation for many commercial Unix SMB servers. SCO has the most visible commercial solution in its VisionFS product. This SMB server is graced with a point-and-click administrative interface, making it somewhat easier for Windows users to administer Unix SMB resources. VisionFS costs $125 for the first user, and
then $82.50 for each additional user.
Samba, on the other hand, costs you nothing but time. The Samba Web site (see
http://samba.canberra.edu.au/pub/samba
) contains pointers to Samba binaries for every conceivable version of Unix. In keeping with the Gnu tradition, the source code is always available.
When I picked up the binaries, I also grabbed the source code. One set of source files is provided for each new release of Samba. I installed the source on my UnixWare 2.1 system and gave it a quick compile. You build Samba for your flavor of Unix by removing the comments from the appropriate lines in the make file. After starting the make, the compiler spat out volumes of warning messages, but it produced a perfectly usable set of binaries. Samba runs entirely as user processes. There are no de
vice drivers or kernel extensions to manage. This is both boon and bane: It makes for an easy installation, but it leaves Unix applications unable to deal with SMB (clients or servers). It also imposes a performance penalty since Samba must wade through Unix API layers to get the file I/O done. Some commercial implementations address this performance problem. SCO claims a nearly 2-to-1 speed advantage for its VisionFS over the regular Samba.
Several of Samba's key operational parameters are compiled into the binaries. That includes the location of the smb.conf file. The contents of this file tell Samba what to share and how to share it. Getting started with Samba requires only a one-line smb.conf:
[homes] writable = yes
With this, Samba will provide user-level access to every user in your Unix host's /etc/passwd file. The
[homes]
entry is actually a template. Every time a validated user attempts to access the server, Samba creates a resource matching the user's name. The resou
rce serves up the user's home directory.
The documentation that comes with Samba includes exhaustive coverage of smb.conf options. Actually, the
options
are exhaustive. The smb.conf manual page lists more than 120 parameters. The sidebar "Ways to Samba" covers just a few of these many parameters.
Samba is more flexible than Windows NT in some ways, allowing you to tune it to respond differently to requests from specified users and machines. Some parameters like "debug level" affect all Samba sessions. Others are share-specific, letting you restrict access, change the rules for mapping long filenames to short filenames, and set default permissions for new files. A sample smb.conf, loaded with comments, is provided for boilerplate editing. Anything more than casual use of Samba calls for a thorough understanding of the documentation.
Samba Server
The Samba SMB services are provided by a pair of daemons:
smbd
and
nmbd
. The SMB server proper is
smbd
. It listens for client requests on TCP port 139. You can start it at boot time by adding it to rc.local (or its equivalent) or by placing entries in /etc/services and /etc/inetd.conf. In my tests, I developed a preference for starting
smbd
at boot time. That way, clients can see published shares as soon as the Unix host is fully up. Otherwise nothing is visible until the first client makes a request.
If smb.conf is filled in and placed in the proper directory, launching
smbd
with the
-D
option (daemon flag) will get SMB services rolling. It runs silently, but if you specify a debug level or a log file, you'll see messages produced by
smbd
as it runs.
The other daemon,
nmbd
, is a Windows Internet Naming Service (WINS) server for Unix. It listens for WINS queries and feeds them to your Unix host's name-resolution mechanism. You can use a Unix host running
nmbd
as your network's primary WINS server.
Who Needs It?
Samba is
n't for everyone. There's nothing friendly about Samba's administrative interface (what interface?). Even a Unix veteran will find the mishmash of smb.conf parameters daunting. What's more, file and print services are the core of a LAN's essential nature. While I encountered no problems with Samba except performance, I'd be hard-pressed to advise a client to rely on it as a primary server.
Samba is, however, delightfully useful for two purposes. First, it provides an easy, inexpensive means of giving Windows users access to Unix files. Without Samba, users must resort to FTP or costly NFS client software to pull files from a Unix host. With Samba, access from Windows clients is effortless and requires no additional software (except TCP/IP for Windows for Workgroups clients, which is also free).
The second purpose came as a surprise to me. Because you have access to the source code, and because the Samba distribution includes a client test utility (smbclient), you can use the Samba suite to diagnose an
d tune up an SMB network. Higher debug levels produce mountains of messages, some useful, some not, but Samba does not try to conceal anything. After installing and running Samba, you will have more than Windows access to your Unix files. You'll have vital tools for diagnosing and fixing SMB network problems. And you'll have an understanding of Microsoft networks the likes of which can't be delivered by Windows' on-line help.
illustration_link (7 Kbytes)
Samba networking provides transport-independent packet exchanges.
Tom Yager is a senior software developer for TTG in Dallas. He operates a private test lab where
he researches networking, OS, software development, and multimedia technology. You can reach him at
tyager@maxx.net
.
Unix and Windows Dance the Samba
