Many Linux projects have turned the tides of the computing industry. Among them are the Beowulf clustering project, Apache, “Big Blue” support, Linux Care, and Red Hat Linux. However, one project took those tides and forced them to straddle the fence of Windows and Linux, resulting in incredible functionality for both sides of the OS war. The dissonant split between UNIX variants and Windows has created a rift in the computing industry that has left IT professionals in the middle of the battleground, struggling for a way to appease their own technical savvy and keep corporate headquarters happy.

Ladies and gentlemen, I give you Samba!

From the Samba man page:

“The Samba software suite is a collection of programs that implements the Server Message Block (commonly abbreviated as SMB) protocol for UNIX systems. This protocol is sometimes also referred to as the Common Internet File System (CIFS), LanManager or NetBIOS protocol.”

Samba is quite a brilliant application that works seamlessly in the background, allowing the Windows environment to navigate the Linux directory hierarchy and use the power of Linux as a file and print server. In this Daily Drill Down, I’ll discuss how you can take advantage of Samba.

Let’s answer a few questions first.

Samba is based on SMB technology. What is SMB?

SMB, in a nutshell, is the protocol by which a lot of PC-related machines share files, printers, and other information, such as lists of available files and printers. Operating systems that support this sharing natively include Windows NT, OS/2, and Linux.

Why use Samba?
Simply put, Samba is a means by which you can integrate Linux into a Windows environment. Samba is capable of providing:

  • Windows NT and LAN Manager-style file and print services to SMB clients, such as Windows 95, Warp Server, SMBFs, and others
  • a NetBIOS (rfc1001/1002) name server, which, among other things, gives browsing support (Samba can be the master browser on your LAN, if you wish)
  • an FTP-like SMB client, which allows you to access PC resources (disks and printers) from UNIX, NetWare, and other operating systems
  • a tar extension to the client for backing up PCs
  • a limited command-line tool that supports some of the NT administrative functionality, which can be used on Samba, NT Workstation, and NT Server

The team of developers who work with Samba consists of about 20 people from around the globe—all focused on the ongoing development of the Samba suite.

Isn’t Samba difficult to install and configure?

No. If you can administer a network, you can install and configure Samba and many of its protocols quickly, efficiently, and without harm to your network—covertly if you will. (Insert quiet yet maniacal laughter.)

Thus it begins
I’ll make a couple of assumptions here. The first assumption is that you have a working network, and the second is that both your Windows (for sake of ease, we’re going to work only with Windows 9x) clients and your Linux clients are working properly on this network. I’ll also assume that you plan to use Linux as your server and your Windows machines as your clients.

So, with the ability to Telnet and FTP into your Linux machine (using host names that were configured in the /etc/hosts file), you’re ready to begin configuring the Linux side of Samba.

Server configuration
The first step in configuring the Linux side of Samba is to create a new account (smbusers) and a new group (smb). The account smbusers won’t be logged in to, so it’s best to disable login. The easiest way to create these accounts is through linuxconf as root. Once you’ve created them, you’ll need to change some permissions and ownerships for the accounts.

Make sure that you have a directory called /home/public. If you don’t, create it. (Don’t worry, I’ll wait.) In case you’re not sure how, type
mkdir /home/public

and you’ll be fine.

Now that you have the directory /home/public, let’s make some changes to permissions and ownerships. The first change is to make sure that /home/public is owned by smbuser. In addition, it should belong to the smb group, and the permissions should be set (as root) like so:
chown smbusers:smb /home/public

and then
chmod 2777 /home/public

Now, any file that’s created in /home/public is owned by the smb group.

The primary and most difficult configuration for Samba involves the smb.conf file, which is located in the /etc directory in Linux. At first glance, this file is rather cumbersome, and it’s often completely rewritten.

Out of the box, smb.conf looks somewhat like this:
#the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options (perhaps too
# many!), most of which are not shown in this example
# Any line which starts with a ; (semi-colon) or a # (hash)
# is a comment and is ignored. In this example we will use a #
# for commentry and a ; for parts of the config file that you
# may wish to enable
# NOTE: Whenever you modify this file you should run the command #”testparm”
# to check that you have not many any basic syntactic errors.
#==============Global Settings==================
# connections to machines which are on your local network. The
# following example restricts access to two C class networks and
# the “loopback” interface. For more examples of the syntax see
# the smb.conf man page
; hosts allow = 192.168.1. 192.168.2. 127.
# if you want to automatically load your printer list rather
# than setting them up individually then you’ll need this
printcap name = /etc/printcap
# It should not be necessary to spell out the print system type unless
# yours is non-standard. Currently supported print systems include:
# bsd, sysv, plp, lprng, aix, hpux, qnx
; printing = bsd
# Uncomment this if you want a guest account, you must add this to /etc/passwd
# otherwise the user “nobody” is used
; guest account = GUEST
# this tells Samba to use a separate log file for each machine
# that connects
log filep = /var/log/Samba/log.%m
# Put a capping on the size of the log files (in Kb).
# security_level.txt for details.
# Use password server option only with security = server
; password server = <NT-Server-Name>
# Password Level allows matching of _n_ characters of the password for
# all combinations of upper and lower case.
; password level = 8
; username level = 8
# You may wish to use password encryption. Please read
# ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba documentation.
# Do not enable this option unless you have read those documents
; encrypt passwords = yes
; smb passwd file = /etc/smbpasswd
# The following are needed to allow password changing from Windows to
# update the Linux sytsem password also.
# NOTE: Use these with ‘encrypt passwords’ and ‘smb passwd file’ above.
# NOTE2: You do NOT need these to allow workstations to change only
# the encrypted SMB passwords. They allow the UNIX password
# to be kept in sync with the SMB password.
; unix password sync = Yes
; passwd program = /usr/bin/passwd %u
; passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n *passw
# UNIX users can map to different SMB User names
; username map = /etc/smbusers
# Using the following line enables you to customize your configuration
# on a per-machine basis. The %m gets replaced with the netbios name
# of the machine that is connecting
; include = /etc/smb.conf.%m
# Most people will find that this option gives better performance.
# See speed.txt and the manual pages for details
socket options
workgroup = NAME
guest account = GUEST
encrypt passwords = no
password level = 0
preferred master = no
os level = 0
null passwords = no
dead time = 0
debug level = 0
domain master = no
load printers = no
comment = Public Stuff
path = /home/
public = yes
writable = yes
printable = no
write list = @staff

This file is responsible for defining everything that occurs on the Linux side of Samba and, as it stands, is a task to piece together. I’m going to try to ease that burden a bit.

A more modest (and easier to explain) smb.conf (and the one that we’re going to work with) looks like this:
printing = bsd
load printers = yes
log file = /var/log/Samba-log.%m
lock directory = /var/lock/Samba
workgroup = WORKGROUP_NAME
encrypt passwords = no

comment = Public Stuff
public = yes
writable = yes
printable = no

printcap name = /etc/printcap
path = /var/spool/Samba
browseable = no
guest ok = yes
writable = no
printable = yes

security = server
path = /var/spool/Samba
printer name = lp
writable = yes
guest okay = yes
public = yes
printable = yes
print command = lpr -r -h -P %p %s
create mode = 0700

A wee bit more manageable… but still a bit overwhelming.

Let’s examine this file section.

The [global] section of the smb.conf file handles all the basic (and primary) Samba configurations that will be shared by all the resources. Within this section, you’ll see entries that cover printing, logs, workgroups, guest accounts, passwords, and a few low-level command entries.

The [global] section of smb.conf contains some key entries for the implementation of Samba. The first entry
printing = bsd

tells our Samba server what type of printing we are dealing with—in this case, bsd. The second entry allows the Samba server to load the printers that are outlined in the various printer sections (in our example, [printers] and [ljet]).

The next most important entry in the [global] section is
workgroup = WORKGROUP_NAME

This section should be very familiar to the avid Windows networking fan. Within your Windows networking environment, your net is set up as a workgroup. You enter the name of this workgroup here.

The entry
encrypt passwords = no

is key to allowing your Samba server to communicate with your Win 9x machine. After the later releases of Windows 95, Microsoft started encrypting passwords, which pulled a bit of a snafu on the Samba project. Samba uses unencrypted passwords by default. (Win 9x uses encrypted by default.) You can’t browse servers when either the client or server is using encrypted passwords because a connection can’t be made anonymously. You can solve this problem in one of two ways: Make Samba deal with encrypted passwords or make Win 9x deal with unencrypted passwords. The latter approach is, by far, the easier. To make Samba use encrypted passwords, you have to create a matching password file, /etc/smbpsswd, and then make the initial connection with the appropriate authentication. To get the initial connection, enter the share name manually in the Windows File Manager or Explorer dialog box, in the form

Log on to the server with a username and password that are valid on the server.

For our purposes, it’s best to have both server and clients working with unencrypted passwords. It will save a great deal of time and won’t sacrifice the security of your network (as long as you have security on your network).

Note: You’ll have to make a simple Registry edit to enable Windows to work with unencrypted passwords.

The [public] section allows the Samba server to specify which directory will be shared out to the public. You’ll have to make a few choices: Do you open the entire server up to the public, do you limit the public on what it can see, and to what level do you limit the public? This “limitation” will depend on two things: how well you trust those who share the server and how secure you need to keep certain files and directories on your server.

For example, say that you want the “public” to be able to read the entire drive on your server. Your path = statement will look like this:
path = /

This approach is not advisable to anyone administering a network when multiple users are involved. The best strategy is to put all the files and directories into a single directory—say, /usr/public—and allow that directory to be shared to the public:
path = /usr/public

For a bit of security, you can allow only members of a specific group to write to the directory by adding the following entry to the [public] section:
write list = @GROUP_ALLOWED

This little entry will ensure that only GROUP_ALLOWED will be able to write to the /usr/public directory.

[printers] and [ljet]
The last two sections of the smb.conf file ([printers] and [ljet]) define the printers to be shared via Samba. Printing with Samba can be rather tricky. The important thing to remember is that you send the files to be printed to a specified directory (in this case, /var/spool/Samba) and execute the print command (in this case, print command = lpr -r -h -P %p %s) on that file.

I’ll examine a few important entries in the printer sections of smb.conf. The entry
printcap name = /etc/printcap

dictates to the server where the system’s printcap file resides. (The printcap file is the configuration file for the system’s printer.)

The second important section is the path to the directory where the printer jobs will be spooled. As mentioned above, this entry is
path = /var/spool/Samba

It will ensure that all print jobs are spooled in the above directory. The final critical entry in the printer section is the print command entry:
print command = lpr -r -h -P %p %s

It will run the proper print command on the job that’s sent to the /var/spool/Samba directory.

The remainder of the printer sections should be self-explanatory.

Finishing up
The final step on the Linux side (after saving the /etc/smb.conf file) is to start the smb daemons. To invoke the necessary daemons (smb and nmb), run the following command as root:
/etc/rc.d/init.d/smb start

You should receive the following:
Starting SMB services:   [ OK ]
Starting NMB services:   [ OK ]

Once these services are in place, it’s time to turn your attention to Windows.

First, make sure that your computer’s Ethernet device is working properly. Then, make sure that the name and workgroup name are configured properly. In the Network properties sheet (Control Panel | Network), select the Identification tab and enter both the computer name and the workgroup. (The workgroup is very important and will be reflected in the smb.conf file on Linux.)

Once you’ve properly named the machine, select the Access Control tab and make sure that share-level access control is enabled. Finally, back on the Configuration tab, go to the File and Print Sharing section and make sure that both options are selected.

Now that you’ve configured identity and access, move over to the properties of your Ethernet adapter and make sure that the IP address and Subnet Mask are correct for that machine. On the WINS Configuration tab, select the option Enable WINS Resolution and enter all the IP addresses of the machines on your network. Next, on the Gateway tab, enter the gateway address of the Linux server. Then, on the DNS Configuration tab, enter the host name (the name of that machine), the Domain name (the domain of your network), and DNS Servers, if necessary.

Once you’ve entered all this information, click Apply and click OK. At this point, let Windows reboot. Then, you should be able to see the newly configured Samba server in Network Neighborhood. Double-click that icon and see if you can browse your Linux file server as if it were any old Windows machine.

You already have your smb.conf file set up and ready for printing. If your printing is taken care of through a Windows machine, you’ve finished. If your printing needs are met through your Linux server, then you have to configure your Windows machines to print from that particular box. The only thing left to configure is the Windows side of life. Use the Printers applet (in Control Panel) to configure the printer. Click the Add Port button, choose Network, and browse on over to the machine that holds your printer. Once you’ve added the port, select the General tab and run a test print job. Simple.

Samba is a very powerful application, and this drill down has only briefly touched on its ability. What we’ve managed to do is set up a very basic Samba server that will allow your Windows clients to use the power of Linux as a file and print server.

Jack Wallen, Jr. is very pleased to have joined the TechRepublic staff as editor in chief of Linux content. Jack was thrown out of the “Window” back in 1995, when he grew tired of the “blue screen of death” and realized that “computing does not equal rebooting.” Prior to Jack’s head-first dive into the computer industry, he was a professional actor, with film, TV, and Broadway credits. Now, Jack is content with his new position of Linux Evangelist. Ladies and gentlemen—the poster boy for the Linux Generation!

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.