Learn Linux, 302 (Mixed environments)
Learn the concepts behind file and print sharing in a mixed environment
This content is part # of # in the series: Learn Linux, 302 (Mixed environments)
This content is part of the series:Learn Linux, 302 (Mixed environments)
Stay tuned for additional content in this series.
In this article, learn about these concepts:
- Server Message Block (SMB)/Common Internet File System (CIFS)
- File sharing
- Print service
This article helps you prepare for Objective 310.1 in Topic 310 of the LPI's Mixed Environment speciality exam (302). The objective has a weight of 1.
To get the most from the articles in this series, you should have an advanced knowledge of Linux and a working Linux system on which you can practice the commands covered in this article. In addition, you should have access to a Windows environment that you can use to test file and print access.
File and print sharing
The goal of file and print sharing is to let computers use disks and printers on other computers as if they were locally attached. This functionality allows more people to use the same expensive resources and to access those resources from anywhere. As central resources, files and printers can be more tightly controlled and audited, should that be required.
Desirable attributes of a file and print sharing solution are:
- The solution should be network agnostic—that is, indifferent to the type of network (Ethernet, token ring) on which it is run.
- Applications should not need to know whether they are accessing a file on a local disk or a remote one or whether they are printing to an attached or remote printer.
- There should be some way to mediate simultaneous requests for the same resource, such as two people trying to print to a printer at the same time.
- The solution should implement some type of authentication system to understand who is asking for a resource and an authorization system to decide whether the access should be granted.
There are several different ways to share files and printers. Many UNIX utilities, such as the Berkeley printing system, have been network aware since the early 1980s. Sun Microsystems introduced the Network File System (NFS) in 1984, which let UNIX computers mount file systems over the network. IBM and Microsoft came up with the SMB protocol to perform many network-sharing tasks, including sharing files and printers. File and print sharing can be performed by dedicated servers, by individual workstations, or by a combination of both.
Even if a file is being shared from a workstation, the device that has the disk resource to share is called the server, and the devices accessing the disk are called clients. The server is said to either export the file system (in UNIX terms) or to share the disk or directory (in Windows terms). Clients then mount the file system as a local disk or connect to the share.
The nature of the sharing relationship can be temporary or long term. A client can connect to the server to get a few files and then disconnect, or a client can have the connection open until it reboots. The client can treat the remote file system as a local disk or part of the local file system, or it can choose to access the resource at the application layer, much like a File Transfer Protocol (FTP) client does.
Another feature related to file sharing is the concept of browsing. Browsing allows a client to find a server on the network, usually from a dynamically populated list.
A printer may not be attached directly to a server, so multiple levels of sharing could be occurring. When multiple clients have the same printer configured, they generally do so through a service called a spooler. The job of the spooler is to manage the list of print jobs, otherwise known as the print queue. As multiple people submit print jobs, the spooler stores the job to disk. Once the printer is unused, the spooler can send the job to the printer without fear of contention from other print jobs.
Even though printers can be attached to the network, a server is usually used as the spooler, which in turn prints to the printer over the network. This is done for three reasons: first, the server is likely to have a more robust and larger spooling area than the printer. Second, the server can take care of access control. And third, the server can distribute printer drivers, should they be needed.
SMB and CIFS
SMB is a protocol, not an implementation. The protocol has been implemented in many different operating systems, from Windows to UNIX and even to mainframe environments.
SMB got its start with IBM and was implemented by Microsoft as the company began to network its products in the early 1990s. At that time, SMB needed a separate product, such as LAN Manager or Windows for Workgroups, but file sharing was eventually made a part of the regular operating system with Microsoft Windows NT.
Microsoft continued to adapt SMB for the new features being introduced in its operating systems and eventually came out with a version it called CIFS, which it proposed for standardization with the Internet Engineering Task Force.
Around the same time, a Ph.D. student from Australia, Andrew Tridgell, started reverse-engineering a mainframe implementation of SMB and began work on what would eventually be an open source implementation of SMB and Microsoft protocols called Samba. The project started as a way to move files and has blossomed into a full client and server implementation, including the ability to act as a Windows domain controller and soon, an Active Directory server.
SMB vs. CIFS
CIFS is technically a dialect of SMB. The SMB protocol has been
modified over the years, so it is necessary for a client and a server to
negotiate the dialect of the protocol to be spoken. CIFS refers to the NT
LAN Manager (NTLM) series of extensions. Strangely, the protocol does not
use the string
CIFS to identify itself;
NT LM 0.12 is used.
For all practical purposes, you can use the terms SMB and CIFS interchangeably, as the CIFS dialect of SMB is the one now in use. Incidentally, CIFS is pronounced "siffs" rather than being spelled out like SMB.
SMB protocol overview
As a client-server protocol, the client makes contact with the server. SMB started out requiring an application programming interface (API) layer called Network Basic Input/Output System (NetBIOS). This API provided several services that SMB used as well as several services relating to name resolution and network browsing. When used in conjunction with NetBIOS, SMB could run on top of:
- Raw Ethernet, in which case SMB used NetBIOS Frames, often called NetBEUI
- Novell Internetwork Packet Exchange (IPX)/Sequenced Packet Exchange(SPX), in which case SMB used NetBIOS over IPX/SPX (NBX)
- TCP/IP, in which case SMB used NetBIOS over TCP/IP (NBT)
NetBIOS provides three key services to a Microsoft network:
- Name services for finding hosts on the network
- Session services for the reliable communication and transfers between a client and a server
- Datagram distribution services for small messages and network broadcasts
SMB therefore made the most use of session services but would rely on the other two services for support, such as using name services to find the address of the server.
Eventually, TCP/IP's dominance and Microsoft's move to rely on Domain Name System (DNS) for name resolution led to SMB being run directly on top of TCP/IP in a manner called direct hosting. Whereas NBT ran on TCP and User Datagram Protocol (UDP) ports 137-139, direct hosting uses TCP and UDP port 445.
SMB in the OSI stack
Figure 1 shows the Open Systems Interconnection (OSI) model, which is used to explain the interactions between network protocols. The OSI model describes the features necessary to have an application work over a network and breaks down the features into a series of layers. Each layer uses the services provided by the layers below it and provides services to the layers above it.
Figure 1. The OSI model
Layers 1 and 2 are the physical and data link layers, respectively, fulfilled by the Ethernet network. These two layers get small pieces of information from one network hop to another. TCP and IP take up the next two layers and are the transport and network layer, respectively. The network layer is responsible for end-to-end connectivity, while the transport layer allows for larger messages to be built out of smaller messages and multiple services to exist on the same server. Each layer uses the layers beneath it, so the network layer does not need to worry about how each hop on the network uses the physical and data link layers and so forth.
On a network using NetBIOS, the session layer is used. The session layer provides the session services described earlier. SMB operates at the application layer (the presentation layer is not used here), which means that it takes advantage of all the features that the lower layers provide.
On a network not using NetBIOS, the session layer is simply left out. TCP is already capable of handling most of the session services, and the name services are handled by DNS.
Uniform Naming Convention
On the Internet, you are familiar with universal resource identifiers
(URIs) such as
URI identifies where you can find a particular document or other content.
In the example URI, the
http refers to the
scheme—in this case, the document is to be retrieved using HTTP.
The name of the host to ask for the content is
/developerworks refers to the resource on that
host to ask for.
Similarly, Uniform Naming Convention (UNC) paths identify Windows network
resources. A UNC path looks like
\\shorty\documents\public\photo.jpg. The UNC
path starts with two backslashes (
by the name of the server, another backslash, and the name of the shared
folder. After that is a path relative to the shared folder that specifies
a path to the resource.
UNC paths differ from URIs in a few ways:
- There is no need for a scheme. SMB is used.
- Backslashes are used instead of forward slashes
/); although in some cases, forward slashes can be used.
- The shared folder looks like part of the resource name but refers to the name of the file share on the server and need not exist on the server's file system.
Samba bills itself as the "standard Windows interoperability suite of programs for Linux and UNIX." Although Linux and other UNIX flavors have come up with other ways of mounting SMB file shares, none comes close to matching Samba's functionality as both a client and a server and further, as an integration point into a Windows network.
Samba consists of several daemons meant to run in the background and provide services as well as several command-line tools used to interact with Windows or Samba services. Both the daemons and the tools will be thoroughly investigated over the course of this article series, but some of the more notable binaries are:
- smbd. This daemon acts as the SMB file and print server.
- nmbd. This daemon provides the NetBIOS naming services.
- mount.cifs. This utility mounts a remote SMB file system onto the local UNIX file system, much like a local disk or NFS share.
- smblient. This utility provides command-line access to SMB resources, much like an FTP client. It can also list shares on a remote server and browse the network.
- smb.conf. This is not a utility but rather the configuration file for all the tools and therefore worth mentioning in the same context as the other binaries.
Samba, like other open source software, can be compiled from the source code or downloaded as part of your distribution. It is managed through system-initialization scripts and configuration files.
The next exam objective, 310.2, discusses the roles that the different Samba daemons play and the different security modes under which these daemons operate.
- Review the entire LPI exam prep series on developerWorks to learn Linux fundamentals and prepare for systems administrator certification based on LPI exam objectives prior to April 2009.
- Read more details about SMB on Wikipedia.
- Read Implementing CIFS, the free online version of an extremely detailed book on the CIFS protocol by Christopher R. Hertel.
- Direct hosting of SMB over TCP/IP explains direct SMB hosting in more detail and gives advice on how to configure it from the Windows perspective.
- In the developerWorks Linux zone, find hundreds of how-to articles and tutorials, as well as downloads, discussion forums, and a wealth of other resources for Linux developers and administrators.
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment.
- Follow developerWorks on Twitter, or subscribe to a feed of Linux tweets on developerWorks.