Chapter 12. Windows
Compatibility
and Samba

Contents:

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.

Samba is the package that lets you access Unix files and printers
from Windows, and it is one of the most famous
Open Source programs of all. People have found that Unix
servers running Samba can--depending on the
circumstances--serve Windows computers faster than even
Windows servers can! In addition, Samba has proven to be very
stable and reliable.

We use the term Windows somewhat generically in
this chapter to refer to any of the DOS-based
operating systems coming from
Microsoft or those compatible with them, like
MS-DOS, PC-DOS, and
DR-DOS/Novell DOS (all with or
without Windows 3.x running on top of them), as well as the various
Windows versions themselves, no matter whether they build upon a
separate DOS installation like the venerable
Windows 3.x or whether they have a DOS kernel built
in like Windows 95 and Windows 98. It should be added that Windows
NT/2000 is a completely different animal; many of the things described
here will not work with these, or will work differently. Your mileage
may vary.

Some of these utilities work well, while others are perhaps "not ready
for prime time." These tools allow many who otherwise
couldn't find out about Linux to try it out without first abandoning their
reliable working platform or without buying a second computer to play with.

You should be a little skeptical of some dreams of compatibility though.
Just because something can be done, doesn't mean it is a great idea. As a
practical matter, you might find, for example, that you need twice the disk
storage in order to support two operating systems and their associated files and
applications programs, plus file conversion and graphic-format conversion
tools, and so on. You may find that hardware tuned for one OS won't be tuned
for the other, and you will have to choose where to spend your cash.

If you find yourself stuck with a piece of hardware that you would
like to use because of its Windows support (like a
USB device), but for which there are no Linux
drivers yet, do not despair.
The desire to have everything will probably continue to drive Linux
developers, so we confidently expect that for each hardware device
that is supported on Windows, there will at one point
or other be a driver for Linux, too. For example, there is already
work going on with respect to USB
devices; see http://video.komm.hdk-berlin.de/~rasca/uusbd-utils/
for more information.

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.

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 optionsservicenamemount_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):

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):

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:

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:

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:

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_fileunix_text_file

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

duconv -d unix_text_filedos_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.