Due to the incredibly large number of Microsoft applications, it is almost
expected that a server be able to provide some kind of access to the Windows
machines. If you have TCP/IP running on your machines, then you have
connectivity from your Windows machines to a Linux server through telnet and
ftp. However, you do have access to the file and print services provided by
an NT server. Or do you?
used by Windows NT networks is the Session Message Block or SMB.
This is the same protocol
that Microsoft has been using for years with their Lan
Manager product. Therefore, anything that
can access a Lan
Manager server, will be able to access an NT server.
Recently, Linux has been able to support SMBs through the SAMBA
package. This not only means that a Linux machine can provide file and print service to
Windows machines, but they can also provide the same services to a Linux
Because Linux and Windows have a different understanding of
security and approach it in a different way, you have to be careful in what you
make available. However, in keeping with the UNIX
tradition of configurability,
you have a wide range of choices on how to configure your system. The are many
different options to define your security
as well as what you make available and
SAMBA has both a server and a client
component and as one might expect
side is fairly straightforward. Fortunately, to get the server side
working, you don't have to do too much. On the other hand, there
are a lot of options that you can use to configure the system to
fit your needs.
There are five primary files that SAMBA
uses. The SMB daemon is smbd, which is the SMB
server. This is what is what is providing the
services. The client
side is the program smbclient. This is what allows you to
access Windows machines from your Linux workstations and servers.
The nmbd program is the NetBIOS name server
SAMBAs configuration file
is smb.conf which you should find in the /etc directory. This file has a format
that is similar to Windows INI files, in that it is broken up into section. Each
section has a particular function. For example, the section that describe the
printer configuration would start like this:
Like the Windows ini files, smb.conf is line based, with one option per line. In general,
the configuration options have the format:
option = value
Finally, there is the testpararm program, which is used to test the SAMBA
The first section of
smb.conf sets up the global configuration and is
called, [global]. The default looks
something like this:
printing = bsd
printcap name = /etc/printcap
load printers = yes
; Uncomment this if you want a guest account
; guest account = pcguest
log file = /var/log/samba-log.%m
lock directory = /var/lock/samba
share modes = yes
The printing option determines how the printer status
information is interpreted. The default is bsd, which is the most common used.
For information on the others, see the smbd man-page.
The printcap name option defines the name of the printcap file. In this example, we are
using the standard printcap file. If you use a different printing option, the printcap
file could be different.
The load printers options determines whether or not all the printers listed in printcap are
loaded for browsing.
The guest account is used for enabling access somewhat
anonymously. By default this is disabled, as in this example. To enable it,
uncomment the lines by removing the semi-colons. The actual effects of this
account we'll get to later
The log file option defines what file to write diagnostic messages and other
information. Note that there is a %m at
the end of the file. This variable
is the netbios name of the client
This can be used in other places, as well. In this case, there will be one log
file for each client.
The lock directory options define the directory where lock files are put. The
share modes option is used to enable/disable the
"share modes" when files are opened. This allows clients to get
exclusive read or write of files. Since this is something not directly supported
by Linux, smbd uses locks in the lock
There are primarily two types of services that you access via
smb: file and print services. File services are directories that have been
made available. Normally, all sub-directories under the exported or
shared directory are accessible. Lets assume that we want to make the
users home directory
available. To do this we share them. The section
might look like this:
comment = Home Directories
read only = no
Here the section name is [home_dirs]
but we specify the path of /home.
So when we are on Windows machine (e.g. Windows 98) we would see this directory
as homes. (Since that is the share name)
In this example, we specified the directory as not being read only. This would
be the same as specifying the directory as writable. (Note that the section
[homes] is a special section, which we
will get to shortly)
We can also define access for specific users. For
example, if I wanted to give each user access to their own home directory
other, I could create shares for each directory. So, the share for jimmo's home
directory might be:
comment = Jimmo's Home Directory
valid users = jimmo
writable = yes
Here we added the
valid users option, which, as one might expect,
indicates which users can have access to this directory. Since the only user
specified is jimmo, only I can access this directory. Note that if I were to add
the option browseable = no and use the
Windows browser (not the same as a Web browser), I would not not be able to see
the share, even though I could explicitely connect to it. If it were browseable,
but I was not in the list of valid users, I could see it, but would then be
asked for your password. Since I was not in the list of valid users, no password
I enter would work. (At least this is the behavior from Windows
Setting up a printer is the same basic process. We define a resource
that we share and specify what access is permitted. An example, might look like
comment = Deskjet on Junior
path = /tmp
printer = lp
public = no
writable = no
printable = yes
Here the path is not the path to the
resource, but rather a world-writable directory that has the sticky-bit set.
This is the spool directory and allows us to write to it, but no one can remove
our files. In this example, I just used /tmp.
However, you could create a special directory for this purpose, for
example /var/spool/public. We could also
specify a list of valid users for this printer.
The [homes] section is used to connect to users home
directories on the fly, without having to create individual shares as I
suggested above. When you try to connect to a service with the same name as a
user, smbd will do one of two things. If there really is a service of that
name, smbd will connect to it. If there is no such service,
smbd will treat it like a user name
and look for that users home directory
in the passwd file. Next, smbd will create a
"virtual" share by making an internal copy of the
[homes] section, but using the users name as the
share name. An example [homes] section
might look like this:
comment = Home Directories
browseable = no
read only = no
create mode = 0750
Note that there is no
path specified in this example. This is because, the path for the share is the
home directory specified in /etc/passwd.
However, we could have specified a path and although the name of the
share would be that of the user, the path would be whatever we specified.
We could still specify the path using the
This is the name of the current service,
which, in this case, is the name of the current user. This could be done like
This might be useful if we give the users one home directory
when accessing from a PC and another home directory when directly logging into the Linux
The [printers] section
behaves similarly to the [homes]
section. If you try to connect to a service, smbd
will first look for a service with the specific name. If it
finds one, that's what it will connect to. If there is none, it will look through
the printcap file. If there is a
matching printer name in the printcap
file, this is the one that will get used. Otherwise, an error is
returned. An example, [printers] might
look like this:
path = /var/spool/public
writable = no
public = yes
printable = yes
Note that this service is defined as not writable. However, it is defined as being printable. This is necessary for
To a limited extent, your Linux machine can be
configured as an SMB client.
This is done using the smbclient program. This provides a functionality
similar to ftp
in that you can copy files from one machine to another. The general syntax would be:
Note that there are twice as many back-slashes as normal. This is because the
first try to interpret the slashes, so we have to escape each one with a back
slash. Alternatively, we could enclose the complete service name inside of
single quotes, like this:
At this point we have configured SAMBA
to allow us to connect from a Windows machine, or any other machine that
understand SMBs. The good news is that's not all. SAMBA
has many more
configuration options. The bad news is that we don't have space to cover them
all. The first place to start looking is the smbd
man-pages. These both go into a lot of detail about how you can configure SAMBA.
There are a few configuration options that I would like to address.
The first set have to do with security. SAMBA
allows you to specify access based on both user (as described above) and by
host. This is done with the allow hosts option. Like the
valid user list, the list of authorized hosts is
comma delimited values. In this case, the IP
address or host
name. You can globally define access by including the list in the
[global] section or you can define it for specific services.
Using the IP address, you could specify entire
networks by simply including just the network
portion of the IP address. For example:
hosts allow = 192.168
We could also exclude specific addresses. For example:
hosts allow = 192.168 EXCEPT 192.168.42
allows access from the class B net 192.168, but denies access from any
machine on the class C network 192.168.42.
Supplemental to hosts allow is hosts
deny, which, as you might guess, is used to specifically
deny access. This has the same syntax as hosts
allow. Note that access defined here is the first phase. If
you deny access to a particular machine, that's it. They cant get any further.
However, if you allow access they can still be restricted at the user
You could also use a list of invalid users
to restrict access. For example, you could define root as an
invalid user. This would prevent root from accessing any service, which is
helpful if you leave a security
hole open. You can also include users that are
part of Linux group by preceeding that name with an at-sign@. For example, to
keep root and members of the adm group out, the line might look like
invalid users = root,@adm
Note that any place that you have a list of users, you can use the @
construct to include group names.
On some cases, there are directories
that you don't want users to have access to, although you allow them access to
their parent. This is first accomplished by setting the permissions
directory. However, this is not always a valid alternative. For example, you may
not want users to have access to the /dev
directory, but you cant change the permissions.
However, you can use the
don't descend option to prevent them from
accessing through SAMBA.
This options takes a common separated list. For
don't descend = /proc,/dev
The guest ok option (and its
synonym public) are used to give access
to services without requiring a password. Once connected, access will be the
same as the guest account.
This is a boolean option with a default of no.
Another useful option give you
the ability to define a configuration file based on the user or machine that is
connecting. This is done with the config file
option, which appears in the global section. Setting the configuration
file based on the machine name might look like this:
config file = /etc/smb.conf.%m
When you connect, smbd will look for a matching
configuration file. If it finds one, it will reload the new one. If there
is no match, the original configuration stays in effect. This is useful for
defining a configuration for some machines (or users) and not for others.
To make management easier, especially if you have a lot of shares for a
lot of different machines, using the include option you can have one main
configuration file and include the configuration files for specific machines and
users. By using variable
substitution, you can create files based on machine or
user name and then include them. For example, to include files based on machine
name, the directive might look like this:
Also helpful to manage your services
is the copy option, which allows you to
copy services (what else?). This way you can create services with different
names but have the same basic configuration options. The syntax is
copy = service
Where service is the name of the service that you want to copy.
Two things to note. First, the "original" must
appear first in the configuration file. Second, you can change parameters in the
copy and they will override anything in the original. This would be useful to
create a kind of template, which , for example, defines the access permissions,
but each service would define its own path.
The guest account option is used in conjunction with the
guest ok and defines a user name
that will be used during the connection. This user must exist in the password file, but it
is safest that they don't have a valid login
(i.e. have /bin/false as their shell).
You can limit access further by defining a service as guest only.
This means that although a user has a valid password to
access a particular service, they are limited to whatever the guest account
has access to.
If you have been working with UNIX
and DOS/Windows machines at the same time, you probably have experienced something that is affectionately
called file name mangling. This results from the fact that UNIX
names can be longer than the standard DOS
You can configure Samba so that it will " mangling" the DOS
names for you, so they are accessible
and Windows. (Note that you don't need to do this with Win98 or WinNT).
Depending on what your needs are, you can mangle names in different
One difference between UNIX
file names that always give me trouble is that DOS
doesn't see a difference between upper a lowercase.
Therefore, the files LETTER.TXT and letter.txt are the same in DOSs eyes.
The mangled names option (yes/no) is used to turn this functionality on and
off. If enabled (yes), names are mangled according to the rules you define. Otherwise, they
are invisible. (See the sbm.conf man-page for details on how names are mangled.)
To mangle the name correctly, you first need to define
a default case with the default case option which can either be upper
or lower. Using the mangle case option (yes/no) you tell smbd
to mangle the characters that are not the default case.
You can also set the case sensitive option (yes/no), which control whether the name
are case sensitive or not. If not (the default), smbd must do a name search to access
the appropriate file. When you create a new file, the preserve
case option (yes/no) defines how smbd will behave. The
default is no.
mangled map option allows you to define specific
changes to files. This is useful when mangling of file names is not the best
choice. The classic example is Web pages. On UNIX
machines, these normally have the extension .html. However, this does
not fit with the 8.3 convention of DOS
file names. Normally, DOS would come up
with some weird, mangled name. You can keep the name somewhat normal by using a
mangled map. For
mangled map = (*.html *.htm)
This means that whenever smbd files a file with an extension of .html it will
automatically convert the extention to .htm.
The good and bad news is that's not it. The smb.conf file contains dozens more
options. Many of which you require a very strong imagination to come up with
uses for. However, this is in keeping with the Linux tradition that you are only
limited by your imagination.
Netbios name server daemon
ftp-like SMB client
Check printer name for use with SAMBA
Check/test SAMBA configuration files
Table - Key SAMBA files