O'Reilly: Windows Compatibility and Samba (Running Linux)

Linux is a remarkably effective operating system that normally replaces MS-DOS/Windows. However, there are always those of us who want to have their cake and eat it, too. We want to continue to use other operating systems as well as Linux, or at least to exchange files directly with them. Linux satisfies such yearnings with internal enhancements that allow it to access foreign filesystems and act on their files, with compatibility utilities that allow it to invoke MS-DOS to run DOS applications, or with a utility that allows Linux to run Xenix binaries without recompiling. The most outstanding tool for getting Linux and Windows to cooperate is Samba, which we'll discuss in enough depth to help you get a basic, functional server running.

One of the first and foremost things you probably want to do with Linux and Windows is install both of them on your computer and decide at boot time which of the two you want to boot. The section "Section 5.2, "Booting the System"" in Chapter 5, "Essential System Management", tells you what to do in order to get a multiboot system.

The next thing you will want to do is share files between Windows and Linux, a topic which we will explore in the next section. You will find out that this works smoothly for most cases nowadays, if you know the tricks of the trade.

Finally, we cover tools that let you (at least partly) run some of your DOS and Windows programs on Linux. We will be leaving the highway here and follow quite stony roads, but as always, those offer the most exciting sights.

12.1. Sharing Files

When you install both Windows and Linux on your computer, you will often wish you could access files on one operating system that you saved with the other operating system. While there are few, if any, ways to get at your Linux files from Windows on the same machine, it is surprisingly easy to access your Windows files from Linux. Linux can read and write files on the traditional FAT filesystem and the newer VFAT filesystem, which was introduced with Windows 95 and supports long filenames. It can read (and eventually will be able to write to) the NTFS filesystem of Windows NT.

In some cases, it can be even easier to access your files over the network using Samba. If you run Linux on one machine and a version of Windows with built-in networking, like Windows for Workgroups or the newer Windows versions 95/98 and NT, you will probably be able to exchange files between the two machines.

Getting at your data is only half the match, though. You must also be able to make sense out of it. You might be surprised to hear that you can have problems even with the simplest file format, raw text--let alone more elaborate file formats like those saved by graphics programs or word processors.

12.1.1. Mounting DOS, VFAT, and NTFS Partitions

If you have already read the section "Section 6.1.2, "Mounting Filesystems"" in Chapter 6, "Managing Filesystems, Swap, and Devices", you know by now that you access partitions on local hard disks by "mounting" them into your directory hierarchy. In order to be able to read and write to a specific filesystem, the Linux kernel needs to have support for this filesystem.

In the section "Section 7.4, "Building a New Kernel"" in Chapter 7, "Upgrading Software and the Kernel", you learned how to build your own kernel. In order to be able to access DOS (used by MS-DOS and Windows 3.x) and VFAT (used by Windows 95 and Windows 98) partitions, you need to enable DOS FAT fs support in the filesystems section during kernel configuration. After you say yes to that option, you can choose MSDOS fs support and VFAT (Windows-95) fs support. The first lets you mount FAT partitions and the second lets you mount VFAT partitions. VFAT support is relatively recent; it appeared first in kernel Version 2.0.34, but really became stable only with recent kernel versions.

While Linux is running, you can then mount a Windows partition like any other type of partition. If, for example, the third partition on your first SCSI hard disk contains your Windows 98 installation, you can make those files accessible with the following command, which must be executed as root:

mount -t vfat /dev/sda3 /mnt/windows98

The /dev/sda3 option specifies the disk drive corresponding to the Windows 98 disk, while the /mnt/windows98 option can be changed to any directory you've created for the purpose of accessing the files. But how do you know that you need--in this case--/dev/sda3 ? If you're familiar with the arcane naming conventions for Linux filesystems (shown in Table 3-1), you'll know that sda3 is the third partition on the first SCSI hard disk, but you'll find life easier if you write down the partitions while you are creating them with fdisk.

Of course, you are free to choose other mount points than /mnt/windows98. If you want to mount a FAT partition, you do the same, but replace vfat with msdos in the previous command.

Both the msdos and the vfat filesystem driver support a number of options that can be specified with the -o option of the mount command, but in most cases, you will not need them. The man page tells you all the options. There are, however, two options that might be useful for you: check and conv.

The option check determines whether the kernel should accept filenames that are not permissible on MS-DOS and what it should do with them. Obviously, this applies only to creating and renaming files. You can specify three values for check: relaxed lets you do just about everything with the filename. If it does not fit into the 8.3 convention of MS-DOS files, the filename will be truncated accordingly. normal, the default, will also truncate the filenames as needed, but not accept special characters like * and ? that are not allowed in MS-DOS filenames. Finally, strict forbids both long filenames and the special characters. In order to make Linux more restrictive with respect to filenames on the partition mounted above, the mount command could be used as follows:

mount -o check=strict -t msdos /dev/sda5 /mnt/dos

Obviously, the restrictions of the filename length do not apply to vfat filesystems.

The second option that is potentially useful, but not quite ready for most users is conv. Windows and Unix systems have different conventions for how a line end is marked in text files. Windows uses both a carriage return and a linefeed character, while Unix only uses the linefeed. While this does not make the files completely illegible on the other system, it can still be a bother. To tell the kernel to perform the conversion between Windows and Unix text file styles automatically, you need to pass the mount command the option conv. conv has three possible values: binary, the default, does not perform any conversion; text converts every file; and auto tries to guess whether the file in question is a text file or a binary file. Auto does this by looking at the filename extension. If this extension is included in the list of "known binary extensions," it is not converted, otherwise it will be converted.

It is not advisable to use text, because this will invariable damage any binary files, including graphics files and files written by word processors, spreadsheets and other programs. Likewise, auto can be dangerous, because the extension-based detection mechanism is not very sophisticated. So we'd suggest you don't use the option. Stick with binary (the default) and convert your files on an as-needed basis.

If you want to access files on a Windows NT partition that carries an NTFS filesystem, you need another driver. Activate the option NTFS filesystem support during the kernel configuration. This lets you mount NTFS partitions by specifying the file system type ntfs. Note, however, that the current NTFS driver supports just read-only access. There is an alpha version of a driver available that supports writing as well, and so far, it has worked for us quite nicely, but we do not advise using this without backing up your NTFS partition first!

12.1.2. Using Samba to Mount Directories from Windows Systems on Your Network

So far, we have covered how to access Windows partitions on the same machine. In this section, we will extend this discussion to partitions (which in this context are often called shares) that reside on other servers. In Windows versions, starting with Windows for Workgroups, you can make directories or printers accessible for other computers. The protocol used for this feature is called SMB (Server Message Block). With the SMB support in Linux, you can access these directories from Linux. Note that the Windows machines must be configured to use TCP/IP in addition to or instead of the native Windows protocol NETBEUI, because the Linux SMB support does not include NETBEUI. Of course, your Linux machine must be set up for TCP/IP networking as well; see Chapter 15, "TCP/IP and PPP", to learn how to do that. For now, we will assume that a TCP/IP connection can be established between your Linux and your Windows computer.

In this section, we cover sharing in one direction: how to access files on Windows systems from Linux. The next section will show you how to do the reverse, and make selected files on your Linux system available to people on Windows systems.

In order to get SMB support running, you have to follow these steps:

Compile support for SMB into your kernel.

Install Samba (described in the next section) and create at least a minimal configuration file.

Mount the services with the smbmount command.

Let's go through these steps one at a time. The first one is easy: In the filesystems/Network File Systems section during kernel configuration, select SMB file system support (to mount WfW shares etc.). Compile and install your kernel, or install and load the module. If you plan to mount shares from a Windows 95 server, you should also select SMB Win95 bug work-around, which works around in bug in showing directories on a Windows 95 share. You don't need this if you are accessing shares only on a Windows 98 or Windows NT machine and should leave it off in this case because it slows down directory reading.

Next, you will need to install the Samba package. This package is meant for providing (not accessing) SMB shares, but its package contains one utility program and one configuration file you will need. If you do not have it on your machine (check whether the file /etc/smb.conf exists), please read the next section to learn how to get it.

You will learn about how to write the configuration file /etc/smb.conf in the next section, but for our purposes here, it suffices to have the following content:

[global]
socket options = TCP_NODELAY

There may be other configuration parameters in the [global] section; this parameter does not need to be the first. If you already have a smb.conf, there can be other socket options too. Don't let yourself be bothered by that; just make sure that you have the TCP_NODELAY option, as this speeds up directory reading a lot.

The last thing to do is to mount the partition (which in the Windows world is called a share). Unlike the partition types described in the last section and unlike the Network File System, you do not use the familiar mount command, but a special command from the Samba package called smbmount. This is because SMB shares have a different addressing scheme. Accordingly, you use smbumount for unmounting an SMB share.

If you are lucky, using smbmount can be quite easy. The general format is:

smbmount options servicename mount_point

where mount_point specifies a directory just as in the mount command. servicename follows more or less the Windows naming conventions, except that it replaces the backslashes with slashes. For example, if you want to mount a SMB share from the computer called winloser that is exported under the name mydocs onto the directory /windocs, you could use the following command:

tigger# smbmount //winloser/mydocs/ /windocs

You can also specify a directory below the exported root if you want to mount only a part of the share. For example, suppose we didn't want to share everything in the mydocs directory of the previous example, but just a subdirectory under it called htmldocs. We could say:

tigger# smbmount //winloser/mydocs/htmldocs /windocs

If a password is needed to access the share, smbmount will ask you for it.

As we previously wrote, if you are lucky, the preceding steps could be everything you need. But if you are unlucky, things could get messy here. If you do not know much about how Windows computers handle networking, you might want to seek help from the person who has set up the Windows machine where the files that you are trying to access are.

The most common problem is that in the SMB protocol, machines can have two different hostnames: the normal hostname and a NetBIOS name. While having two names might not be a good idea anyway, you will not be able to simply mount a SMB share with the previous commands if the two differ. If you know the NetBIOS name, you can pass it with the -s option:

tigger#smbmount -s nbname //winloser/mydocs/ /windocs

Another thing to try is to tell smbmount about the IP address of the machine exporting the SMB share. This is done with the -I option (see Chapter 15, "TCP/IP and PPP" to learn about IP addresses). If the server has the IP address 192.168.0.5, you could try the following command:

tigger# smbmount -I 192.168.0.5 //winloser/mydocs/ /windocs

Please see the manual page for smbmount for further tricks to try.

One problem with the smbmount command is that is does not really tell you what went wrong. For hints on what the problem is, try the utility program smbclient, which also comes from the Samba package. smbclient lets you copy files to and from a SMB share and list its directory contents, and it has the advantage of providing a little more detailed error messages. See the manual page for smbclient for further details. If you can access a SMB share with smbclient, but not with smbmount, it is very likely that either SMB support is not available in the kernel or that the mount point cannot be accessed, that is, that the problem has nothing to do with the network.

12.1.3. Using Samba to Serve SMB Shares

You probably want to access Linux files from Windows, in addition to accessing Windows files from Linux as we did in the previous section. For instance, a safe and popular networking strategy is to locate user's critical files in Unix home directories and serve them up to the users on their PCs.

A warning before you plunge into the wonderful world of Samba: NetBIOS, the underlying protocol for SMB, is quite complex, and because Samba has to deal with all those complexities, it provides a huge number of configuration options. Thus, if you are really serious about serving a department of 50 employees that use all kinds of Windows and perhaps even OS/2 machines, you are well advised to read the Samba documentation thoroughly and perhaps even read a good book about Samba.

That being said, I can reassure you that for the not-so-complex cases, setting up Samba is surprisingly easy, both as a file and as a print server. In addition, there is a small tool that helps you check your configuration file for errors.

Setting up Samba involves the following steps:

Compile and install the Samba programs if they are not already present on your system.
Write the Samba configuration file smb.conf and check it for correctness.
Start the two Samba daemons smbd and nmdb.

If you successfully set up your system, the directories you select will appear in the browse lists of the Windows users on your local network--normally accessed by clicking on the Network Neighborhood icon on Windows. The users on those systems will be able to read and write files according to your security settings just as they do on their local systems.

12.1.3.1. Installing Samba

Most Linux distributions nowadays contain Samba, and you can install it simply by choosing an option when installing Linux. If your distribution doesn't have Samba, you can get it from ftp://ftp.samba.org. It comes with installation instructions. Follow those instructions and build the package. During the configuration, you will have to decide where the configuration file smb.conf should reside. We will assume here that you pick /etc/smb.conf. If you choose a different location, you will have to substitute that location in the following description.

The next step is to create a smb.conf file that is suitable for your system. There are graphical configuration tools available for Samba, including the nifty, web-based SWAT (Samba Web Administration Tool), but as always, it's good to know what goes on under the hood in case the graphical configuration tools get things wrong.

Samba comes with several sample configuration files that you can simply take and adapt to your situation. But it is not difficult to write one from scratch, either. In this section, we will assume that you want to provide your unfortunate Windows colleagues with the home directories of your machine, your printers, and a CD-ROM drive mounted on /cdrom--a quite common setup.

The format of the smb.conf file is like the one used by Windows 3.x: there are entries of the type:

key = value

which are put into groups. A group starts with a line like the following:

[groupname]

Each directory or printer you share is called a service in Windows networking terminology. You can specify each service as a separate group name, but we'll show you some ways to simplify the configuration file and support lots of services in a few lines. One special group called [global] contains parameters that apply to all services. While Samba literally understands hundreds of parameters (keys), it is very likely that you will need to use only a few of them, because most of them have reasonable defaults. If you are curious which keys are available or are looking for a special parameter, you can check the manual page smb.conf.

For starters, we will now create a minimal smb.conf that looks as follows:

workgroup = your workgroup

[homes]
guest ok = no
read only = no

This does not do much yet, but it serves two purposes: You can check your Samba installation, and you can get used to a test tool called testparm that is used to check the validity of your smb.conf file.

We assume here that you have already started the Samba daemons as described later. If your distribution contains Samba, and you have opted to install it during the installation, this might already have been done for you.

You can now test your Samba installation by issuing a command like the following (replace TIGGER with the hostname of your computer in capitals):

tigger# nmblookup TIGGER
Added interface ip=192.168.0.3 bcast=192.168.0.255 nmask=255.255.255.0
Sending queries to 192.168.0.255
192.168.0.3 TIGGER

You should get an output similar to the previous example. If you don't get it, here are some things to check:

Check whether Samba can find your smb.conf file. If you installed Samba during the installation of your Linux system, you should check the documentation of your distribution for the location where the Samba package is looking for its configuration file. A common place is /etc/smb.conf, but others are possible as well. If you have compiled Samba yourself, you might have specified during the configuration where Samba should look for smb.conf and hopefully remember this location now. If you did not make any changes to the setup files while building and installing Samba, the configuration file is being searched for in /usr/local/samba/lib/smb.conf.

Check whether smbd and (more important for this test) nmbd are in fact running.
Samba might not have autodetected the network interface to use. Try adding a line like:
```
interfaces = your IP address
```
to your smb.conf file to tell Samba explicitly which interface to use.
nmbd might not be able to find out the NetBIOS name (which by default is the hostname in capitals). You can try stopping your nmbd and restarting it with the option -n, followed by the NetBIOS name.

Once you see a successful result from the nmblookup command, you can start to explore what you get from the sample smb.conf file we shipped. Short as it is, it's sophisticated enough to let Samba serve home directories. Check the service with the command smbclient, which is like a small FTP client for SMB servers. Try the following (replacing TIGGER with your hostname in capitals and kalle with your user name):

tigger$ smbclient \\\\TIGGER\\kalle
Added interface ip=192.168.0.3 bcast=192.168.0.255 nmask=255.255.255.0
Server time is Thu Mar 11 23:49:53 1999
Timezone is UTC+1.0
Password:
Domain=[THE TIGERS] OS=[Unix] Server=[Samba 1.9.16p10]
smb: \>

Samba asks for your password and then "logs you in" to your home directory. Since that's probably where you issued the smbclient command from anyway, you have not gained much, but now you know that your Samba installation really works, and you can continue tuning your installation.

The program testparm, checks your smb.conf for errors and inconsistencies. A run should look roughly as follows:

tigger$ testparm
Load smb config files from /etc/smb.conf
Processing section "[homes]"
Loaded services file OK.
Press enter to see a dump of your service definitions

testparm tells you where it is looking for the configuration file, which services it has found, and whether it has found any errors in the configuration file. If it does not report Loaded services file OK., it will tell you the errors so that you can correct them and try again.

After succeeding in reading the configuration file, testparm offers to show you all service definitions. This is a lengthy list of all services defined together with all their parameters, not only the parameters you specified, but also those that are defaulted. Since the output can be very, very long, we won't bother repeating it here, but it can be very useful for you to check whether the parameters are really as you expect them to be.

12.1.3.2. Configuring Samba

Now that you have a rudimentary Samba installation, we can look at a more full-blown smb.conf:

[global]
   workgroup = The tigers
   guest account = nobody
   keep alive = 30
   printing = bsd
   printcap name = /etc/printcap
   load printers = yes
   print command = /usr/bin/lpr -r -P%p %s
   lpq command = /usr/bin/lpq -P%p
   lprm command = /usr/bin/lprm -P%p %j
   preserve case = yes
   short preserve case = yes
   case sensitive = no

[homes]
   comment = Home directory
   browseable = yes
   read only = no
   create mode = 0750

[usr]
   comment = /usr
   browseable = yes
   read only = no
   create mode = 0750
   directory = /usr

[cdrom]
   comment = Linux CD-ROM
   path = /cdrom
   read only = yes
   locking = no

[printers]
   comment = All Printers
   browseable = yes
   printable = yes
   public = no
   read only = yes
   create mode = 0700
   directory = /tmp

We will not cover every single line here, but go through everything that is important for you to set up your own Samba server.

First, you need to know that there are three sections that are special: [global], [homes], and [printers]. Samba treats those sections slightly differently from the others. The section [global] contains parameters that apply to all services. For example, workgroup specifies the workgroup the Samba server is supposed to be in. If you have Windows networking experience, you might already know that in Windows networking, all computers belong to a certain workgroup and can access services only from computers in the same workgroup. Therefore, you have to make sure that you enter the same workgroup here as the one you entered on your Windows machines.

guest account is important only if you allow guest access to services. A guest is anyone on your network who has no account on your system; you may want to provide a special directory for them in the same way that some sites provide anonymous FTP access. In this case, the account specified here will provide the rights for the guest. keep alive specifies the interval in which the server checks whether a client connected to it is still alive and responding. This value can be between 0 (no checks) and 60 seconds. If your network is reliable enough, you can afford to set this to 0.

For now, we'll skip a few parameters that apply to printing services and cover them later. preserve case, short preserve case, and case sensitive specify how Samba should handle the fact that filenames on Unix systems are case sensitive while those on Windows are case insensitive. The settings shown in the previous example have proven very useful when you want to read and write files from both Unix and Windows, because they keep the case when saving (by default, everything would be saved with lowercase characters), but when looking for a file, matching is done without regard to case, as expected by Windows.

The following sections describe services that the Samba server provides to its clients. We'll start with [usr] and [cdrom] here, because those are straightforward entries applying to individual services. ([homes] and [printers] are special cases covering a number of services).

The group [usr] makes a directory available to Windows. In this case, the directory is named /usr, but naming the service after the directory is just an administrative convenience. Because the service is named usr, it will show up in the users' browse lists (Network Neighborhood) that way. You could also have named the service clinton by describing it in the group [clinton], but in that case the service would be announced as clinton to the clients in the Network Neighborhood window.

To make sure our share is visible in the browse list, we have set the value of the browsable parameter to yes. If we had not set this, you could still access the service, but you would have to know what it is called and could not access it via the browse list. read only specifies, of course, whether the clients may write to the directory tree provided by this service. Note that even if this value is no, users still need the usual Unix permissions to be able to read and write anything from that service. create mode specifies the permissions that files newly created by a client on this service will get. directory specifies the root of the directory tree to be exported by this service. Note that whether it is useful to export /usr to Windows machines depends on what you have stored there. If you keep only Linux programs and their utility files there, this is not useful, of course. Finally, comment specifies a string that is shown in the Properties dialog in Windows or in the detail view.

The service cdrom makes the Linux CD-ROM drive accessible to Windows clients. It has about the same format as usr, but of course specifies read only = yes, because you cannot write to a CD-ROM. locking = no means that Samba will not use locks to prevent one user from overwriting the files of another user; in this case the value makes sense because nobody can write to a CD-ROM and locking wastes time.

Now let's go to the more interesting sections. The section [homes] is special, because it does not describe a single service but a number of possible services. Use it to give each of your users a directory of his own that can be accessed from Windows systems on your LAN.

Each user to whom you want to offer a directory should have an account on your system; to make configuration easy, make the account name and the home directory the same as the login name the user has on the Windows network. All you need after that is a properly configured Samba with a [homes] section like the one shown in our example.

Whenever a user on a Windows client connects to the service, Samba checks the user name and asks for the password (which is then entered in a Windows dialog) and provides the home directory of the user. Thus, when a connection is set up, Samba creates a so-called virtual service for the home directory of the user in question. This is very useful, because you do not have to tell Samba explicitly about new users when you add them to your Unix system: once a user account is created and has a home directory, the user can access this home directory from Windows.

This leaves us with the printing services. You can configure each printer that is configured on your Linux box separately, but in general, it is much easier to use the [printers] section. Just as [homes] specifies a number of file access services (each home directory), [printers] specifies a number of printing services: access is allowed to each printer configured in /etc/printcap. As explained in "Section 8.4, "Managing Print Services"" in Chapter 8, "Other Administrative Tasks", the printcap file lists all the printers on your system and how they are accessed.

For the [printers] section to work, you need to set load printers = yes in the [global] section, which tells Samba to read /etc/printcap to see which printers are available. Other important values in the global section with respect to printing are printing, which specifies the type of printer service your Linux box uses (normally bsd, the default) and printcap name, which tells Samba where your printer capabilities or printcap file is located. On Linux, the printer capabilities files is almost always /etc/printcap, which is also the default used by Samba. If you use the alternative LPRng printing system, you must specify lprng here. There are other possibilities that are less likely to be used on Linux listed in the smb.conf manual page.

You also need to specify in the [global] section which commands Samba can use to send files to the printer. These commands are simply those that would be issued on the command line by a user on your system, with placeholders (macros) beginning with % to refer to filenames and other changing parameters. The values shown in the example are crafted for a BSD printing system and are probably useful for you, too. They make use of a number of macros that Samba expands automatically when reading the configuration file: %p specifies the printer name, %s the name of the file to print and %j the job number of the print job. For more macros, please see the smb.conf manual page.

Most parameters in the [printers] section have already been explained, but there remains a very important one: printable = yes tells Samba that this section specifies printing services and not file services. Printer services should always be set to read-only, otherwise malicious users could interfere with other users' print jobs. The directory parameter specifies where Samba should store the temporary printing files.

Note that setting up the printing service on the Samba side is not enough to be able to print from Windows. You also need to configure a printer on all Windows clients and use a suitable printer driver for the printer in question. Samba supports the automatic installation of printer drivers onto Windows 95 and Windows 98 machines; read the manual page smb.conf for further details (look for the printer driver file option).

After you have made changes to your Samba configuration file, it is always a good idea to check the syntax with testparm, at least to ensure you haven't introduced a spelling or syntax error. You will probably also want to look at the values testparm outputs for all the parameters. There is also a tiny program called testprns that checks the validity of printer names, but it is not as helpful as testparm.

Normally, the Samba daemons smbd and nmbd should automatically reread the configuration file when it has been changed, but this does not always work correctly. You can always send the daemons the HUP signal to make them reread the smb.conf file, though:

tigger# killall -HUP smbd
tigger# killall -HUP nmbd

We have covered only a small number of the hundreds of options that Samba provides, but with the facts given here, you should already be able to set up file and printing services for Windows clients for a lot of situations, and you can always read up on further details in the Samba documentation.

12.1.3.3. Starting Samba

Depending on your distribution, there may already be a script to start the Samba service. In this case, it is best to use that script. For example, on Red Hat systems, you can start the Samba server (provided that you have installed the Samba package) with:

tigger# /etc/rc.d/smb start

and shut it down with:

tigger# /etc/rc.d/smb stop

On SuSE, the smb daemon is located by default in /sbin/init.d/smb instead of /etc/rc.d/smb, on Debian, it is /etc/init.d/samba.

If you have installed Samba yourself, you have two options. You can either have the Samba daemons started by inetd or simply start them from the command line.

Since the latter is used more often and is better for testing, we describe that option here. The manual pages for smbd and nmbd describe how to use inetd.

To run Samba from the command line, simply start the daemon by entering the following commands (assuming that you have installed the Samba daemons in /usr/sbin):

tigger# /usr/sbin/nmbd
tigger# /usr/sbin/smbd

Once you know that your Samba server works, you should start the daemons with the option -D which tells them to detach themselves from the shell they were started from, the normal mode of operation for a daemon:

tigger# /usr/sbin/nmbd -D
tigger# /usr/sbin/smbd -D

This also allows you to close the shell without killing the daemons.

The Samba daemons have a number of other options, but you can probably do without them; if necessary, you will find all the information in the manual pages. We have only touched the surface here of what Samba can do, but this should already give you an impression why Samba--despite being not specifically developed for Linux--is one of the software packages that have made Linux famous.

12.1.4. Utilities for Accessing DOS Filesystems: MTools

Most Linux users who want to run Linux programs on Windows files can do so simply by mounting their Windows partitions as we described earlier in the section "Section 12.1.1, "Mounting DOS, VFAT, and NTFS Partitions"." Once you set up the mount correctly, you can use standard shell commands to move around in the directories and run vi, Perl scripts, or whatever other programs you know and love.

Before Linux contained support for nonnative file systems, a set of programs called MTools was quite important. It was a collection of simple commands that let you manipulate Windows directories and files while running Linux. Now, the main use we've found for MTools is to access Windows-formatted floppy disks, because MTools remove the need to mount the floppy disk just to read a file from it. Using Windows-formatted floppy disks can be a very useful and efficient way to transport smaller amounts of data from a Windows machine to a Linux machine and back if the two are not networked.

Here are summaries of the MTools utilities; they are further documented in manual pages that are part of the distribution:

mattrib: Changes attributes of a Windows file
mcd: Changes to a Windows directory
mcopy: Copies files from Linux to Windows or from Windows to Linux
mdel: Deletes a Windows file
mdir: Displays a Windows directory
mformat: Creates a Windows FAT filesystem on a floppy
mlabel: Writes a Windows disk volume label to a Windows partition
mmd: Creates a Windows directory
mrd: Removes a Windows directory
mread: Reads a Windows file to Linux
mren: Renames a Windows file
mtype: Displays the contents of a Windows file
mwrite: Writes a Linux file to Windows

12.1.5. File Translation Utilities

As we already mentioned, one of the most prominent problems when it comes to sharing files between Linux and Windows is that the two systems have different conventions for the line endings in text files. Luckily, there are a few ways to solve this problem:

If you access files on a mounted partition on the same machine, let the kernel convert the files automatically as described in the section "Section 12.1.1, "Mounting DOS, VFAT, and NTFS Partitions"" earlier in this chapter. Use this with care!
Sophisticated editors like Emacs can handle the conversion automatically at either load or save time for you.
There are a number of small tools available that convert files from one line-end convention to the other. Some of these tools can also handle other conversion tasks as well.

We will look here at two of the small utilities mentioned here: duconv and recode.

duconv is a tiny program available with most distributions that converts the line-ends and can also convert some special characters used in European languages from their DOS encoding to their Unix encoding. Note that the latter is not necessary with text files written on newer versions of Windows (like Windows 95 and Windows 98), because Windows uses the same encoding for those special characters as Unix does, the international standard ISO Latin-1, also known as ISO 8859-1.

In order to convert a Windows text file to a Unix text file, call duconv as follows:

duconv -u dos_text_file unix_text_file

To convert the other way around (from Unix to Windows), use the option -d:

duconv -d unix_text_file dos_text_file

duconv is a nice little utility, but if you need something more full-blown, you should go for the GNU project's recode. This is a program that can convert just about any text-file standard to any other text-file standard. recode isn't as easy to use as duconv, however.

The normal way to use recode is to specify both the old and the new character sets (encodings of text file conventions) and the file to convert. recode will overwrite the old file with the converted one; it will have the same file name. For example, in order to convert a text file from Windows to Unix, you would enter:

recode ibmpc:latin1 textfile

textfile is then replaced by the converted version. You can probably guess that to convert the same file back to Windows conventions, you would use:

recode latin1:ibmpc textfile

In addition to ibmpc (as used on Windows) and latin1 (as used on Unix), there are other possibilities available, among others latex for the LaTeX style of encoding diacritics (see Section 9.3.1, "TeX and LaTeX") and texte for encoding French email messages. You can get the full list by issuing:

recode -l

If you do not like recode 's habit of overwriting your old file with the new one, you can make use of the fact that recode can also read from standard input and write to standard output. To convert dostextfile to unixtextfile without deleting dostextfile, you could do:

recode ibmpc:latin1 < dostextfile > unixtextfile

With the two tools just described, you can handle text files quite comfortably, but this is only the beginning. Things are less easy when it comes to other files. For example, pixel graphics on Windows are usually saved as bmp files, which are very uncommon on Unix. Fortunately, there are a number of tools available that can convert bmp files to graphics file formats like xpm that are more common on Unix. Among these are the shareware image viewer and manipulation package xv, which is probably included with your distribution.

Things become even more hairy when it comes to proprietary file formats like those saved by office productivity programs. While the various incarnations of the doc file format of the Word for Windows word processor have become a de facto lingua franca for word processor files on Windows, until recently, it was hardly possible to read those files on Linux. Fortunately, a number of software packages have appeared lately that can read (and sometimes even write) those files. Among those are the word processor WordPerfect, the office productivity suite StarOffice, and the office productivity suite ApplixWare. Be aware though, that these conversions will never be perfect; it is very likely that you will have to edit the files by hand afterwards.

In general, the more common a file format is on Windows, the more likely it is that Linux developers will provide a means to read or even write those file formats as well. This might also be a good occasion to switch to open file formats like RTF (Rich Text Format) or XML (Extensible Markup Language) when you're on Windows, too. In the age of the Internet, where information is supposed to float freely, closed, nondocumented file formats are an anachronism.