Figure 1. The Network Neighborhood

Oh dear, we have lots of Windows servers we didn't know about .... But let's concentrate on just the Marketing machine. See Figure 2.

Figure 2. The Marketing server
Figure 2. The Marketing server

This looks manageable: two directories containing a small number of proposals and templates, and a printer.

The first thing to do is to protect the data and copy it to our Samba server, Elsbeth. We changed the permissions (actually passwords) on the Windows server so that only we could read from it, and created a directory tree on our Samba server for the data.

From the new /usr/local/samba/marketing directory on Elsbeth, we started copying using smbclient:

   elsbeth> cd /usr/local/samba/marketing/proposals
   elsbeth> smbclient //marketing/proposals
   added interface ip= bcast= \ 
   Got a positive name query response from
   smb: \> prompt
   smb: \> mget *
   smb: \> quit
   elsbeth> ls
   proposal_1 proposal_12
   proposal_2 proposal_3
   proposal_5 proposal_7

Smbclient is an ftp-like program that's handy for jobs like this. Its commands are shown in Appendix D of Using Samba (also on page 63 of Samba Pocket Reference).

Interested in learning more about how Samba can help Unix and Windows machines coexist peacefully? For more insight into the power of Samba read An Interview with the Authors of Using Samba.

This isn't the only way to get the files. We could have used smbsh to copy the //marketing/templates directory:

   elsbeth> smbsh
   Username: davecb
   smbsh$ cd /smb/marketing/templates
   smbsh$ ls
   enquiry information old presales
   smbsh$ cp * /usr/local/samba/marketing/templates
   cp: old: is a directory
   smbsh$ cp -r * /usr/local/samba/marketing/template
   smbsh$ pwd
   smbsh$ exit

Smbsh is an SMB shell for Unix systems using ELF libraries, which allows us to use ordinary Unix commands to copy files to and from SMB servers mounted on your system. It's described in Appendix D of Using Samba (also on page 71 of Samba Pocket Reference).

We also could have used smbmount if we were on a Linux machine:

   elsbeth> mount -t smbfs -o 
        //marketing/proposals /mnt
   elsbeth> cp -a /mnt/templates* \ 
   elsbeth> umount /mnt

[Editor's note: Line 1 was extended to two lines to accommodate our Web site's formatting. Throughout this article, whenever a line of code or data has been broken up into two lines, the second line is indented.]

Smbmount is an SMB client that uses the standard Unix "mount" mechanism, similar to NFS. At the time of this writing, smbmount is available only on Linux.

Creating the Virtual Server

Next we set up a master smb.conf file and two files, one per virtual server. The smb.conf file says:

        workgroup = EastCoast
        netbios aliases = elsbeth mktg
        include = /usr/local/samba/lib/smb.conf.%L

The %L at the end of the include line will be replaced by whichever NetBIOS name the client tries to use. Clients connecting to Elsbeth will get the usual configuration file, which was copied to smb.conf.elsbeth. Clients connecting to Mktg, the temporary name for the new marketing server, get:

   # Global parameters
        wins support = yes
        local master = no
        log level = 1
        debug timestamp = yes

        browseable = yes
        read only = no
        path = /usr/local/samba/marketing/proposals
        browseable = yes
        read only = no
        path = /usr/local/samba/marketing/templates

This is the Samba declaration for the two former Windows shares, plus a few settings that apply to all shares on that server.

If we connect from a Windows client, we'll see the image in Figure 3.

Figure 3. Our first try at a replacement
Figure 3. Our first try at a replacement

Additional Wrinkles

After asking the departmental secretary in marketing to connect to the new server, we found we had the files and directory permissions right, but hadn't given "administrative" access to the secretary. We resolved that by adding:

   admin users = mktg_sec

to the [globals] section of smb.conf.mktg. This gave mktg_sec the equivalent of root permission in the /usr/local/samba/marketing file tree, but nowhere else.

The second wrinkle was that everything in the proposals directory had to be editable by the group. This meant we had to add:

   force create mode = 0660

so that all files that were created or edited from Windows would be writable by the group. Windows editors create new copies of the files they edit. If we didn't force the permissions to include writable-by-group, the proposal files would be read-only to everyone except the last person to edit them.

Next we had to make the templates read-only, which we did by changing the line under [templates] to:

   read only = yes

Finally, a local printer on the former marketing manager's machine had been shared as Printer E12. This printer was promptly claimed by the departmental secretary. We therefore set up a printer share on Mktg called Printer E12, pointing to the Windows printer, which now resided on the secretary's machine. The process is discussed in Chapter 7 of Using Samba (also on page 65 of Samba Pocket Reference).

Once we finished, we were ready to let the department get its data back. We renamed the virtual server from Mktg to Marketing, and emailed users that it was working. The user community started connecting, as shown in Figure 4.

Figure 4. The final replacement server
Figure 4. The final replacement server

The old marketing machine was retained for a few days under a different name with its files set as read-only, so that anything we missed would be available. After a week of no complaints, we shut it down and handed it over for refurbishing and reinstalling of a new copy of Windows.

We made almost everyone happy. The department had a server now that was backed up nightly (the Windows machine had never been), the secretary had the printer, and the new marketing manager had a Windows machine that wasn't slowed down by other people in his department using it as a file server.

Making Migration a Practice

When we first looked for the Marketing machine, we found a plethora of Windows SMB servers: 19 to be precise. Exactly three of these were official NT or Samba servers. This did not please our management, since they were paying for the servers, but didn't even know they existed. The old servers also were not on our backup system.

If your management is as cost-sensitive as ours, you might propose replacing large numbers of Windows servers with a single Unix or Linux server, to reduce both costs and business risk.

There are a number of places where Samba will save money over Windows servers, even planned and supported ones. These include client access licensing (CAL), server licenses, hardware reusability, increased uptime, and decreased third-party software licensing costs.

If we had replaced the unofficial Marketing server with an official Windows 2000 PDC, our first cost would be buying a license upgrade and client licenses for the other windows machines in the department:

Software Licensing Costs Windows 2000 server Server Licenses (upgrade) $599 each, includes 10 CALs Client Access Licences (CALs)
  (must be renewed with each upgrade) $799 for 20
($39.95 per client)

If we consider Windows licensing costs for a 20-client department or a 2000-client company, the upgrade and relicensing costs are nontrivial.

  20 clients, 2 servers 2000 clients, 20 servers* Server Licenses
  (upgrade, if available) $1,980 $11,980 CAL Costs included in server price $71,910

*Ask about volume discounts

We can also gain savings in hardware costs. Samba runs on Linux, and Linux will run effectively on hardware which Windows considers obsolete. For instance, the minimum requirements to run Windows 2000 are a Pentium 166 with 64MB of RAM. Linux, however, can run on as little as a 386 with 8MB of RAM. Many businesses can reuse former low-speed Pentium-class desktop computers as Samba servers.

However, our greatest savings is in increased system reliability. Because we are able to do most system maintenance and software upgrades "live," without rebooting, we are able to keep systems up during most maintenance windows. With Windows NT 4, companies generally allow four hours per month for offline maintenance, which is about 99.45 percent uptime.

Getting this up to 99.99 percent uptime, typical of Unix and Windows 2000 systems, gives us 3.5 additional hours of uptime per month, without the cost of upgrading to Windows 2000. With system administration costs running around $125 per hour, even 3.5 hours per month (due to the 0.5 percent improvement in uptime) equates to more than $425 in savings per server.

Caveats and Avenues of Error

If you plan to retire the redundant Windows servers in your company, you need to consider a few additional issues.

One of the obvious ones is to make sure you have enough disk space and memory to support the additional user community. In several cases we've removed disk drives from inactive Windows 9x servers and reused them in Samba servers for subsequent server migrations. Appendix B of Using Samba includes the rules of thumb we've used to size Samba for larger groups of users.

We found out very quickly that managing user accounts on individual Unix servers was difficult. Unless the Linux machines used a centralized database of users and groups, they could start to become an administrative nuisance. To eliminate this, we use NIS which allows us to centrally manage user logins, and groups.

In migrating a group of users from a Windows NT PDC, however, we found NIS alone wasn't enough. In larger organizations, administrators would change user information in the Windows NT domain, but forget to modify the Linux user information. To ease administration, we used a program called AutoSync. It automatically synchronizes Windows NT user and group changes into NIS.

We also recommend LPRng and LPRngTool for managing printers, as they are easier to use then most other printing subsystems, and work well with Samba.


There are significant financial and administrative advantages in using Samba. Multiple virtual Samba instances on one server reduce the amount of hardware required, the licensing costs, and the amount of time spent administering those servers. From both a business and systems point of view, it's a big win, and with the money saved, we just might be able to convince upper management to buy us some new hardware.

David Collier-Brown David Collier-Brown is a former system administrator from a multinational corporation, and is now a Staff Engineer at Sun's Customer Engineering site in Toronto. He does system and application tuning for customers on Solaris and tries to find time to write about Samba and Linux. David is coauthor of Using Samba and Samba Pocket Reference.

Geoff Silver Geoff Silver is a Senior Systems Administrator at Scoreboard, Inc., is married, and runs a Linux professional services company at US Linux Networks, LLC. He is a graduate of the University of Maryland, Baltimore County, and has been working with Unix since 1995 and Linux since 1998.

O'Reilly & Associates will soon release (April 2001) Samba Pocket Reference, based on the best-selling Using Samba (November 1999).