Samba
Eric Knudstrup I was recently asked to come up with a way to allow the people in our office to share files between our Sun workstations and the PCs that run Windows. Also, our NetWare server was getting pretty old, and having one less box in the office sounded like a good idea. I considered purchasing an NFS package, but none of them fit in with the specifications that I had in mind. I wanted a package that wouldn't mean adding new software to the Windows machines, and price was also a consideration. For a couple of years I have been experimenting with a GNU copylefted server called Samba that runs on UNIX machines, so I decided to give it a try for our network. Introduction Samba uses the SMB (Server Message Block) protocol that Microsoft has adopted for its native file sharing. SMB is basically NetBIOS running over TCP/UDP. Because SMB is encapsulated within TCP/IP, there isn't a problem with routing over different networks. I have even seen a few ftp sites that advertised public Samba shares. Samba's main attractions are as a file and print server. As a side benefit, it will also act as a WINS name server. Several other utilities that allow Samba to act as a client are also included with the package. smbtar allows you to connect to other SMB hosts and create tar files from their contents. smbprint allows the workstation to use shared printers from machines running Windows 95 or NT. There are two main differences between Samba and NFS. NFS is oriented more toward machine-based file sharing, except for PC-NFS, which runs an additional daemon on the server to authenticate PC users. Samba shares, on the other hand, are authenticated on a per-user basis like ftp or telnet. Another major difference is that Samba's primary transport is TCP instead of UDP. The most noticeable consequence of this is that, with Samba, clients won't keep a connection to a server if the server goes down. Samba was originally written by Andrew Tridgell in Australia, and other people began to pitch in later. Possible clients include Windows for Workgroups 3.11, Windows 95, Windows NT, DOS, as well as Lan Manager and OS/2. Also, a kernel extension for Linux exists that allows mounting of shares from Windows machines (or Samba, for that matter). Currently supported platforms for hosting Samba include most common versions of UNIX, such as SunOS, SCO, AIX, Linux, FreeBSD, and HP-UX. I have verified it on three platforms, SunOS 4.1.3, SunOS 5.5 (Solaris 2.5), and Linux. At the least, you will need to have gzip (GNU zip) available, because in all of the places that I found it (in source and binary form) Samba was only available in tar-gzip format. If you decide to compile it yourself, note that it requires an ANSI C compiler. The one included with SunOS 4.1.3 doesn't qualify, and Solaris 2.5 didn't include one, so I used GCC. Getting Samba Samba is available via ftp from nimbus.anu.edu.au in the directory /pub/tridge/samba. If you are into Linux, some distributions such as Red Hat and Caldera's Network Desktop (Caldera includes a NetWare client as well) include Samba. Also, several very informative WWW sites are devoted to it, all of which you can find by starting out at http://lake.canberra.edu.au/pub/samba. After unzipping and untarring the archive, you will see several directories: bin, docs, examples, and source. docs contains the associated man pages, the basic installation instructions under INSTALL.txt, and a lot of other interesting and helpful information. The examples directory is also pretty useful, as it includes a couple of good example Samba configuration files, that can be used to make your own, by default read from /usr/local/samba/lib/smb.conf. Many options are available, but for our small network, the one below works fine.
[global] keep alive 30 [homes] guest ok no writable yes browseable no [shared] path /export/home/shared writable yes public yes
The [global] is a special section that specifies configuration. The section labeled [homes] is used for sharing people's home directories on the UNIX machine. Once people are logged into their machine in Windows 95, opening up "Network Neighborhood" will display their home directory as a possible share under the server. Note that the last section in the example creates a public directory that everyone can see and connect to. Two daemons comprise the server: smbd, which listens on TCP port 139 and handles file and print service, and nmbd, the name service daemon, which listens on UDP ports 137 and 138. As a warning, it is recommended that sites using SMB-based fileservers filter these ports from their router if they are connected to the Internet. For our clients, we chose Windows 95 for its well-integrated TCP/IP stack. (Microsoft has an update for Windows 95 filesharing, available from http://www.microsoft.com/windows/software/w95fpup.html.) Windows 95 and Windows NT both offer the ability to use the longer filenames used on UNIX machines. If you don't want to upgrade quite yet, Microsoft has an ftp site, ftp.microsoft.com, with the required TCP/IP driver for Windows for Workgroups. I also tried a DOS client available from Microsoft's ftp site and found that it worked pretty well, too. There were a few subtle details that took some time to figure out. One was making sure that all machines were using exactly the same workgroup name, as Windows 95 occasionally had trouble finding the machine with even slightly different workgroup names. Another frustrating problem was that on some machines, Samba would use the wrong broadcast address when it started up. A command line switch for nmbd fixed the problem by specifying which IP address I wanted it to use for broadcasts (nmbd -I your.machines.ip.address). Overall, I have been very pleased with Samba's performance and reliability. Access from our Sun workstation seems to be close to what I expected from accessing a local disk. I recently read a survey from the Samba listserv in which some of the respondents said they were using Samba for more than 200 clients, and the people that were using PC-NFS in conjunction with Samba overwhelmingly declared the latter to be noticeably faster.
About the Author
Eric Knudstrup is a software developer and network administrator for Mammoth Technology in Agoura Hills, California.
|