As we showed you in the previous section, it is possible to use the MTools utilities to access a DOS-formatted hard disk partition, and you can even mount a DOS-formatted disk onto the Linux file system with mmount. These methods can be used on a dual-boot system containing a MS-DOS partition, but there’s a better way.
As we’ve explained in section Section 6.1.2 in Chapter 6, partitions on local hard disks are accessed by mounting them onto a directory in the Linux file system. In order to be able to read and write to a specific filesystem, the Linux kernel needs to have support for it.
Linux has filesystem drivers that 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 also can read (and with some caveats) write to the NTFS filesystem of Windows NT/2000/XP.
In Section 7.4 in Chapter 7, 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/98/ME) partitions, you need to enable DOS FAT fs support in the File systems 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 FAT32 partitions.
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 a version of this driver
available that supports writing as well, but at the time of this
writing, it was still under development, and not guaranteed to work
reliably when writing to the NTFS partition. Read the documentation
carefully before installing and using it!
While Linux is running, you can mount a Windows partition like any
other type of partition. For example, if the third partition on your
first IDE hard disk contains your Windows 98 installation, you can
make the files in it accessible with the following command, which
must be executed as root
:
# mount -t vfat /dev/hda3 /mnt/windows98
The
/dev/hda3 argument specifies the disk drive
corresponding to the Windows 98 disk, while the
/mnt/windows98 argument 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/hda3
? If
you’re familiar with the naming conventions for
Linux filesystems, you’ll know that
hda3
is the third partition on the hard disk
that is the master on the primary IDE port. You’ll
find life easier if you write down the partitions while you are
creating them with fdisk
, but if you neglected
to do that, you can run fdisk
again to view the
partition table.
The filesystem drivers support a number of options that can be
specified with the -o option of the
mount command. The mount(8)
manual page documents the options that can be used, with sections
that explain options specific to the fat and
ntfs filesystem types. The section for
fat
applies to both the msdos
and vfat filesystems, and there are two options
listed there that are of special interest.
The check option determines whether the kernel
should accept filenames that are not permissible on MS-DOS and what
it should do with them. 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 doesn’t 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, and also removes 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
This option is used with msdos filesystems only; the restrictions on filename length do not apply to vfat filesystems.
The conv option can be useful, but not as
commonly as you might at first think. Windows and Unix systems have
different conventions for how a line ending is marked in text files.
Windows uses both a carriage return and a linefeed character, while
Unix only uses a 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, pass the mount
command the option conv, which 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 generally 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 suggest you don’t use the conv option, unless you are sure the partition contains only text files. Stick with binary (the default) and convert your files manually on an as-needed basis. See Section 12.2.3 later in this chapter for directions on how to do this.
As with other filesystem types, you can mount MS-DOS and NTFS
filesystems automatically at system bootup by placing an entry in
your /etc/fstab
file. For example, the following
line in /etc/fstab
mounts a Windows 98 partition
onto /win
:
/dev/hda1 /win vfat defaults,umask=002,uid=500,gid=500 0 0
When accessing any of the msdos, vfat or ntfs filesystems from Linux, the system must somehow assign Unix permissions and ownerships to the files. By default, ownerships and permissions are determined using the UID and GID, and umasking of the calling process. This works acceptably well when using the mount command from the shell, but when run from the boot scripts, it will assign file ownerships to root, which may not be desired. In the above example, we use the umask option to specify the file and directory creation mask the system will use when creating files and directories in the filesystem. The uid option specifies the owner (as a numeric UID, rather than a text name), and the gid option specifies the group (as a numeric GID). All files in the filesystem will appear on the Linux system as having this owner and group. Since dual-boot systems are generally used as workstations by a single user, you will probably want to set the uid and gid options to the UID and GID of that user’s account.
When you have Linux and Windows running on separate computers that are networked, you can share files between the two. The built-in networking support in Windows uses Microsoft’s Server Message Block (SMB) protocol, which is also known as Common Internet File System (CIFS) protocol. Linux has support for SMB protocol by way of Samba and the Linux smbfs filesystem.
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, to make selected files on your Linux system available to Windows clients.
The utilities smbmount and smbmnt from the Samba distribution work along with the smbfs filesystem drivers to handle the communication between Linux and Windows, and mount the directory shared by the Windows system onto the Linux file system. In some ways, it is similar to mounting Windows partitions, which we covered in the previous section, and in other ways similar to mounting an NFS filesystem.
This is all done without adding any additional software to Windows, because your Linux system will be accessing the Windows system the same way other Windows systems would. However, it’s important that you run only TCP/IP protocol on Windows, and not NetBEUI or Novell (IPX/SPX) protocols. Although it is possible for things to work if NetBEUI and/or IPX/SPX are in use, it is much better to avoid them if possible. There can be name resolution conflicts and other similar problems when more than TCP/IP is in use.
TCP/IP protocol on your Windows system should be configured properly, with an IP address and netmask. Also, the workgroup (or domain) and computer name of the system should be set. A simple test is to try pinging the Windows system from Linux, using its computer name (hostname), in a matter, such as:
$ ping maya
PING maya.metran.cx (172.16.1.6) from 172.16.1.3 : 56(84) bytes of data.
64 bytes from maya.metran.cx (172.16.1.6): icmp_seq=2 ttl=128 time=362 usec
64 bytes from maya.metran.cx (172.16.1.6): icmp_seq=3 ttl=128 time=368 usec
--- maya.metran.cx ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.344/0.376/0.432/0.038 ms
This shows that Linux is able to contact maya
, the
Windows server, and that name resolution and basic TCP/IP
communication are working.
For now, we will assume that a TCP/IP connection can be established between your Linux and Windows computers, and that there is a directory on the Windows system that is being shared. Detailed instructions on how to configure networking and file sharing on Windows 95/98/Me and Windows NT/2000/XP can be found in Using Samba by Robert Eckstein and David Collier-Brown (O’Reilly).
On the Linux side, the following three steps are required:
Your Linux distribution may come with smbfs and Samba already installed, but in case it doesn’t, let’s go through the above 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.
Next, you will need to install the smbmount and smbmnt utilities from Samba package. You can install Samba according directions in the next section, or if you already have Samba installed on a Linux system, you can simply copy the commands from there. You also may want to copy over some of the other Samba utilities, such as smbclient and testparm.
The smbmount program is meant to be run from the command line, or by mount when used with the -t smbfs option. Either way, smbmount calls smbmnt, which performs the actual mounting operation. While the shared directory is mounted, the smbmount process continues to run, and if you do a ps ax listing, you will see one smbmount process for each mounted share.
The smbmount program reads the Samba configuration file, although it doesn’t need to gather much information from it. In fact, you may be able to get by with a configuration file that is completely empty! The important thing is to make sure the configuration file exists in the correct location, or you will get error messages. To find the location of the configuration file, run the testparm program. (If you copied the two utilities from another Linux system, run testparm on that system.) The first line of output identifies the location of the configuration file, as in this example:
$testparm
Load smb config files from /usr/local/samba/lib/smb.conf... deleted ...
You will learn more about writing the configuration file in the next section, but for our purposes here, it suffices to have the following content:
[global]
workgroup = NAME
Simply replace NAME
with the name of your
workgroup, as it is configured on the Windows systems on your
network.
The last thing to do is to mount the shared directory. Using smbmount can be quite easy. The command synopsis is:
smbmountshare_name
mount_point options
where mount_point
specifies a directory
just as in the mount command.
servicename follows the Windows Universal Naming
Convention (UNC) format, except that it replaces the backslashes with
slashes. For example, if you want to mount a SMB share from the
computer called maya
that is exported under the
name mydocs
onto the directory
/windocs
, you could use the following command:
# smbmount //maya/mydocs/ /windocs
If a username and/or password is needed to access the share, smbmount will prompt you for them. Now let’s consider a more complex example of an smbmount command:
#smbmount //maya/d /maya-d/
-o credentials=/etc/samba/pw,uid=jay,gid=jay,fmask=600,dmask=700
In this example, we are using the -o
option to
specify options for mounting the share. Reading from left to right
through the option string, we first specify a credentials file, which
contains the username and password needed to access the share. This
avoids having to enter them at an interactive prompt each time. The
format of the credentials file is very simple:
username=USERNAME
password=PASSWORD
where USERNAME
and
PASSWORD
are replaced by the username and
password needed for authentication with the Windows workgroup server
or domain. The uid and gid
options specify the owner and group to apply to the files in the
share, just as we did when mounting a MS-DOS partition in the
previous section. The difference is that here, we are allowed to use
either the username and group names or the numeric UID and GID. The
fmask and dmask options
allow permission masks to be logically ANDed with whatever
permissions are allowed by the system serving the share. For further
explanation of these options and how to use them, see the
smbmount(8) manual page.
One problem with smbmount is that when the attempt to mount a shared directory fails, it does not really tell you what went wrong. To diagnose the problem, try accessing the share with smbclient, which also comes from the Samba package. smbclient lets you list the contents of a shared directory and copy files to and from it, and has the advantage of providing a little more detailed error messages. See the manual page for smbclient(1) for further details.
Once you have succeeded in mounting a shared directory using
smbmount, you may want to add an entry in your
/etc/fstab
file to have the share mounted
automatically during system boot. It is a simple matter to reuse the
arguments from the above smbmount command to
create an /etc/fstab
entry such as the
following:
//maya/d /maya-d smbfs/ credentials=/etc/samba/pw,uid=jay,gid=jay,fmask=600,dmask=700 0 0
Now that you can mount shared Windows directories on your Linux system, we will discuss networking in the other direction — serving files stored on Linux to Windows clients on the network. This also is done using Samba.
Samba can be used in many ways, and is very scalable. You might want to use it just to make files on your Linux system available to a single Windows client (such as when running Windows in a virtual machine environment on a Linux laptop). Or, you can use Samba to implement a reliable and high-performance file and print server for a network containing thousands of Windows clients.
A warning before you plunge into the wonderful world of Samba: the SMB protocol is quite complex, and because Samba has to deal with all those complexities, it provides a huge number of configuration options. In this section, we will show you a simple Samba setup, using as many of the default settings as we can. If you are really serious about supporting a large number of users that use multiple versions of Windows, or using more than Samba’s most basic features, you are well advised to read the Samba documentation thoroughly and perhaps even read a good book about Samba, such as O’Reilly’s Using Samba.
Setting up Samba involves the following steps:
Compiling and installing Samba, if it is not already present on your system.
Writing the Samba configuration file smb.conf
and checking it for correctness.
Starting the two Samba daemons smbd and nmbd.
If you successfully set up your Samba server, it and the directories you share will appear in the browse lists of the Windows clients on your local network — normally accessed by clicking on the Network Neighborhood or My Network Places icon on the Windows desktop. The users on the Windows client systems will be able to read and write files according to your security settings just as they do on their local systems or a Windows server. The Samba server will appear to them as another Windows system on the network, and act almost identically.
There are two ways in which Samba may be installed on a Linux system:
From a binary package, such as Red Hat’s RPM (also used with SuSE and some other distributions), or Debian’s .deb package formats
By compiling the Samba source distribution
Most Linux distributions include Samba, allowing you to install it simply by choosing an option when installing Linux. If Samba wasn’t installed along with the operating system, it’s usually a fairly simple matter to install the package later. Either way, the files in the Samba package will usually be installed as follows:
Daemons in /usr/sbin
Command-line utilities in /usr/bin
Configuration files in /etc/samba
Log files in /var/log/samba
There are some variations on this. For example, in older releases,
you may find log files in /var/log, and the Samba
configuration file in /etc
.
If your distribution doesn’t have Samba, you can
download the source code, and compile and install it yourself. In
this case, all of the files that are part of Samba are installed
into
subdirectories of /usr/local/samba
.
Either way, you can take a quick look in the directories just mentioned to see if Samba already exists on your system, and if so, how it was installed.
If you are not the only system administrator of your Linux system, be careful. Another administrator might have used a source code release to upgrade an earlier version that was installed from a binary package, or vice-versa. In this case, you will find files in both locations, and it may take you a while to determine which installation is active.
If you need to install Samba, you can either use one of the packages created for your distribution, or install from source. Installing a binary release may be convenient, but Samba binary packages available from Linux distributors are usually significantly behind the most recent developments. Even if your Linux system already has Samba installed and running, you might want to upgrade to the latest stable source code release.
To install from source, go to the Samba web site at http://www.samba.org, and click on one of the
links for a download site nearest you. This will take you to one of
the mirror sites for FTP downloads. The most recent stable source
release is contained in the file
samba-latest.tar.gz
. After downloading this
file, unpack it and then read the file
docs/htmldocs/UNIX_INSTALL.html
from the
distribution. This file will give you detailed instructions on how to
compile and install Samba. Briefly, you will use the following
commands:
$tar xvfz samba-latest.tar.gz
$cd samba-
VERSION
$su
Password: #./configure
#make
#make install
Make sure to become superuser before running the
configure
script. Samba is a bit more demanding
in this regard than most other Open Source packages you may have
installed. After running the above commands, Samba files can be found
in the
following
locations:
Executables in /usr/local/samba/bin
Configuration file in /usr/local/samba/lib
Log files in /usr/local/samba/log
smbpasswd file in /usr/local/samba/private
Manual pages in /usr/local/samba/man
You will need to add the /usr/local/samba/bin
directory to your PATH environment variable to be able to run the
Samba utility commands without providing a full path. Also, you will
need to add the following two lines to your
/etc/man.config
file to get the
man command to find the Samba manual pages:
MANPATH /usr/local/samba/man MANPATH_MAP /usr/local/samba/bin /usr/local/samba/man
The next step is to create a Samba configuration file for your system. Many of the programs in the Samba distribution read the configuration file, and although some of them can get by with minimal information from it (even an empty file), the daemons used for file sharing require that the configuration file be specified in full.
The name and location of the Samba configuration file depends on how
Samba was compiled and installed. An easy way to find it is to use
the testparm command, as we showed you in the
section on mounting shared directories earlier in this chapter.
Usually, the file is called smb.conf
, and
we’ll use that name for it from now on.
The format of the smb.conf
file is like that of
the .ini files used by Windows 3.x: there are
entries of the type:
key
=value
When working with Samba, you will almost always see the keys referred to as parameters or options. Parameters are put into sections, which are introduced by labels made of the name of the section in square brackets. This section name goes by itself on a line, like this:
[section-name
]
Each directory or printer you share is called a
share or service in
Windows networking terminology. You can specify each service
individually using a separate section name, but
we’ll show you some ways to simplify the
configuration file and support many services using just a few
sections. One special section called [global]
contains parameters that apply as defaults to all services, and
parameters that apply to the server in general. While Samba
understands literally hundreds of parameters, it is very likely that
you will need to use only a few of them, because most have reasonable
defaults. If you are curious which parameters are available, or you
are looking for a specific parameter, read the manual page for
smb.conf
(5). But for now, let’s
get started with the following
smb.conf
file:
[global] workgroup = METRAN encrypt passwords = yes wins support = yes local master = yes [homes] browsable = no read only = no map archive = no [printers] printable = yes printing = BSD path = /var/tmp [data] path = /export/data read only = no map archive = no
Although this is a very simple configuration, you may find it satisfactory for most purposes. We’ll now explain each section in the file in order of appearance, so you can understand what’s going on, and make the changes necessary for it to fit your own system. The parts you most likely need to change are emphasized in boldface.
In the [global]
section, we are setting parameters that
configure Samba on the particular host system. The
workgroup
parameter defines the workgroup to which
the server belongs. You will need to replace METRAN with the name of
your workgroup. If your Windows systems already have a workgroup
defined, use that workgroup. Or if not, create a new workgroup name
here and configure your Windows systems to belong to it. Use a
workgroup name other than the Windows default of WORKGROUP, to avoid
conflicts with misconfigured or unconfigured systems.
For our server’s computer name (also called NetBIOS name), we are taking advantage of Samba’s default behavior of using the system’s hostname. That is, if the system’s fully-qualified domain name is dolphin.example.com, it will be seen from Windows as dolphin. Make sure your system’s hostname is set appropriately.
The encrypt passwords
parameter tells Samba to
expect clients to send passwords in
“encrypted” form, rather than
plaintext. This is necessary in order for Samba to work with Windows
98, Windows NT Service Pack 3, and later versions. If you are using
Samba version 3.0 or later, this line is optional, because newer
versions of Samba default to using encrypted passwords.
The wins support
parameter tells Samba to function
as a WINS server, for resolving computer names into IP addresses.
This is optional, but helps to keep your network running efficiently.
The local master
parameter is also optional. It
enables Samba to function as the master browser on the subnet,
keeping the master list of computers acting as SMB servers, and their
shared resources. Usually, it is best to let Samba accept this role,
rather than let it go to a Windows system.
The rest of the sections in our example smb.conf
are all optional, and define the resources Samba offers to the
network.
The [homes
] share tells Samba to automatically share
home directories. When clients connect to the Samba server, Samba
looks up the username of the client in the Linux
/etc/passwd
file, to see if the user has an
account on the system. If the account exists, and has a home
directory, the home directory is offered to the client as a shared
directory. The username will be used as the name of the share (which
appears as a folder on a Windows client). For example, if a user
diane
, who has an account on the Samba host,
connects to the Samba server, she will see that it offers her home
directory on the Linux system as a shared folder named
diane
.
The parameters in the [homes]
section define how
the home directories will be shared. It is necessary to set
browsable = no
to keep a shared folder named
homes from appearing in the browse list. By
default, Samba offers shared folders with read-only permissions.
Setting read only = no
causes the folder and its
contents to be offered read/write to the client. Setting permissions
like this in a share definition does not change any permissions on
the files in the Linux filesystem, but rather acts to apply
additional restrictions. A file that has read-only permissions on the
server will not become writable from across the network as a result
of read only
being set to no
.
Similarly, if a file has read/write permissions on the Linux system,
Samba’s default of sharing the file read-only
applies only to access by Samba’s network clients.
Samba has the sometimes difficult job of making a Unix filesystem
appear like a Windows filesystem to Windows clients. One of the
differences between Windows and Unix filesystems is that Windows uses
the archive attribute to tell backup software whether a file has been
modified since the previous backup. If the backup software is
performing an incremental backup, it backs up only files that have
their archive bit set. On Unix, this information is usually inferred
from the file’s modification timestamp, and there is
no direct analog to the archive attribute. Samba mimics the archive
attribute using the Unix file’s execute bit for
owner. This allows Windows backup software to function correctly when
used on Samba shares, but has the unfortunate side-effect of making
data files look like executables on your Linux system. We set the
map archive
parameter to no
because we expect that you are more interested in having things work
right on your Linux system than being able to perform backups using
Windows applications.
The [printers]
section tells Samba to make printers
connected to the Linux system available to network clients. Each
section in smb.conf
, including this one, that
defines a shared printer must have the parameter printable = yes
. In order for a printer to be made available, it must
have an entry in the Linux system’s
/etc/printcap
file. As explained in Section 8.4 in Chapter 8, the printcap
file lists
all the printers on your system and how they are accessed. The
printer will be visible to users on network clients with the name it
is listed by in the printcap
file.
If you have already configured a printer for use, it may not work properly when shared over the network. Usually, when configuring a printer on Linux, the print queue is associated with a printer driver that translates data it receives from applications into codes that make sense to the specific printer in use. However, Windows clients have their own printer drivers, and expect the printer on the remote system to accept raw data files that are intended to be used directly by the printer, without any kind of intermediate processing. The solution is to add an additional print queue for your printer (or create one, if you don’t already have the printer configured) that passes data directly to the printer. This is sometimes called “raw mode”.
The first time the printer is accessed from each Windows client, you
will need to install the Windows printer driver on that client. The
procedure is the same as when setting up a printer attached directly
to the client system. When a document is printed on a Windows client,
it is processed by the printer driver, and then sent to Samba. Samba
simply adds the file to the printer’s print queue,
and the Linux system’s printing system handles the
rest. Historically, most Linux distributions have used BSD-style
printing systems, and so we have set printing = BSD
to notify Samba that the BSD system is in use. Samba
then acts accordingly, issuing the appropriate commands that tell the
printing system what to do. More recently, some Linux distributions
have used the LPRng printing system or CUPS. If your distribution
uses LPRng, set printing = LPRNG
. If it uses CUPS,
then set printing = CUPS
, and also set
printcap
name = CUPS
.
We have set the path
parameter to
/var/tmp
to tell Samba where to temporarily put
the binary files it receives from the network client, before they are
added to the print system’s queue. You may use
another directory if you like. The directory must be made
world-writable, to allow all clients to access the printer.
The [data]
share in our example shows how to share a
directory. You can follow this example to add as many shared
directories as you want, by using a different section name and value
for pat
h for each share. The section name is used
as the name of the share, which will show up on Windows clients as a
folder with that name. As in previous sections, we have used read
only = no to allow read/write access to the share, and map archive =
no to prevent files from having their execute bits set. The path
parameter tells Samba what directory on the Linux system is to be
shared. You can share any directory, but make sure it exists and has
permissions that correspond to its intended use. For our
[data]
share, the directory
/export/data
has read, write and execute
permissions set for all of user, group and other, since it is
intended as a general-purpose shared directory for everyone to use.
After you are done creating your smb.conf
file,
run the testparm program, which
checks your
smb.conf
for errors and inconsistencies. If your
smb.conf
file is correct,
testparm should report satisfactory messages,
as
follows:
$ testparm
Load smb config files from /usr/local/samba/lib/smb.conf
Processing section "[homes]"
Processing section "[printers]"
Processing section "[data]"
Loaded services file OK.
Press enter to see a dump of your service definitions
If you have made any major errors creating the
smb.conf
file, you will get error messages mixed
in with the output shown. You don’t need to see the
dump of service definitions at this point, so just type CTRL-C
to
exit testparm.
Network
clients must be authenticated by Samba
before they can access shares. The configuration we are using in this
example uses Samba’s
“user-level” security, in which
client users are required to provide a username and password that
must match those of an account on the Linux host system. The first
step in adding a new Samba user is to make sure that the user has a
Linux account, and if you have a [homes]
share in
your smb.conf
, that the account has an existing
home directory.
In addition, Samba keeps its own password file, which it uses to validate the encrypted passwords that are received from clients. For each Samba user, you must run the smbpasswd command to add a Samba account for that user:
#smbpasswd -a
username
New SMB password: Retype new SMB password:
Make sure that the username and password you give to smbpasswd are both be the same as those of the user’s Linux account. We suggest you start off by adding your own account, which you can use a bit later to test your installation.
The Samba distribution includes two daemon programs, smbd and nmbd , that must both be running in order for Samba to function. Starting the daemons is simple:
#smbd
#nmbd
Assuming your smb.conf
file is error-free, it is
rare for the daemons to fail to run. Still, you might want to run a
ps ax command and check that they are in the
list of active processes. If not, take a look at the Samba log files,
log.smbd
and log.nmbd
, for
error messages. To stop the daemons, you can use the
killall command to send them the SIGTERM signal:
# killall -TERM smbd nmbd
Once you feel confident that your configuration is correct, you will probably want the Samba daemons to start up during system boot, along with other system daemons. If you are using a binary release of Samba, there is probably a script provided in the /etc/init.d directory that will start and stop Samba. For example, on Red Hat and SuSE Linux, Samba can be started with the following command:
# /etc/init.d/smb start
The smb script can also be used to stop or
restart Samba, by replacing the start
argument
with stop or restart. The name and location of
the script may be different on other distributions. On Debian 3.0,
the script is named samba, and on older versions
of Red Hat, it is located in /etc/rc.d/init.d
.
If you installed from a source code distribution, you will have to write and install your own script that can perform the start and stop functions. (Or maybe you can copy the script from a Samba binary package for your distribution.) When started from a script, smbd and nmbd must be started with the -D option, so that they will detach themselves and run as daemons.
After you have tested the script and you are sure it works, create
the appropriate symbolic links in your
/etc/rc
N
.d
directories to start Samba in the runlevel you normally run in, and
stop Samba when changing to other runlevels.
Now that you have Samba installed, configured, and running, try using the smbclient command to access one of the shared directories:
$ smbclient //localhost/data
added interface ip=172.16.1.3 bcast=172.16.1.255 nmask=255.255.255.0
Password:
Domain=[METRAN] OS=[Unix] Server=[Samba 2.2.5]
smb: >
At the smb: >
prompt, you can enter any
smbclient command. Try the
ls command, to list the contents of the
directory. Then try the help command, which will
show you all of the commands that are available. The
smbclient program works very much like
ftp, so if you are used to
ftp, you will feel right at home. Now exit
smbclient (using the quit
or exit command), and try some variations.
First, use your server’s hostname instead of
localhost
, to check that name resolution is
functioning properly. Then try accessing your home directory by using
your username instead of data
.
And now for the really fun part: go to a Windows system, and log on using your Samba account username and password. (On Windows NT/2000/XP, you will need to add a new user account, using the Samba account’s username and password.) Double-click on the Network Neighborhood or My Network Places icon on the desktop. Browse through the network to find your workgroup, and double-click on its icon. You should see an icon for your Samba server in the window that opens. By double-clicking on that icon, you will open a window that shows your home directory, printer, and data shares. Now you can drag and drop files to and from your home directory and data shares, and after installing a printer driver for the shared printer and send Windows print jobs to your Linux printer!
We have only touched the surface of what Samba can do, but this should already give you an impression why Samba — despite not being developed just for Linux — is one of the software packages that have made Linux famous.
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 Section 12.2 earlier in this chapter. Use this with care!
When creating or modifying files on Linux, common editors like Emacs and vi can handle the conversion automatically for you.
There are a number of tools that convert files from one line-ending convention to the other. Some of these tools can also handle other conversion tasks as well.
Use your favorite programming language to write your own conversion utility.
If all you are interested in is converting newline characters,
writing programs to perform the conversions is surprisingly simple.
To convert from DOS format to Unix format, replace every occurrence
of CRLF (
f
or
) in the
file to a newline (
). To go the other way,
convert every newline to a CRLF. For example, we will show you two
Perl programs that do the job. The first, which we call
d2u, converts from DOS format to Unix format:
#!/usr/bin/perl while (<STDIN>) { s/ $//; print }
And the following program (which we call u2d) converts from Unix format to DOS format:
#!/usr/bin/perl while (<STDIN>) { s/$/ /; print }
Both commands read the input file from the standard input, and write the output file to standard output. You can easily modify our examples to accept the input and output file names on the command line. If you are too lazy to write the utilities yourself, you can see if your Linux installation contains the programs dos2unix and unix2dos, which work similarly to our simple d2u and u2d utilities, and also accept filenames on the command line. Another similar pair of utilities is fromdos and todos. If you cannot find any of these, then try the flip command, which is able to translate in both directions.
If you find these simple utilities underpowered, you may want to try recode, a program that can convert just about any text-file standard to any other.
The most simple 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, such as latex
for the
LaTeX style of encoding diacritics (see Chapter 9)
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 tools just
described, you can handle text
files quite comfortably, but this is only the beginning. For example,
pixel graphics on Windows are usually saved as
bmp
files. Fortunately, there are a number of
tools available that can convert bmp
files to
graphics file formats, such as png
or
xpm
that are more common on Unix. Among these
are the Gimp, which is probably included with your distribution.
Things are less easy when it comes to other file formats like those
saved by office productivity programs. While the various incarnations
of the doc
file format used by Microsoft Word
have become a de facto lingua franca for word processor files on
Windows, it was until recently almost impossible to read those files
on Linux. Fortunately, a number of software packages have appeared
that can read (and sometimes even write) .doc
files. Among them are the office productivity suite KOffice, the
freely available OpenOffice, and the commercial StarOffice 6.0, a
close relative to OpenOffice. Be aware, though, that these
conversions will never be perfect; it is very likely that you will
have to manually edit the files afterwards. Even on Windows,
conversions can never be 100% correct; if you try importing a
Microsoft Word file into WordPerfect (or vice versa), you will see
what we mean.
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 it. Another approach might be to switch to open file formats, such as Rich Text Format (RTF) or Extensible Markup Language (XML), when creating documents on Windows. In the age of the Internet, where information is supposed to float freely, closed, undocumented file formats are an anachronism.