Samba: Better at Windows than Windows?

See how Samba can provide even better Windows networking configurations than Windows can.

When IBM first shipped OS/2, it touted the operating system as being a "Better Windows Than Windows." OS/2 may indeed have been better than Windows 3.1, and in many ways also better than Windows 95, but OS/2 didn't last long in the face of the Microsoft onslaught. Linux has been faring a little better than OS/2, and with the inclusion of Samba, Linux can participate in a Windows network in such a way that it is a better Windows than Windows. Here's why.

Samba as a client
One of the benefits of Samba is that the client is simple. There aren't layers of GUI and multiple connection mechanisms to get in the way of making a simple request to mount a drive. Although capable of connecting with Windows 2003 Servers, it's also equally capable of connecting to all versions of Windows, including Windows for Workgroups 3.11. Where a Windows XP system might refuse to transmit user passwords over the network unencrypted, Samba will dutifully complete the request you made of it.

Mounting a shared drive with Samba isn't substantially different from mounting any kind of a file system. Whether you're mounting a CD-ROM drive or an ext3 formatted partition, the mount command takes two basic parameters: the device to mount and where to mount it.

Mounting a Windows share is the same—you reference the server and share with a UNC-reminiscent path. It's the same as a regular UNC path that you would use with Windows, except the backslashes have been replaced by forward slashes. This is to accommodate the special backslash handling in most Linux shells. So where UNC is \\SERVER\SHARE, the mount equivalent is //SERVER/SHARE. The first part of the mount command would look something like mount //server/share /mnt/smb where /mnt/smb is the directory you created to mount the share to.

In most cases, this will work flawlessly. Mount will detect that you want to mount a SMB share. It will provide the current username to the remote machine and will prompt for a password, if necessary. The problem with this is that it will require that the username on the remote system be the same as the username with which you logged in to the Linux system.

Given that the administrative account in Linux is root and the administrative account in Windows NT and greater is administrator, it's likely that you'll have at least some cases when you'll need to override the username that Samba wants to use. This is done by using the -o option to tell mount that you need to pass along some other parameters. A username can be passed along to Samba by providing username=. You can optionally pass a password along with password=. If you wanted to specify the username of myuser and password of tellnoone, the option would look like:
-o username=myuser,password=tellnoone

You should notice that there is a space after the -o, and that the parameters are separated by a comma and no spaces.

Finally, you may want to be explicit and tell mount that you really want to mount the SMB share. This is done by specifying a type (-t) of smbfs. When you put everything together, you end up with a mount command that looks like:
mount //server/share /mnt/smb –t smbfs -o username=myuser,password=tellnoone

If you want to do something more esoteric, such as specify a different port to connect to, there are options that you can use. The man page for smbmount, which is used by mount to accomplish its tasks, gives you a complete list of supported options in the mount command. The mount options that are available here are substantially more flexible than a typical Windows client, where the settings are buried in registry settings that are not documented—or are not documented well.

Samba as a server
For those who've never worked with UNIX much before, the concept of help files takes on a different meaning. Most UNIX jockeys live by man pages. The man program provides quick information and detailed information about how a particular command works. Not only are all of the parameters covered, but often there are a series of progressively more complex commands. Most man pages are no more than a handful of screen pages long so they can be read quickly.

Samba is a bit different in that the smb.conf file—the main Samba configuration file—has 120 printed pages of documentation in its man pages. The configuration file has a set of options that allow you to tweak nearly everything in Samba. This includes more than a few options that are clearly marked with warnings that they should probably never be changed.

This is a distinctly different experience than with a Windows server. With a Windows server, many of the file-serving options are buried down in the registry. The names of the parameters are often confusing or misleading, and finding documentation on them is limited to searching the Knowledge Base.

Samba's documentation provides a great advantage, but the ability to set many of these options on a share-by-share basis is also substantially better than in Windows, which may require that file-serving settings be set for all shares.

Setting up a simple share in the Samba configuration file, smb.conf, is as simple as going to the end of the file and adding a few lines. The first one is in the form of a section name that will be the share that the user will use. To create the share called test, you would start with a line that reads [test]. Under this line, you'll want to add a few lines that tell Samba where you want the share to point to, who can access it, and how you want it to behave.

The first thing that should be set for the share is the path that the share will connect the users with. This is the path element, so the line starts with path=. The actual path to the directory is expressed in the standard UNIX/Linux format. The final line might look something like:
path = /tmp

If you want to tell the users who are browsing for information on what the share does—and your share name isn't descriptive enough—you can enter a comment or description that will be displayed to users as they browse. This line begins with the comment attribute. An example might include the line:
comment=Testing Samba and temporary working space.

The next step is to decide who can access the share and what you want them to be able to do. If you want them to be able to write to the share, you'll need a line to tell Samba to make the share writable. This is done with a line that reads writable = yes. If you're interested in being clear to Samba, you can also add a line that says printable = no to make it clear that you're not referring to a printer.

You can fine-tune what happens when a Windows user puts a file into the share or creates a directory by inserting the create mask and directory mask options into the new section of the Samba configuration file that you are creating. Playing with the create mask and directory mask can give you shares that only allow uploading (and no reading) as well as shares that allow you to create locations where only the user who added a file can modify it.

Finally, you have to decide which users can have access to the share. You can make the share available to everyone—authenticated or not—by setting the attribute public equal to yes. That would look like public = yes. Going in the other direction, you could specify that the valid users are a small subset of your users. This is a way that you could limit the share to use by the IT department, or some other department that might need some enhanced security on their files. Specifying valid users is done with the valid users attribute and might look something like valid users = alex shelley. This would allow Alex and Shelley to use the share, but no one else.

Save and go
When you're done with your editing, just save the configuration file. Samba will detect the file change and will reread the file to take into account your changes. You've just created your own share that you can access from any Windows system just as you would another Windows system.

Editor's Picks