The Strength of Teamwork: Integrating NT and Linux through Samba

May 1999

Intrigued by the attention that Linux is receiving lately, but not sure how it might fit into your enterprise? With a suite called Samba that ships with every version of Linux, you can make Linux a useful part of your Microsoft network.

As you know, Linux is generating a lot of interest lately. What you might find surprising, though, is that it’s being adopted in great numbers even by IS organizations that have standardized on Windows NT. Two of the reasons: Linux is stable and amazingly cost-effective (especially when you compare it to the licensing fees for NT), and Linux can integrate into any existing network infrastructure—be it Microsoft, Novell, or Unix.

Samba is the technology that allows Linux to fit into a Microsoft file and print sharing network. In this article, I’m going to explain some basics of Samba—how it fits into the Linux world, how it works, how it differs from NT, and how it integrates with NT. After reading this article, you may consider implementing a test project in your own company to take advantage of each environment as appropriate.

What is Samba?

Samba is the name of a suite of server and client programs originally developed by Andrew Tridgell at the Australian National University at the same time as Microsoft’s initial release of Windows NT, version 3.1. Since then, like NT itself, Samba has undergone several years of improvement and development; it’s now used by many organizations worldwide as a scalable and robust file and print server for Windows clients, providing an alternative to NT. In much the same way as the Linux kernel itself, Samba is now maintained and developed by a worldwide team of programmers known as the Samba Team (of which I’m a member). Although most commonly associated with Linux (all Linux distributions ship with a version of Samba as standard), Samba is based on the POSIX standard APIs (see “What’s POSIX?”); as such, it’s very portable and runs on all known Unix variants. Versions of Samba also have been ported to Novell NetWare and HP MPE/3000 (Hewlett-Packard’s proprietary minicomputer operating system).

Samba provides a full implementation of Microsoft’s CIFS file sharing standard that Windows NT networking is based on. (CIFS stands for Common Internet File System, formerly known as SMB, Server Message Block.)

SMB/CIFS, in turn, is currently packaged inside NetBIOS packets. NetBIOS is a transport-independent specification (in fact, it was actually originally an API standard, not a protocol) that may be packaged inside other transport protocols such as IPX, NetBEUI, or TCP/IP (see Figure 1). An NT server supports clients that use any of these protocols, whereas Samba only supports clients that use TCP/IP, not IPX or NetBEUI. This comes from Samba’s Unix heritage and actually works well, since TCP/IP is now a widely accepted standard and the declared standard protocol in all Windows systems. (If you must support protocols like NetBEUI or IPX, you can use NT or NetWare, respectively. Samba is not the answer.

How Does Samba Work?

With Windows NT, the NT kernel contains the services offered by NT, along with the NetBIOS naming mechanisms. In contrast, Samba runs two separate user-mode services (known in Unix terminology as “daemons”) in order to provide NetBIOS naming, browsing, and file and print services.

The first user-mode service, or daemon, in Samba is the “nmbd” (NetBIOS naming daemon). Nmbd, the simpler of the two daemons, provides basic NetBIOS naming services (name registration on both broadcast LANs and to WINS servers), as well as the browsing service that allows Samba servers to appear in Windows’ Network Neighborhood as a resource. NT has a separate “browser” service that provides this functionality. If configured to do so, nmbd can also act as a WINS server, although it can’t yet replicate with Microsoft WINS servers (Microsoft uses a proprietary, undocumented protocol that runs over DCE/RPC for this purpose).

But even without replication services, the reliability of Samba on a Linux/Unix machine has allowed some organizations to use the nmbd daemon as their primary and only WINS server. Normally, each Samba server has one copy of nmbd running. Nmbd can also provide a gateway to the Internet standard DNS (Domain Name Service). It can allow clients that use only NetBIOS naming services to have nmbd look up names in the DNS on their behalf; the NetBIOS name requests are proxied into DNS lookups transparently.

The NetBIOS over TCP/IP protocol that nmbd and NT both use, along with the WINS server name registration and release protocol, are documented in the Internet Request for Comment documents RFC1001 and RFC1002 (see “Additional Information” for details). The NetBIOS over TCP/IP protocol described in these RFCs and the browsing protocols (described in Microsoft documents) use UDP port 137 for NetBIOS name service and UDP port 138 for the mailslots that carry the browsing announce messages. If you want to know exactly how NetBIOS name registration and name lookup work, these RFCs are essential reading; they specify the format of the packets on the wire.

Figure 2. Smbd uses a Unix SystemV shared memory area arbitrated with standard Unix SystemV  semaphores to communicate between each smbd process.

The browsing protocols that implement the Network Neighborhood in Windows are Microsoft inventions rather than Internet standards, but Microsoft has generously documented these protocols as part of its ongoing efforts to standardize the SMB/CIFS protocol suite. These documents are designed to help those implementing a protocol, not just the protocol’s users.

Also, the nmbd source code is available as part of Samba for programmers who want to study one particular implementation of the NetBIOS naming protocols. (Earlier versions of nmbd in Samba consisted of an implementation of the browsing protocols implemented by actually watching packets on the wire between Microsoft systems, along with some internal Microsoft documentation that Microsoft made available to the Samba development team.) Now that we have complete documentation for the SMB/CIFS browsing protocols, the Samba implementation is robust and full-featured, and interoperates perfectly with Microsoft implementations, allowing Linux and Unix servers to participate in Microsoft’s Network Neighborhood concept.

The second daemon is “smbd” (SMB daemon). Smbd implements the heart of the SMB/CIFS protocol that provides the file and print sharing services offered by Samba. When run over TCP/IP, this protocol uses port 139. It’s a complicated program comprising close to 80,000 lines of code in its current release, and like most complex programs it grows all the time.

Smbd differs from Microsoft implementations of SMB/CIFS in that it’s a user-mode program rather than a kernel mode service. It’s more robust than NT in the face of programming errors. A programming error causes the smbd daemon to fail, rather than the entire machine. Another difference: smbd uses a model in which each connecting client invokes a separate instance of smbd to service its requests. (The NT implementation, in contrast, consists of a single multi-threaded service.) This adds another level of robustness to the implementation, since a failure of one smbd terminates file and print services to only one client, allowing other users to continue to use the server.

Using multiple processes in this way may seem less scalable than the multi-threaded approach, but Linux is quite efficient at running multiple processes at once. As a result, this multiple-process approach is very effective in creating a high-performance file server. This design also allows Samba to take advantage of the better multi-processor scalability available in Linux and Unix (which currently scale beyond the four-way systems that standard Windows NT can run on).

Samba and Speed

Running an SMB/CIFS server in kernel mode should be more efficient than user mode, since no transition is needed between kernel and user mode in order to serve out data to clients. Thus, as would be expected, NT performs better than Samba as a file server for low numbers of clients. As the client load rises, however, even though Samba is implemented in user mode, the better scalability of Linux and Unix-based systems begins to show. A recent Ziff-Davis NetBench benchmark run by Sm@rt Reseller magazine showed Samba on Linux out-performing NT on identical Intel-based hardware by a factor of two once the client load was greater than 12 simultaneous clients.

In fact, the two fastest published NetBench throughput numbers (232 Mbits/second and 193 Mbits/second) are currently held by Samba running on Unix hardware, a Sun E450 of unknown configuration running Solaris, and an Origin 200 MIPS system with four processors running IRIX from Silicon Graphics. (As a disclaimer, I must point out that I work for Silicon Graphics, which sells and commercially supports a version of Samba for its proprietary Unix.) In fact, Samba can go much faster than this, since Unix systems scale to far more than four-processor systems and the design of multiple processes communicating via IPC (inter-process communication) has no inherent bottlenecks. (Indeed, internal benchmarks I’ve conducted at Silicon Graphics have provided throughput numbers significantly greater than these published numbers.)

Smbd uses a Unix SystemV shared memory area (a standard Unix-shared memory API also used by Oracle databases on Unix) arbitrated with SystemV semaphores (the standard Unix semaphore API) to communicate between each smbd process. As the smbd processes need to communicate only when accessing shared files, users can work in their own file spaces without any contention for shared memory access. This leads to a fast and scalable file server.

Emulating Windows File Services on Linux

One of the more interesting challenges for smbd is providing Windows semantics for file serving on a Unix or Linux system. The most obvious difference is case-sensitivity. By default, NT applications treat file names as case-insensitive (unless they’re running under the POSIX subsystem). Unix and Linux systems applications such as smbd, by contrast, are case-sensitive.

Some Win32 applications, such as the Windows 95 Explorer, present file names with a leading capital letter. Smbd, therefore, must be able to provide a case-insensitive view of the file system. A further twist is that Windows and Linux are available in many different languages, so smbd must be able to cope with the case-insensitivity in a variety of Windows codepages. NT provides this capability by using UNICODE. Smbd can be set to load a specific Windows codepage at runtime to provide the case insensitivity needed. An internal cache of recently case-mapped names is used by smbd in order to provide a speedy mapping from the case-insensitive Windows name to the case-sensitive Unix one.

Samba also handles differences in file access between Linux and Windows. Win32, Win16, and DOS applications have the concept of a file “deny” mode. This allows one application to specify what other types of access other applications may have to an open file. Linux’ POSIX API has no such concept. Samba provides this to Windows clients by using the shared memory area described previously to store Windows deny modes for open files, thus providing the full Windows semantics needed.

File locking is another area of difference. Unix has been criticized for its file locking due to the problems of using POSIX file locking over NFS (Sun’s Network File System is the standard UNIX-to-UNIX file sharing protocol and historically has had very poor locking support). However, the POSIX file-locking API provided by Linux is actually far more flexible than the Win32 one. Byte range file locks may be split and merged, and read-only locks may be upgraded to read-write locks or vice versa. This flexibility makes it somewhat difficult for smbd to emulate the more restrictive Win32 file locking (Win32 offers no overlapping ranges, no range splitting or merging, and no upgrade or downgrade) without extra checks from user level code. However, the Windows client redirector comes to the aid of smbd here, in that invalid file lock requests between applications on a single client are handled locally by the client redirector as an optimization and never sent over the wire to the SMB/CIFS server.

Just an Introduction

In this article, I’ve only been able to scratch the surface of the complex topic of NT/Linux compatibility. Suffice it to say that smbd provides “close-enough” Windows file access semantics to Windows clients, without ever compromising the Linux security model or giving unpleasant surprises to Linux applications. The Samba team considers any report of a Windows application failing to run against a Samba server as a bug, and fixes such problems as a priority. Smbd implements such advanced SMB/CIFS protocol features such as “opportunistic locking,” oplocks for short, which allow Windows clients to cache files locally that are in use by a single client only.

Additionally, smbd provides a full implementation of the Windows printing protocol—a complex topic in itself. This is so effective that Cisco Systems, for example, uses Linux servers running Samba for most of its Windows client printing requirements. Since the source code for these services is provided, these sites can add custom features not provided in the main Samba code base. For instance, some sites have used this to add such things as advanced auditing features or application usage metering.

Configuring Samba

Linux, like most other Unix systems (AIX is a notable exception) doesn’t use a registry database to store its configuration information; these details are stored in a standard ASCII flat file, similar to the .INI files that Microsoft used in Windows 3.1. This can be a strength, since such files are easy to edit and fix with a standard text editor, even over a restricted bandwidth remote link. However, to administrators used to graphical tools such as those in NT, editing such files with a text editor seems primitive. Most versions of Linux do ship with graphical administration tools (LinuxConf ships with all new versions of Red Hat Linux, for example), but these tools aren’t yet well integrated with all services.

For Unix systems that don’t ship with GUI administration tools, Samba has a browser-based administration tool called “SWAT” (Samba Web Admin Tool, imaginatively enough). SWAT is installed as part of a standard Samba rpm install. (rpm stands for Red Hat package manager, comparable to Install Shield. Rpm has been adopted as a standard in the Linux world.) SWAT allows the administrator (or “root,” as this user is known in Linux) to configure Samba remotely using any browser. SWAT allows an administrator to add and delete Samba users or change passwords (even remotely to an NT PDC).

Try It Out!

I hope I’ve piqued your interest in exploring what Samba, in conjunction with Linux or another flavor of Unix, may offer your NT-centric organization. Remember, this has by necessity been a quick tour of Samba and a few of its features. If you want to know more, check the Web sites I list in “Additional Information” to help with your pilot project. Good luck!

Jeremy Allison is a lead developer on the Samba Team, a group of programmers developing an Open Source Windows-compatible file and print server product for Unix systems. He has a wide background in Unix and Windows NT systems and has ported much Unix software to NT, including Sun’s ONC/RPC networking libraries, the Vantive Customer support system and the Kerberos 5 authentication system. He also authored the NT utility PWDUMP and seclib, a Win32 C++ library for manipulating NT security descriptors. Jeremy has been working on Samba since its origin in 1993 and is currently adding support into Samba for the Windows NT domain controller protocols. He works for Silicon Graphics, which funds his work on Samba. Reach him at jra@samba.org. 

1999 QuickStart Technologies, Inc., all rights reserved.