Samba - Tuning the NT/UNIX Dance
Mark Nassal
More and more NT installations are occurring every day in corporate America, and as system administrators we must begin harnessing these resources and integrating them into our UNIX networks. One of the biggest problems with NT/UNIX integration has been the inability to share files without the additional purchase of third party products such as PCNFS, Chameleon, or FTP OnNet. NFS add-ons often carry a large price tag and are not always fully compatible with many PC applications. On several occasions, I have seen MS Access run out of file handles when mounting a drive with PCNFS. But, just like in the movies when you think all is lost, in walks the hero. In this case, the hero is a protocol called Samba. Essentially, Samba is a LanManager server running on a UNIX box. Clients using LanManager, NetBEUI, NetBIOS, or IPX/SPX and TCP/IP can communicate with UNIX servers peer-to-peer. This means that Microsoft NT, 95, and Windows for Workgroups are all LanManager compatible, so you no longer need to purchase a third party protocol for your Microsoft/UNIX connections. You can simply install Microsoft networking and Microsoft TCP/IP on your clients, and Samba on the server. Samba is distributed under the freeware concept. It is continually updated and is documented better than some commercial applications used every day. To get a copy of precompiled binaries or the source, go to:
http://lake.canberra.edu.au/pub/samba/samba.html.
The most current version is 1.9.16, patch 9. I currently have this rev running on six servers and haven't encountered any problems, (two SunOS 4.1.3, two Solaris 2.5.x, one Red Hat Linux 2.0.18, and one Plug and Play Linux). Many other systems are supported as well. In fact, I will lay odds that if you have a server built after the stone age, there is a binary already available for it. After quickly scanning the Samba Web site, I found binaries for SGI, HP, Solaris 2.x, SunOS, Linux, SCO, Ultrix, AIX, Interactive, UnixWare, OSF1, and BSD. If your system does not already have a binary available, then the source can be downloaded. There are also LanManager clients available for Windows 3.1 and OS/2. Not only are many systems supported, but there are literally thousands of Samba installs out there. The author of the protocol has added a customer survey section to the Web site, and the list includes some heavy hitters. Bank of America has 15,000 clients connected to Samba; Central Missouri State University has 5,023; Netcom Technologies has 2,100; Johnson & Johnson has 600; and Digital Equipment Corp. has 500. As you can see, these are not small installs. This protocol is being used in a big way. Performance All this stuff sounds great, but assume I need to transfer a lot more that one or two files. How does Samba stack up to NFS? When using WFW, NT, or 95 as the client, Samba has been shown to be up to four times faster than PCNFS. While converting my large network to Samba (500+ seats), I decided to run some numbers myself. I used a Pentium 133mhz PC running Microsoft NT 3.51 with FTP OnNet as the NFS client, and a Sparc 20 running Solaris 2.x as the server. The newest rev of Samba was installed on the server using my standard configuration template. Throughout the day, I recorded transfer rates while copying a 14 MB file. Transfer times varied as traffic on the Internet changed, but Samba always came out ahead. After some minor tuning, Samba measured 26% faster than the 32-bit OnNet. I would expect to see an even greater difference with a 16-bit OS such as DOS or Windows 3.1. One advantage of Samba is that it is fully configurable and options can be applied selectively to each share. For example, one directory can be writable only by group, another writable by everyone, and yet other reduces long file names to the DOS 8.3 naming convention. The key is flexibility. With Samba, your network can be tailored to meet the needs of both UNIX and PC users. Installation The first step in installing Samba is to download a binary for your system. Connect to:
http://lake.canberra.edu.au/pub/samba/samba.html
and search through the binary index. You will need a copy of GZIP to decompress the files. If you do not have a copy, one can be downloaded from ftp://sunsite.unc.edu. Decompress the file in a temporary directory as root and then un-tar it in /usr/local. Samba will extract to a directory named samba with the version number. Rename the directory to samba (mv samba-xxxxx samba). Change to the $SambaHome and add the directory $SambaHome/lib. Your configuration file (smb.conf) will be stored here. Next, you'll need to create a directory for the log file, I suggest /var/log/samba, so that all your system log files are located in a central location. You will also need to create a lock directory and a print queue. Make the directories /var/spool/samba/lock and /var/spool/public. The lock directory must be writable by all, so change the directory permissions to 666. The directory structure is now complete. An incredible number of options can be set for Samba and its shares. Samba uses a file called smb.conf to store configuration information. This file will be edited to add, remove, and modify the command options. This file also contains the share information (similar to the UNIX /etc/exports). Before editing the samba.conf, I suggest reading the man page to get a better understanding of the commands. To find the man page, change to $SambaHome/docs and enter the command:
nroff -man smb.conf.5 | more
After you become acquainted with the options, it is time to create the config file (smb.conf). I have included a sample template with this article (see Listing 1), which with a few minor modifications should work well. I use this file on all my servers with excellent success. Each main entry is commented so you will know what changes need to be made. When you have finished editing the file, store it in $SambaHome/lib. I have also added an smb.conf generator to my Web site: http://www.tiac.net/users/nassalm/index.html. It is an on-line form that prompts users for the required information, then displays the file for download. I have set up five sample shares in the template (CDROM, home directories, public, group, and general). The first share type is the CDROM. There are three key points with this share: (a) it is a read-only file system; (b) it does not require file locking; and (c) a mask must be added for UNIX CDs. Many UNIX CDROMs when mounted to PCs will display ;1 at the end of each file. To correct this, the "mangled map" must be added.
;Setup a CDROM Share [CDROM0] comment = CDROM 0 ;Path to CDROM path = /cdrom ;Set to Read Only File System read only = yes ;Turn off File Locking locking = no ;Mask the ";1" mangled map = (*;1 *) ;If names need to be truncated to 8.3 set to yes mangled names = no
When sharing the home directories, restrict access to the owner and have the directory automounted. Samba automatically connects users to their home directories when the [homes] share type is encountered. It works similarly to the "auto-home" map used by NFS automounter. Because the guest ok option is set to no, a password is required when entering the directory.
;Setup Home Directories [homes] comment = Home Directories ;Prevent other users from viewing the DIR browseable = no
Public directories allow users to create and view files in a common area. Passwords are not required, and files are saved under the Samba guest user.
;Public Share [public] comment = Public ;Path to DIR path = /export/public ;Allow other users to scan the directory browseable = yes ;Allow guest users (no password) guest ok = yes ;Users can Read and Write read only = no ;Turn on File Locking locking = yes ;UNIX File mod create mode = 0666 ;If names need to be truncated to 8.3, un-comment ;mangled names = yes
Group shares can be created so that the world can read directories, but only users within a group can write to them. These permissions are set using the "public" and "write list" options. The public option allows all the users to view the share, and the write list option defines the group or aliased group that has write privileges.
;Create a Group Share [group] comment = My Groups Directory ;Path for the Share path = /home/samba ;Make it Available to everyone public = yes ;Writable by Group Members writable = yes printable = no ;Turn on File Locking locking = yes ;Group which has Write Privileges write list = users ;If names need to be truncated to 8.3, un-comment ;mangled names = yes
This directory could be further secured by setting the "read list," which would limit the users who could view the documents. The "read list" also uses a group name as an argument. These settings override the UNIX permissions and should be used carefully. Most of your shares will fit into the "general" format, leaving UNIX to determine privileges based on uids and gids. Each user is required to enter a password and, depending on the mode set for that directory, they will be given privileges accordingly. This format is equivalent to a PCNFS share.
;General Share [general] comment = General Purpose Share ;Set path path = /opt/local ;Allow users to view files according to UNIX privileges browseable = yes ;Only view with Permission public = no ;Require a Password< guest ok = no ;Allow users with Privs to Write read only = no ;Turn on File Locking locking = yes create mode = 0755 ;If names need to be truncated to 8.3, un-comment ;mangled names = yes
User names and passwords can be accessed from an NIS server, the local /etc/passwd file, or the Samba password file. It really doesn't make sense to use the Samba password file since the users are already in the local or yppasswrd files. If the Samba server is connected to an NIS network, point to the NIS password server (password server= $ypserver) in your smb.conf. If the local system is being used for lookups, comment out password server= $localserver. The global settings at the top of the conf file are self-explanatory, but again if you need more information, review the man pages. Now that the configuration file has been created, you can test the settings. You can avoid a lot of headaches by using the file $SambaHome/bin/testparm to check your configuration. The best way to use the tool is to print the results to a file and view it after completion. Change to the directory $SambaHome/bin and enter the command ./testparm > /tmp/testsamba; press Enter, then after a few seconds, press Enter again. The script waits for the Enter key to be pressed before continuing. You won't see this message because it is piped to a file. After the prompt returns, use more or vi to view the file (/tmp/testsamba). You will see a complete list of Samba's variables and its translation of your smb.conf file. If everything looks OK, then you can continue. If any of the settings are different than you intended, go back and check your entries. Continue this process until you get a clean output. Now that the configuration is completed, you can start up the server daemons. Samba can be loaded in several ways. It can be loaded through the /etc/services file, from a script, or in /etc/rc3.d. I prefer to use a combination of scripts and "rc" files. It is easer to bring the daemons up and down this way. I usually create a script in /usr/local/bin because it is a default path for my root logins. To create the file, use vi or your favorite editor and add these lines.
echo -n "Starting SAMBA Services: " if [ -f /usr/local/samba/bin/smbd ]; then
Save the file as /usr/local/bin/ start.samba, and then use chmod to set the file to 775. Next you should create an "rc" so the daemons will be started and stopped by the run levels of your system. Use the same script as above and save it to the appropriate "rc" file. If you are running Solaris 2.x, save the file to /etc/rc3.d/SxxStartSamba (xx = run number); if the OS is Red Hat Linux, save it to /etc/rc.d/rc3.d/SxxStartSamba; and if your OS is SunOS or HP, add it to the end of /etc/rc.local. You can get fancy and add start and stop functions to the code, but I don't think it is necessary. Now, barring any run errors, the server install is done. Start the daemons with /usr/local/ start.samba and cross your fingers. Samba initially starts two processes, smbd and nmbd. Use the ps command to check that they are indeed running (ps -aef |grep bd or ps -aex |grep bd). You should see both daemons listed. If so, great; you can start testing it. If not, go back and check your startup script. Kill any bd processes and try it again. Now that the Samba server is up, let's see if it's sharing the requested directories. The Samba server comes with a UNIX client so you can test your setup and copy files to and from Microsoft workstations. Change to $SambaHome/bin and run ./smbclient -L $localserver. Replace $localserver with your server name. The -L option displays all the shares on a LanManager server. You should see a list of shared directories, their LanManager share names, and the comments. If your shares and server names are correct, you can now try accessing the server from a NT workstation. The Windows NT configuration is pretty straightforward because it is designed to use the LanManager protocol. My description will be limited to NT 4.0, because that is the current version Microsoft is shipping. There are only a three prerequisites for connecting to a Samba server. First, you should have TCP/IP configured; second, you will need the NetBIOS protocol loaded; and third, each client and server must be in each other's host list. If your network is internally routed, then the Samba server will not show up in the Explorer browser. You will have to search for it with the "Find" option. Start the Explorer, then select the Tools menu, find, and Computer. Enter the Samba server name preceded by two back slashes (\\$sambaserver). Press the "Find Now" button. Once the server is located, it will be displayed in the dialog box. Double-click on the icon, and a list of available shares will be shown in the Explorer (See Figure 1). Double-click on the desired share just as you would for a local directory. You will then be prompted for a password and user name (if requested), then you will be in. Keep in mind that NT user names and passwords should be the same as the UNIX names and passwords. Samba attempts to use the current NT login for connections. If you want the share to be available at login, or accessible through applications, you must map it to a drive letter. To assign a drive letter to a directory, right-click on the directory icon and select "Map Network Drive" (See Figure 2). When prompted, select a drive letter. For the drive to automount, choose "Connect at Logon." (See Figure 3)The next time you log in, the directory will be automounted. If your network is flat (i.e., not internally routed), you can connect the Samba server through the Explorer browse list. Double-click on "Network Neighborhood" and then on the servers icon. You will then get a display of the shared directories as in the above example. Configuring Windows 95 is essentially the same as NT. Ensure that TCP/IP is configured and that the NetBIOS protocol is loaded. Since NT has started using the 95 desktop, browsing is the same. Windows for Workgroups (WFW) users will have to download the Microsoft TCP/IP package (if it is still available) or purchase a third party TCP/IP stack and install Microsoft Networking. Because there isn't a network browser included in WFW, connections must be made at the command line. Microsoft includes a utility called net that allows users to connect to MS workstations. At the prompt, enter the string net use $driveletter:\$servername\$directory. For more information on using this option, consult the MS WFW documentation. WFW has reached the outer limits of it usefulness in the networking environment, and I stopped working with it several years ago, so my information is limited. The Samba Web site contains a lot of information on configuring and using the older operating systems such as WFW, Windows 3.x, and OS2. I suggest reading the FAQs regarding these systems if you plan to add them to your integration list. Now that I have covered the Microsoft clients, I'll discuss the UNIX client. Earlier in the article, I mentioned a utility called smbclient that was used to check shares. This same script can be used to connect to an MS workstation. The tool provides an interface similar to ftp. It can be included in scripts to automate file transfers, and even provides a tar option. An engineer I work with uses it to automatically transfer data from UNIX network collectors to his PC for analyses. The only catch is the strange addressing it uses. To connect to a share, you must enter four back slashes and the servername, then two slashes and the share name (\\\\$servername\\$sharename). If you forget to use this format, it will error out. Change to the $sambahome/bin directory to give it a try. The first step is to find out what shares are available on the PC. Enter ./smbclient -L $MSservername. This command will list the shares for a Microsoft workstation. Now you can pick a share and connect to it. Enter ./smbclient\\\$Msservername\\$sharename <enter>. You will then be prompted for a password. Enter the password, and you will be presented with a Samba prompt (smb: >>). At the prompt, enter ? to receive a list of available commands. The standard ftp commands are available along with several new options such as newer, setmode, archive, tar, recurse, queue, and blocksize. The man page for smbclient describes the commands in detail and also shows how to automate transfers. If the connection did not work properly, check the server path (\\\\$MSservername\\$sharename), user name, and password. Also make sure that both machines are listed in the host files. This may sound complicated, but it's really not. I average about 15 minutes for an install. The secret is having a good smb template and keeping things simple. As I stated earlier, there are numerous options that can be set for drive shares, but in most cases only two or three share types are needed. Start with the sample template and make modifications one at a time. Once the system runs well on your network save the file as a master config. I hope this article piqued your curiosity if nothing else; enjoy.
About the AuthorMark Nassal is a senior UNIX administrator at Harte Hanks Data Technologies in Billerica, MA. They operate a predominantly UNIX network with NT 3.5 and 4.0 as the standard desktop OS. He has been in the Computer/Telecommunications industry for nine years, and much of his work has centered around UNIX/Microsoft integration.
|