First, I'm going to show you a bunch of screenshots from one of my Windows NT boxes named kompressor. These screenshots demonstrate what a fully-configured Samba system looks like from the Windows side. They'll give you a real-world grasp of what Samba can do.
I currently have three machines set up on my internal LAN:
In this environment, I use Samba extensively to share files, print, and even run Windows applications directly from freebox (Unix). Here's a screenshot showing the contents of kompressor's Network Neighborhood:
As you can see, both ntbox and kompressor are visible, which is no surprise since they are both NT Workstations. What is rather unusual, however, is the fact that I can see freebox as well. Because freebox is running Samba, I can see it under Network Neighborhood on every Windows machinethat is part of my "GENTOO" Windows workgroup.
Now it's time to take a look at what's "inside" freebox. The following window pops up after double-clicking on the freebox icon:
In this window you can see a bunch of what are called "shares". More specifically, they're called SMB/CIFS shares and contain parts of freebox's file system that are accessible through the network.
On freebox, Samba has been specifically configured to create only those particular shares that you see above. The drobbins share contains the contents of my home directory. I like to store all my files on freebox (under Unix) to keep things centralized and easy to manage. One of the wonderful things about Samba is that it allows administrators to centralize the storage of user files rather than providing each user with two separate file locations for Windows and Unix.
In addition to standard shares (which act as virtual directories), you can also see a printer share called nec. Another really great feature of Samba is that you can share printers the same way you can from any Windows machine. Nec is my NEC SuperScript 870 laser printer, which is hooked up to freebox and set up as a standard Unix lpd-based printer. Samba allows this printer to be used by Windows clients just like a standard Windows network printer would.
You may be wondering how the printer driver situation is handled since the printer is running under Unix. Good question. On freebox, nec is set up as a standard, parallel port-based printer running in "raw" mode. In other words, any print jobs sent to nec are handed directly to the printer as is, without any filtering or data massaging.
On kompressor, nec is configured as an NEC SuperScript 870 network printer. When I print to it, the local NT printer driver generates the appropriate binary data for nec, which is then automatically spooled over the network to Samba running on freebox. Samba then automatically inserts this data untouched into nec's queue, and my printer begins printing the job.
I should note that unfortunately my NEC SuperScript 870 is not a Postscript printer; it uses Adobe's proprietary PrintGear technology. While my printer is not fully supported under Unix, it still works perfectly when printing from Windows (this is because all the printer-specific data is generated on the Windows side, using the Windows driver). Ironically, since GhostScript (a freely-available PostScript-compatible interpreter available for Unix) does not know how to produce PrintGear output, I can only print plain ASCII text or 300 dpi PCL4-based documents from the Unix side; but from the Windows side, the Windows NT driver allows me to print at a full 600 dpi. I don't find this cumbersome at the moment because I do most of my printing from Windows. Although in the future it would be nice to have a printer that has Postscript built-in so that I can use the printer's full functionality from Unix as well.
OK, now it's time to move on to the next screen shot. This one illustrates the contents of the drobbins share on freebox, which is configured to share my Unix home directory. All the files listed in the window actually reside on freebox but are directly accessible from my Windows NT client machines. Being able to integrate Windows and Unix is wonderful stuff!
To show you more about how Samba works internally, I'm going to give you a very simplified explanation of what happened behind the scenes when I poked around in the Network Neighborhood. I should first explain something about my current Windows session. Since I am running Windows NT Workstation, I had to log in to gain access to the machine. For this NT session I logged in to the local machine with the username "Administrator" and the password "mypass". If I were running Windows 95 or 98, the standard Windows networking drivers would have asked me for a username or password as well. Under Windows 95 and 98, this password isn't really used to determine who can access the local machine; rather, it is cached and used to connect to network resources.
Of course, Windows NT is extremely secure compared to Windows 95 and 98 and will not allow you to use the machine unless you supply a valid username and password. After kompressor validated my username and password against its local security database, it allowed me to begin using Windows. Kompressor will also use my username and password to try to automatically authenticate itself when I connect to password-protected network resources.
When I clicked on Network Neighborhood, a window containing a list of all Windows-compatible machines on my network popped up. For this to happen, kompressor contacted freebox behind the scenes to obtain a "browse list" of all the Windows-compatible machines on the current subnet. Kompressor contacted freebox because I configured freebox's Samba so that it would become "local master browser" on my network (which means that freebox manages the list of network resources that appear in Network Neighborhood).
The next thing I did was double-click on freebox, which caused a new window to appear and display all of the shares on freebox. For kompressor to receive this information it connected to a special hidden share on freebox (called IPC$) as the guest user, and downloaded the names and types of all the available shares. In the next article, when we configure Samba, we will need to put an option in Samba's configuration file that specifies which Unix account is equivalent to NT's "guest" user. If this isn't set up correctly, you will not be able to browse any of the resources on a Samba machine. This is also worth mentioning because it shows that you don't need any special permission to view the SMB/CIFS shares on a Samba server, noteworthy for security purposes.
I was now able to click on the drobbins share to display the contents of my home directory. While this happened automatically and without any fuss, it's important to understand the hidden conversation between freebox and kompressor that ultimately granted me access to the drobbins share. But before we get into that, let's quickly discuss some Samba security issues.
When I configured Samba I set up the drobbins share to be password protected; even though I'm on my own private LAN, I still like to keep things locked down to a certain extent. At the same time I set up two Samba users: drobbins and administrator. I set their passwords to match those on my NT Workstations for consistency. For the drobbins share, my security policy is as follows: if you are a valid Samba user, and you supply the correct password for that user, you will be allowed access to the drobbins share. So, both administrator and drobbins will be granted access as long as the user also supplies the correct password for their account.
Now, back to the conversation between freebox and kompressor. Because I logged
in as administrator, double-clicking on the drobbins share caused Windows NT to
automatically try to authenticate me to Samba by sending the username
"administrator" and the password "mypass" to freebox. Samba then checked these
values against its internal security database (which is separate from the
standard Unix
You may be wondering why Samba has its own unique password database. Why
doesn't it just use the standard Unix password to authenticate the administrator
user? While it used to be possible to do this when Windows transmitted passwords
in plain-text, all modern versions of Windows now transmit SMB/CIFS passwords in
an encrypted form that is not compatible with the standard Unix password hash.
In other words, there is no way for Samba to use the standard Unix
Now that we've seen Samba from the Windows side, it's time to take a look at
Samba from the Unix side. First some general information. The main Web site for
Samba is
If you compile and install Samba from the original sources, Samba's
configuration file can be found at
One of the major complaints about Samba is that the smb.conf file has a relatively high learning curve. While this is true, remember that Samba is not just a simple network file sharing program. It has the responsibility of sensibly integrating two significantly different systems: Windows and Unix. Sometimes the configuration process will seem tricky, but do not fear. When you have everything working perfectly, it will all be worth it!
I mentioned earlier that Samba has its own password store that is unique from
the standard Unix
We've covered a lot of Samba's key functionality and key concepts. We've also
seen an overview of Samba's Unix-side file structure. In my next article I'll
walk you through the process of setting up Samba on your own system. Unlike this
article, which focused more on concepts, the