Samba is the name of an open-source, Linux-based implementation of the Windows networking protocols. In plain English, what this means is simple: Once you have Samba running on a Linux system, the Linux box will appear in Windows users’ Network Neighborhood dialog boxes; likewise, Linux users can access directories on Windows systems. In addition, users can make their printers available to network users, and that’s true whether the printers are attached to Windows or Linux workstations. In short, Samba implements transparent resource sharing on networks in which Linux and Windows systems coexist, and that’s why Samba is an increasingly indispensable resource for Linux users everywhere.

There’s a genuine need for a simple, step-by-step introduction to Samba that includes all the information you need to get a basic, no-frills Samba system working correctly. And that’s just what you’ll find here. This two-part series of Daily Drill Downs walks you through every step needed to configure your network for Samba usage, install and configure the Samba software, and implement reliable, easy-to-use file sharing between Linux and Windows systems.

Just the ticket
Samba is just the ticket for cross-platform networks, as you’ll see, but here’s a point that’s not sufficiently stressed: Samba is well worth investigating even if your network is Microsoft-free. There’s no reason you can’t use Samba as your networking protocol for a Linux-only network. Compared to the native Linux network resource sharing protocols, the Network File System (NFS) and Line Printer Daemon (lpd), Samba is easier to implement, more flexible, less likely to bring down workstations in the event of a network failure, and easier to administer.

If there’s a downside to Samba, it’s the package’s complexity. Configured to the max, Samba can emulate many of the functions of Windows NT Server, but you’ll need a lot of time and NT expertise to implement all of Samba’s capabilities. What’s more, you can’t just install Samba and expect to see your Linux system in the Network Neighborhood window. You have to prepare your Linux and Windows systems properly—and to do so, you’ll need a certain amount of system administration expertise that’s often taken for granted in the Samba documents available online—which is one of the reasons so many people have trouble getting Samba to work.

Creating Linux accounts for Windows users
Let’s get started—but not with Samba. To get Samba working correctly, you need to set up accounts on the Linux server that duplicate the username and password that users supply to the Windows network login dialog box. This is one of the areas that the Internet-accessible documentation doesn’t sufficiently cover; the authors of these documents assume, I suppose, that readers would instantly realize the need to take the steps described in this section. All too often, though, people attempt to configure Samba without taking these steps, and—as a result—Samba won’t work.

Why do you need to set up these accounts? Thank Windows. You see, Windows clients provide no logical way to supply a username when a Windows user makes a Samba connection. Instead, the Windows client sends the username that the user supplied in the Windows Networking login dialog box, which appears at the start of a Windows session. Unless you want to configure all your Samba services to be accessible to guest users—which would create a security hole you could drive a truck through—you need to set up Linux accounts in which the username parallels the one that the Windows client is submitting. While you’re at it, create these accounts with exactly the same password that Windows users supply in the Windows Networking login box. If the user’s Linux password is the same as the same user’s password on the Windows client, users can access their Samba resources without supplying a password.

To set up the user accounts, you can use the useraddutility or your Linux distribution’s user configuration utility (such as linuxconf on Red Hat and Red Hat-derived systems). To set an account for Suzanne with the password yai2bfw, log in as superuser, type useradd-p yai2bfw suzanne, and press [Enter]. By default, this command creates a home directory (here, /usr/suzanne); if the command fails to do this, it means the value CREATE_HOME is turned off in /etc/login.defs. To change this behavior, edit /etc/login.defs. If CREATE_HOME is set to no, change it to yes; if the value doesn’t appear, type CREATE_HOME yes and save the file, and then run useradd again.

Decisions, decisions: Plain text vs. encrypted passwords
Next, you’ll need to consider whether you want to use plain text or encrypted passwords. If you want to use plain text passwords, you’ll have to modify the Windows clients; if you want to use encrypted passwords, you’ll need to modify your Samba installation, as explained in the next section.

Which is best, plain text or encrypted passwords? The short version: Use encrypted passwords. Here’s why: By default, Samba uses plain text passwords, which means that passwords are sent as ordinary text over the network. These passwords could be detected by an intruder and used to gain access to confidential resources. This isn’t a problem in a small network in which all users are reasonably trustworthy. Still, it’s not a bad idea to use encrypted passwords, even on a small network.

As you’ve just learned, the most convenient way to configure Samba passwords involves using exactly the same usernames and passwords for the user’s Linux and Windows accounts. The downside lies in what might happen if people use a packet sniffer to detect user passwords: They’ll get access to all of the user’s accounts—including their Linux accounts—and from there it’s not very difficult to get into the rest of the server. In a large network connected to the Internet, or in a private network in which some workstations are placed in insecure locations, you must use encrypted passwords.

If you decide to use plain text passwords, you’ll need to modify Windows 95 (Service Pack 2 and later), Windows 98, and Windows NT/2000 to disable the default password setting (encrypted passwords only). This involves changing one of the settings in the Windows registry and rebooting the system. Remember, if you opt for plain text passwords, you’ll need to modify all the Windows clients to work with plain text passwords—and you’ll have to remember to do so when somebody brings a new Windows client online.

Setting up name resolution services
To make sure the computers on your network can locate each other, you’ll need to do one of the following:

  • Run a DNS server: The Domain Name System (DNS)defines an automated system that translates between human-readable domain names (such as mycomputer.mydomain.org) and numerical IP addresses (such as 192.168.100.33). It isn’t difficult to set up a DNS server, but the details are beyond the scope of this Daily Drill Down. See the next bulleted item for a low-tech alternative.
  • List the IP addresses, domain names, and aliases of all the computers in your network in /etc/hosts: If you’re setting up a relatively small network (a dozen boxes or less), you can skip DNS and go the manual route. To do so, you’ll need to provide a file on each computer that lists the numerical IP address and domain name of all the computers on the network. On the Linux systems, you do this by adding entries to /etc/hosts (see Table A); the entries use a three-column format beginning with the numerical IP address, the fully qualified domain name (FQDN), and aliases, if any. On the Windows systems, you must create and save a file called C:\Windows\Hosts that contains exactly the same information.

Table A: Sample /etc/hosts and C:\Windows\Hosts files
127.0.0.1 localhost.localdomain localhost
192.168.100.10 lothlorien.mydomain.org lothlorien
192.168.100.33 bag-end.mydomain.org bag-end
192.168.100.34 roadrunner.mydomain.org roadrunner

Configuring the Windows systems
Before proceeding, verify that the Windows systems can “see” each other in the Network Neighborhood window; if not, you’ll need to make sure all the needed networking support is installed, including the Client for Microsoft Networks.
The following instructions assume you’ve installed a networking card and all the necessary networking software (including TCP/IP). If some of the components aren’t available when you perform the following steps, you can install them by clicking the Add button in the Windows Network applet in Control Panel. You’ll need the Windows installation disk—and lots of time to reboot, reboot, and reboot yet again.
Follow these steps to configure the Windows 95/98/NT client to access your Linux network. To begin, go to the first Windows client that you would like to connect to your network. In the Windows Control Panel, double-click Network. You’ll see the Network dialog box. Click the Identification tab, and in the Computer Name box, type a name for this computer (you’re limited to 15 characters).

Next, in the Workgroup box, type a workgroup name, or just use the default (WORKGROUP). In the Computer Description box, type a brief description that identifies the computer’s main user and location (such as Suzanne’s PC– Room 106). Click the Access Control tab and choose Share-Level Access Control. You can’t use user-level control unless you’ve configured Samba to make the master user list available, and that’s beyond the scope of this Daily Drill Down.

Next, click the Configuration tab. Select TCP/IP and click Properties. If there is more than one TCP/IP option, select the one associated with your network card, and then click Properties. In the TCP/IP dialog box, click the IP Address tab, if necessary. Do one of the following:

  • If your LAN is running a DHCP server, select Obtain An IP Address Automatically.
  • Click Specify An IP address. In the IP Address box, type a static IP address for this system.

Chances are you’ve set up your network using one of the Class C network numbers that are available for private network use, such as networks using addresses beginning with 192.168.1.0. You’ll also need to supply the subnet mask (for a Class C network, it’s 255.255.255.0).

Now, click the WINS Resolution tab, and make sure WINS Resolution is disabled. WINS is a proprietary Windows alternative to the Internet-standard DNS. Since you’re running Samba with TCP/IP, which uses DNS, you don’t need WINS.

At this point, click the Gateway tab. Here, you enter the IP address of the computer or router that provides access to the public Internet. In the New Gateway box, type the IP address of the computer or router that’s used to link your network to the Internet, and click Add. Be sure to enter exactly the same gateway address on all the Windows systems. If your network isn’t connected to the Internet, leave this box blank.

Now, click the DNS Configuration tab. Select Enable DNS, and in the Host box, type a host name that uniquely identifies this computer. In the Domain box, type your network’s domain name. If you’ve set up a private internal network, you can use any domain name you like (such as mydomain.org), but make sure you use the same domain name for all the computers on your network.

In the DNS Server Search Order area, do one of the following:

  • If you’ve set up a DNS server on your LAN, type the primary and secondary DNS addresses here.
  • If your LAN lacks a DNS server but is connected to the Internet, type your ISP’s primary and secondary DNS addresses here.
  • If your network isn’t connected to the Internet and you’re not running DNS, give the Samba server’s address as the primary DNS server. Since this machine isn’t running a server, Windows won’t get the information it needs, but this failure will force it to look at the C:\Windows\Hosts file you created in the previous section.

Click the Bindings tab and select Client For Microsoft Networks. If you would like to make this system’s resources available to other workstations on the network, including Linux workstations running Samba, select File And Printer Sharing.

Next, click the NetBIOS tab and make sure NetBIOS is enabled. If it isn’t, there’s something wrong with the TCP/IP installation; you should repeat the installation and start over.

Finally, click OK. If Windows needed any additional software, you’ll be in for a round of rebooting before you can take the next step.

On the Configuration tab of the Network dialog box, select Client For Microsoft Networks and click Properties. Deselect Log On To Windows NT Domain, if necessary. In the Network Logon area, select Quick Logon or Logon And Restore Network Connections; either option is acceptable. Quick Logon doesn’t restore network drive mapping, in which a user’s network drive is mapped to a local system drive letter. Click OK to confirm the Client For Microsoft Networks settings.

Next, on the Configuration tab of the Network dialog box, click the File And Print Sharing button. In the File And Print Sharing dialog box, specify the access options that the user wants (the user can share files, local printers, or both). Click OK to confirm the file and print sharing options. Then, click OK to confirm the Windows networking settings. You’ll need to restart your system. Repeat the above steps for the rest of the Windows boxes on your network, if any.

Your next step: Installing and configuring Samba
Congratulations! The steps you’ve followed in this Daily Drill Down lay the foundation for smooth, trouble-free networking with Samba. In part 2 of this series, you’ll learn how to install and configure Samba so that your Linux and Windows users can exchange files effortlessly.

Bryan Pfaffenberger, a UNIX user since 1985, is a University of Virginia professor, an author, and a passionate advocate of Linux and open source software. A Linux Journal columnist, his recent Linux-related books include Linux Clearly Explained (Morgan-Kaufmann) and Mastering Gnome (Sybex; in press). His hobbies include messing around with his home LAN and sailing the southern Chesapeake Bay. He lives in Charlottesville, VA. If you’d like to contact Bryan, send him an e-mail.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.