path: root/docs/faq/Samba-meta-FAQ.sgml

<!doctype linuxdoc system> <!-- -*- SGML -*- -->
<!--
 v 0.1 23 Aug 1997 	Dan Shearer 
			Original Samba-meta-FAQ.sgml from Paul's sambafaq.sgml
 v 0.2 25 Aug 1997      Dan   
 v 0.3 7  Oct 1997	Paul
			Changed samba.canberra refs to samba.anu.../samba/
-->

<article>

<title> Samba meta FAQ

<author>Dan Shearer & Paul Blackman, <tt>ictinus@samba.org</tt>

<date>v 0.3, 7 Oct '97

<abstract> This is the meta-Frequently Asked Questions (FAQ) document
for Samba, the free and very popular SMB and CIFS server product. It
contains overview information for the Samba suite of programs, a
quick-start guide, and pointers to all other Samba documentation. Other
FAQs exist for specific client and server issues, and HOWTO documents
for more extended topics to do with Samba software. Current to version
Samba 1.9.17. Please send any corrections to the author. 
</abstract>

<toc>

<sect> Quick Reference Guides to Samba Documentation<p><label id=quickref>

We are endeavouring to provide links here to every major class of
information about Samba or things related to Samba. We cannot list every
document, but we are aiming for all documents to be at most two
referrals from those listed here. This needs constant maintaining, so
please send the author your feedback.

<sect1> Samba for the Impatient<p><label id="impatient">

You know you should read the documentation but can't wait to start? What
you need to do then is follow the instructions in the following
documents in the order given. This should be enough to get a fairly
simple site going quickly. If you have any problems, refer back to this
meta-FAQ and follow the links to find more reading material.

<descrip>

<label id="ImpGet"><tag/Getting Samba:/ The fastest way to get Samba
going is and install it is to have an operating system for which the
Samba team has put together an installation package. To see if your OS
is included have a look at the directory
/pub/samba/Binary_Packages/"OS_Vendor" on your nearest <url
url="../MIRRORS" name="mirror site">. If it is included follow the
installation instructions in the README file there and then do some <ref id="ImpTest"
name="basic testing">. If you are not so fortunate, follow the normal <ref
id="WhereFrom" name="download instructions"> and then continue with <ref
id="ImpInst" name="building and installing Samba">.

<label id="ImpInst"><tag/Building and Installing Samba:/ At the moment
there are two kinds of Samba server installs besides the prepackaged
binaries mentioned in the previous step. You need to decide if you have a <url url="../UNIX_INSTALL.txt"
name="Unix or close relative"> or <url
url="Samba-Server-FAQ.html#PortInfo" name="other supported operating system">.

<label id="ImpTest"><tag/Basic Testing:/ Try to connect using the
supplied smbclient command-line program. You need to know the IP
hostname of your server. A service name must be defined in smb.conf, as
given in the examples (under many operating systems if there is a
[homes] service you can just use a valid username.) Then type
<tt>
        smbclient \\hostname\servicename
</tt>
Under most Unixes you will need to put the parameters within quotation
marks. If this works, try connecting from one of the SMB clients you
were planning to use with Samba.

<label id="ImpDebug"><tag/Debug sequence:/ If you think you have completed the 
previous step and things aren't working properly work through 
<url url="../DIAGNOSIS.txt" name="the diagnosis recipe.">

<label id="ImpExp"><tag/Exporting files to SMB clients:/ You should read the manual pages
for smb.conf, but here is a <url url="Samba-Server-FAQ.html#Exporting"
name="quick answer guide.">

<label id="ImpControl"><tag/Controlling user access:/ the quickest and dirtiest way of sharing
resources is to use <ref id="ShareModeSecurity" name="share level
security."> If you want to spend more time and have a proper username
and password database you must read the paragraph on <ref
id="DomainModeSecurity" name="domain mode security."> If you want
encryption (eg you are using Windows NT clients) follow the <url
url="Samba-Server-FAQ.html#SMBEncryptionSteps" name="SMB encryption
instructions.">

<label id="ImpBrowse"><tag/Browsing:/ if you are happy to type in "\\samba-server\sharename"
at the client end then do not read any further. Otherwise you need to
understand the <ref id="BrowsingDefinitions" name="browsing terminology">
and read <url url="Samba-Server-FAQ.html#NameBrowsing">. 

<label id="ImpPrint"><tag/Printing:/ See the <url url="Samba-Server-FAQ.html#Printing"
name="printing quick answer guide.">

</descrip>

If you have got everything working to this point, you can expect Samba
to be stable and secure: these are its greatest strengths. However Samba
has a great deal to offer and to go further you must do some more
reading. Speed and security optimisations, printer accounting, network
logons, roving profiles, browsing across multiple subnets and so on are
all covered either in this document or in those it refers to.

<sect1> All Samba Documentation<p><label id=AllDocs>

<itemize>

<item> Meta-FAQ. This is the mother of all documents, and is the one you
are reading now. The latest version is always at <url
url="http://samba.org/[.....]"> but there is probably a much
nearer <url url="../MIRRORS" name="mirror site"> which you should use
instead.

<item> <url url="Samba-Server-FAQ.html"> is the best starting point for
information about server-side issues. Includes configuration tips and
pointers for Samba on particular operating systems (with 40 to choose
from...)

<item> <url url="Samba-Client-FAQ.html"> is the best starting point for
information about client-side issues, includes a list of all clients
that are known to work with Samba.

</itemize>

<sect> General Information<p><label id="general_info">

All about Samba - what it is, how to get it, related sources of
information, how to understand the numbering scheme, pizza
details.

<sect1> What is Samba?<p><label id="introduction">

Samba is a suite of programs which work together to allow clients to
access to a server's filespace and printers via the SMB (Server Message
Block) and CIFS (Common Internet Filesystem) protocols. Initially
written for Unix, Samba now also runs on Netware, OS/2, VMS, StratOS and
Amigas. Ports to BeOS and other operating systems are underway. Samba
gives the capability for these operating systems to behave much like a
LAN Server, Windows NT Server or Pathworks machine, only with added
functionality and flexibility designed to make life easier for
administrators. 

This means that using Samba you can share a server's disks and printers
to many sorts of network clients, including Lan Manager, Windows for
Workgroups, Windows NT, Linux, OS/2, and AIX. There is also a generic
client program supplied as part of the Samba suite which gives a user on
the server an ftp-like interface to access filespace and printers on any
other SMB/CIFS servers.

SMB has been implemented over many protocols, including XNS, NBT, IPX,
NetBEUI and TCP/IP. Samba only uses TCP/IP. This is not likely to change
although there have been some requests for NetBEUI support.

Many users report that compared to other SMB implementations Samba is
more stable, faster, and compatible with more clients. Administrators of
some large installations say that Samba is the only SMB server available
which will scale to many tens of thousands of users without crashing.
The easy way to test these claims is to download it and try it for
yourself!

The suite is supplied with full source code under the <url
url="../COPYING" name="GNU Public License">. The GPL means that you can
use Samba for whatever purpose you wish (including changing the source
or selling it for money) but under all circumstances the source code
must be made freely available. A copy of the GPL must always be included
in any copy of the package.

The primary creator of the Samba suite is Andrew Tridgell. Later
versions incorporate much effort by many helpers. The man pages
and this FAQ were originally written by Karl Auer.

<sect1> Where can I go for further information?<p><label id="more">

There are a number of places to look for more information on Samba,
including:

<itemize>

<item>The mailing lists devoted to discussion of Samba-related matters.
See below for subscription information.

<item>The newsgroup comp.protocols.smb, which has a great deal of
discussion about Samba. 

<item>The WWW site 'SAMBA Web Pages' at <url
url="http://samba.org/samba/"> includes:

  <itemize>
    <item>Links to man pages and documentation, including this FAQ
    <item>A comprehensive survey of Samba users
    <item>A searchable hypertext archive of the Samba mailing list
    <item>Links to Samba source code, binaries, and mirrors of both
    <item>This FAQ and the rest in its family
  </itemize>

</itemize>

<sect1>How do I subscribe to the Samba Mailing Lists?<p><label id="mailinglist">

Surf to <url url="http://lists.samba.org/"> for an overview of all the mailing lists.

<sect1> Something's gone wrong - what should I do?<p><label id="wrong">

<bf>[#] *** IMPORTANT! *** [#]</bf>
<p>

DO NOT post messages on mailing lists or in newsgroups until you have
carried out the first three steps given here!

<enum> <item> See if there are any likely looking entries in this FAQ!
If you have just installed Samba, have you run through the checklist in
<url url="ftp://samba.org/pub/samba/DIAGNOSIS.txt"
name="DIAGNOSIS.txt">? It can save you a lot of time and effort.
DIAGNOSIS.txt can also be found in the docs directory of the Samba
distribution.

<item> Read the man pages for smbd, nmbd and smb.conf, looking for
topics that relate to what you are trying to do.

<item> If there is no obvious solution to hand, try to get a look at
the log files for smbd and/or nmbd for the period during which you
were having problems. You may need to reconfigure the servers to
provide more extensive debugging information - usually level 2 or
level 3 provide ample debugging info. Inspect these logs closely,
looking particularly for the string "Error:".

<item> If you need urgent help and are willing to pay for it see 
<ref id="PaidSupport" name="Paid Support">.

</enum>

If you still haven't got anywhere, ask the mailing list or newsgroup. In
general nobody minds answering questions provided you have followed the
preceding steps. It might be a good idea to scan the archives of the
mailing list, which are available through the Samba web site described
in the previous section. When you post be sure to include a good
description of your environment and your problem.

If you successfully solve a problem, please mail the FAQ maintainer a
succinct description of the symptom, the problem and the solution, so
that an explanation can be incorporated into the next version.

<sect1> How do I submit patches or bug reports?<p>

If you make changes to the source code, <em>please</em> submit these patches
so that everyone else gets the benefit of your work. This is one of
the most important aspects to the maintainence of Samba. Send all
patches to <htmlurl url="mailto:samba@samba.org" name="samba@samba.org">. Do not send patches to Andrew Tridgell or any
other individual, they may be lost if you do.

Patch format
------------

If you are sending a patch to fix a problem then please don't just use
standard diff format. As an example, samba@samba.org received this patch from
someone:

382a
#endif
..
381a
#if !defined(NEWS61)

How are we supposed to work out what this does and where it goes? These
sort of patches only work if we both have identical files in the first
place. The Samba sources are constantly changing at the hands of multiple
developers, so it doesn't work.

Please use either context diffs or (even better) unified diffs. You
get these using "diff -c4" or "diff -u". If you don't have a diff that
can generate these then please send manualy commented patches to I
know what is being changed and where. Most patches are applied by hand so
the info must be clear.

This is a basic guideline that will assist us with assessing your problem
more efficiently :

Machine Arch:
Machine OS:
OS Version:
Kernel:

Compiler:
Libc Version:

Samba Version:

Network Layout (description):

What else is on machine (services, etc):

Some extras :

<itemize>

<item> what you did and what happened

<item> relevant parts of a debugging output file with debuglevel higher.
  If you can't find the relevant parts, please ask before mailing
  huge files.

<item> anything else you think is useful to trace down the bug

</itemize>

<sect1> What if I have an URGENT message for the developers?<p>

If you have spotted something very serious and believe that it is
important to contact the developers quickly send a message to
samba-urgent@samba.org. This will be processed more quickly than
mail to samba@samba.org. Please think carefully before using this address. An
example of its use might be to report a security hole.

Examples of things <em>not</em> to send to samba-urgent include problems
getting Samba to work at all and bugs that cannot potentially cause damage.

<sect1> What if I need paid-for support?<p><label id=PaidSupport>

Samba has a large network of consultants who provide Samba support on a
commercial basis. The list is included in the package in <url
url="../Support.txt">, and the latest version will always be on the main
samba ftp site. Any company in the world can request that the samba team
include their details in Support.txt so we can give no guarantee of
their services.

<sect1> Pizza supply details<p><label id="pizza">
Those who have registered in the Samba survey as "Pizza Factory" will
already know this, but the rest may need some help. Andrew doesn't ask
for payment, but he does appreciate it when people give him
pizza. This calls for a little organisation when the pizza donor is
twenty thousand kilometres away, but it has been done.

<enum>
<item> Ring up your local branch of an international pizza chain
and see if they honour their vouchers internationally. Pizza Hut do,
which is how the entire Canberra Linux Users Group got to eat pizza
one night, courtesy of someone in the US.

<item>Ring up a local pizza shop in Canberra and quote a credit
card number for a certain amount, and tell them that Andrew will be
collecting it (don't forget to tell him.) One kind soul from Germany
did this.

<item>Purchase a pizza voucher from your local pizza shop that has
no international affiliations and send it to Andrew. It is completely
useless but he can hang it on the wall next to the one he already has
from Germany :-)

<item>Air freight him a pizza with your favourite regional
flavours. It will probably get stuck in customs or torn apart by
hungry sniffer dogs but it will have been a noble gesture.

</enum>

<sect>About the CIFS and SMB Protocols<p><label id="CifsSmb">

<sect1> What is the Server Message Block (SMB) Protocol?<p>
SMB is a filesharing protocol that has had several maintainers and
contributors over the years including Xerox, 3Com and most recently
Microsoft. Names for this protocol include LAN Manager and Microsoft 
Networking. Parts of the specification has been made public at several 
versions including in an X/Open document, as listed at 
<url url="ftp://ftp.microsoft.com/developr/drg/CIFS/">. No specification
releases were made between 1992 and 1996, and during that period
Microsoft became the SMB implementor with the largest market share.
Microsoft developed the specification further for its products but for
various reasons connected with developer's workload rather than market
strategy did not make the changes public. This culminated with the 
"Windows NT 0.12" version released with NT 3.5 in 1995 which had significant 
improvements and bugs. Because Microsoft client systems are so popular,
it is fair to say that what Microsoft with Windows affects all suppliers
of SMB server products.

From 1994 Andrew Tridgell began doing some serious work on his 
Smbserver (now Samba) product and with some helpers started to 
implement more and more of these protocols. Samba began to take 
a significant share of the SMB server market.

<sect1> What is the Common Internet Filesystem (CIFS)?<p>
The initial pressure for Microsoft to document their current SMB
implementation came from the Samba team, who kept coming across things
on the wire that Microsoft either didn't know about or hadn't documented
anywhere (even in the sourcecode to Windows NT.) Then Sun Microsystems
came out with their WebNFS initiative, designed to replace FTP for file
transfers on the Internet. There are many drawbacks to WebNFS (including
its scope - it aims to replace HTTP as well!) but the concept was
attractive. FTP is not very clever, and why should it be harder to get
files from across the world than across the room? 

Some hasty revisions were made and an Internet Draft for the Common
Internet Filesystem (CIFS) was released. Note that CIFS is not an
Internet standard and is a very long way from becoming one, BUT the
protocol specification is in the public domain and ongoing discussions
concerning the spec take place on a public mailing list according to the
rules of the Internet Engineering Task Force. For more information and
pointers see <url url="http://samba.org/cifs/">

The following is taken from <url url="http://www.microsoft.com/intdev/cifs/">

<verb>
    CIFS defines a standard remote file system access protocol for use
    over the Internet, enabling groups of users to work together and
    share documents across the Internet or within their corporate
    intranets. CIFS is an open, cross-platform technology based on the
    native file-sharing protocols built into Microsoft® Windows® and
    other popular PC operating systems, and supported on dozens of
    other platforms, including UNIX®. With CIFS, millions of computer
    users can open and share remote files on the Internet without having
    to install new software or change the way they work."
</verb>

If you consider CIFS as a backwardsly-compatible refinement of SMB that
will work reasonably efficiently over the Internet you won't be too far
wrong.

The net effect is that Microsoft is now documenting large parts of their
Windows NT fileserver protocols. The security concepts embodied in
Windows NT are part of the specification, which is why Samba
documentation often talks in terms of Windows NT. However there is no
reason why a site shouldn't conduct all its file and printer sharing
with CIFS and yet have no Microsoft products at all.

<sect1> What is Browsing? <p>
The term "Browsing" causes a lot of confusion. It is the part of the
SMB/CIFS protocol which allows for resource discovery. For example, in
the Windows NT Explorer it is possible to see a "Network Neighbourhood"
of computers in the same SMB workgroup. Clicking on the name of one of 
these machines brings up a list of file and printer resources for
connecting to. In this way you can cruise the network, seeing what
things are available. How this scales to the Internet is a subject for
debate. Look at the CIFS list archives to see what the experts think.

<sect>Designing A SMB and CIFS Network<p>

The big issues for installing any network of LAN or WAN file and print
servers are 

<itemize> 

<item>How and where usernames, passwords and other security information
is stored 

<item>What method can be used for locating the resources that users have
permission to use 

<item>What protocols the clients can converse with

</itemize> 

If you buy Netware, Windows NT or just about any other LAN fileserver
product you are expected to lock yourself into the product's preferred
answers to these questions. This tendancy is restrictive and often very
expensive for a site where there is only one kind of client or server,
and for sites with a mixture of operating systems it often makes it
impossible to share resources between some sets of users.

The Samba philosophy is to make things as easy as possible for
administators, which means allowing as many combinations of clients,
servers, operating systems and protocols as possible.

<sect1>Workgroups, Domains, Authentication and Browsing<p>

From the point of view of networking implementation, Domains and
Workgroups are <em>exactly</em> the same, except for the client logon
sequence. Some kind of distributed authentication database is associated
with a domain (there are quite a few choices) and this adds so much
flexibility that many people think of a domain as a completely different
entity to a workgroup. From Samba's point of view a client connecting to
a service presents an authentication token, and it if it is valid they
have access. Samba does not care what mechanism was used to generate
that token in the first place.

The SMB client logging on to a domain has an expectation that every other
server in the domain should accept the same authentication information.
However the network browsing functionality of domains and workgroups is
identical and is explained in <url url="../BROWSING.txt">.

There are some implementation differences: Windows 95 can be a member of
both a workgroup and a domain, but Windows NT cannot. Windows 95 also
has the concept of an "alternative workgroup". Samba can only be a
member of a single workgroup or domain, although this is due to change
with a future version when nmbd will be split into two daemons, one for
WINS and the other for browsing (<url url="../NetBIOS.txt"> explains
what WINS is.)

<sect2> Defining the Terms<p><label id="BrowseAndDomainDefs">

<descrip>

<tag/Workgroup/ means a collection of machines that maintain a common
browsing database containing information about their shared resources.
They do not necessarily have any security information in common (if they
do, it gets called a Domain.) The browsing database is dynamic, modified
as servers come and go on the network and as resources are added or
deleted. The term "browsing" refers to a user accessing the database via
whatever interface the client provides, eg the OS/2 Workplace Shell or
Windows 95 Explorer. SMB servers agree between themselves as to which
ones will maintain the browsing database. Workgroups can be anywhere on
a connected TCP/IP network, including on different subnets or even on
the Interet. This is a very tricky part of SMB to implement.

<tag/Master Browsers/ are machines which holds the master browsing
database for a workgroup or domain. There are two kinds of Master Browser:

<itemize>

<item> Domain Master Browser, which holds the master browsing
information for an entire domain, which may well cross multiple TCP/IP
subnets.

<item> Local Master Browser, which holds the master browsing database
for a particular subnet and communicates with the Domain Master Browser
to get information on other subnets.

</itemize>

Subnets are differentiated because browsing is based on broadcasts, and
broadcasts do not pass through routers. Subnets are not routed: while it
is possible to have more than one subnet on a single network segment
this is regarded as very bad practice.

Master Browsers (both Domain and Local) are elected dynamically
according to an algorithm which is supposed to take into account the
machine's ability to sustain the browsing load. Samba can be configured
to always act as a master browser, ie it always wins elections under all
circumstances, even against systems such as a Windows NT Primary Domain
Controller which themselves expect to win. 

There are also Backup Browsers which are promoted to Master Browsers in
the event of a Master Browser disappearing from the network.

Alternative terms include confusing variations such as "Browse Master",
and "Master Browser" which we are trying to eliminate from the Samba
documentation. 

<tag/Domain Controller/ is a term which comes from the Microsoft and IBM
etc implementation of the LAN Manager protocols. It is tied to
authentication. There are other ways of doing domain authentication, but
the Windows NT method has a large market share. The general issues are
discussed in <url url="../DOMAIN.txt"> and a Windows NT-specific
discussion is in <url url="../DOMAIN_CONTROL.txt">.

</descrip>

<sect2>Sharelevel (Workgroup) Security Services<p><label id="ShareModeSecurity">

With the Samba setting "security = SHARE", all shared resources
information about what password is associated with them but only hints
as to what usernames might be valid (the hint can be 'all users', in
which case any username will work. This is usually a bad idea, but
reflects both the initial implementations of SMB in the mid-80s and
its reincarnation with Windows for Workgroups in 1992. The idea behind
workgroup security was that small independant groups of people could
share information on an ad-hoc basis without there being an
authentication infrastructure present or requiring them to do more than
fill in a dialogue box.

<sect2>Authentication Domain Mode Services<p><label id="DomainModeSecurity">

With the Samba settings "security = USER" or "security = SERVER"
accesses to all resources are checked for username/password pair matches
in a more rigorous manner. To the client, this has the effect of
emulating a Microsoft Domain. The client is not concerned whether or not
Samba looks up a Windows NT SAM or does it in some other way.

<sect1>Authentication Schemes<p>

In the simple case authentication information is stored on a single
server and the user types a password on connecting for the first time.
However client operating systems often require a password before they
can be used at all, and in addition users usually want access to more
than one server. Asking users to remember many different passwords in
different contexts just does not work. Some kind of distributed
authentication database is needed. It must cope with password changes
and provide for assigning groups of users the same level of access
permissions. This is why Samba installations often choose to implement a
Domain model straight away.

Authentication decisions are some of the biggest in designing a network.
Are you going to use a scheme native to the client operating system,
native to the server operating system, or newly installed on both? A
list of options relevant to Samba (ie that make sense in the context of
the SMB protocol) follows. Any experiences with other setups would be
appreciated. [refer to server FAQ for "passwd chat" passwd program 
password server etc etc...]

<sect2>NIS<p>

For Windows 95, Windows for Workgroups and most other clients Samba can
be a domain controller and share the password database via NIS
transparently. Windows NT is different. 
<url url="http://www.dcs.qmw.ac.uk/~williams" name="Free NIS NT client">

<sect2>Kerberos<p>

Kerberos for US users only:
<url url="http://www.cygnus.com/product/unifying-security.html"
name="Kerberos overview">
<url url="http://www.cygnus.com/product/kerbnet-download.html"
name="Download Kerberos">

<sect2>FTP<p>

Other NT w/s logon hack via NT

<sect2>Default Server Method<p>

<sect2>Client-side Database Only<p>

<sect1>Post-Authentication: Netlogon, Logon Scripts, Profiles<p>

See <url url="../DOMAIN.txt">

<sect>Cross-Protocol File Sharing<p>

Samba is an important tool for...

It is possible to...

File protocol gateways...

"Setting up a Linux File Server" http://vetrec.mit.edu/people/narf/linux.html

Two free implementations of Appletalk for Unix are Netatalk, <url
url="http://www.umich.edu/~rsug/netatalk/">, and CAP, <url
url="http://www.cs.mu.oz.au/appletalk/atalk.html">. What Samba offers MS
Windows users, these packages offer to Macs. For more info on these
packages, Samba, and Linux (and other UNIX-based systems) see <url
url="http://www.eats.com/linux_mac_win.html"> 3.5) Sniffing your nework


<sect>Miscellaneous<p><label id="miscellaneous">
<sect1>Is Samba Year 2000 compliant?<p><label id="Year2000Compliant">
The CIFS protocol that Samba implements
negotiates times in various formats, all of which
are able to cope with dates beyond 2000.

</article>