SMB.CONF(5)

NAME
smb.conf - configuration file for smbd

SYNOPSIS
smb.conf

DESCRIPTION
The smb.conf file is a configuration file for the Samba suite. smb.conf contains runtime configuration information for the smbd program. The smbd program provides LanManager-like services to clients using the SMB protocol.

FILE FORMAT
The file consists of sections and parameters. A section begins with the name of the section in square brackets and continues until the next section begins. Sections contain parameters of the form 'name = value'. The file is line-based - that is, each newline-terminated line represents either a comment, a section name or a parameter. Section and parameter names are not case sensitive. Only the first equals sign in a parameter is significant. Whitespace before or after the first equals sign is discarded. Leading, trailing and internal whitespace in section and parameter names is irrelevant. Leading and trailing whitespace in a parameter value is discarded. Internal whitespace within a parameter value is retained verbatim. Any line beginning with a semicolon is ignored, as are lines containing only whitespace. The values following the equals sign in parameters are all either a string (no quotes needed) or a boolean, which may be given as yes/no, 0/1 or true/false. Case is not significant in boolean values, but is preserved in string values. Some items such as create modes are numeric.

SERVICE DESCRIPTIONS
Each section in the configuration file describes a service. The section name is the service name and the parameters within the section define the service's attributes. There are three special sections, [global], [homes] and [printers], which are described under 'special sections'. The following notes apply to ordinary service descriptions. A service consists of a directory to which access is being given plus a description of the access rights which are granted to the user of the service. Some housekeeping options are also specifiable. Services are either filespace services (used by the client as an extension of their native file systems) or printable services (used by the client to access print services on the host running the server). Services may be guest services, in which case no password is required to access them. A specified guest account is used to define access privileges in this case. Services other than guest services will require a password to access them. The user name is specified in the configuration section for the service. The client must supply the password for that user in order to gain access to the service. Note that the access rights granted by the server are masked by the access rights granted to the specified or guest user by the host system. The server does not grant more access than the host system grants. The following sample section defines a file space service. The user has write access to the path /home/bar. The service is accessed via the service name "foo":
     [foo]
         path = /home/bar
         writable = true The following sample section defines a printable service. The service is readonly, but printable. That is, the only write access permitted is via calls to open, write to and close a spool file. The 'guest ok' parameter means access will be permitted as the default guest user (specified elsewhere):
     [aprinter]
         path = /usr/spool/public
         read only = true
         printable = true
         public = true

SPECIAL SECTIONS

  The [global] section
    Parameters in this section apply to the server as a whole, or are defaults for services which do not specifically define certain items. See the notes under 'Parameters' for more information.

  The [homes] section
    If a section called 'homes' is included in the configuration file, services connecting clients to their home directories can be created on the fly by the server. When the connection request is made, the existing services are scanned. If a match is found, it is used. If no match is found, the requested service name is treated as a user name and looked up in the local passwords file. If the name exists and the correct password has been given, a service is created by cloning the [homes] section. Some modifications are then made to the newly created section:
        The service name is changed from 'homes' to the located username The username is set to the located username If no path was given, the path is set to the user's home directory.
    This is a fast and simple way to give a large number of clients access to their home directories with a minimum of fuss. The [homes] section can specify all the parameters a normal service section can specify, though some make more sense than others. The following is a typical and suitable [homes] section:
         [homes]
             writable = yes Some important points:
        If a path is specified in the [homes] section, it will be copied into all dynamically generated services. Specifying a path thus rather defeats the purpose of the [homes] section. If a username is specified in the [homes] section, it will be ignored. It is not possible to have all clients accessing all homes as a single user. With versions of the protocol higher than core, the username is set to the username passed in the connection request. If guest access is specified in the [homes] section, all home directories will be accessible to all clients without a password. In the very unlikely event that this is actually desirable, it would be wise to also specify read only access.

  The [printers] section
    This section works like [homes], but for printers. If a [printers] section occurs in the configuration file, users are able to connect to any printer specified in the local host's printcap file. When a connection request is made, the existing services are scanned. If a match is found, it is used. If no match is found, but a [homes] section exists, it is used as described above. Otherwise, the requested service name is treated as a printer name and the appropriate printcap file is scanned to see if the requested service name is a valid printer name. If a match is found, a new service is created by cloning the [printers] section. A few modifications are then made to the newly created section:
        The service name is set to the located printer name If no printer name was given, the printer name is set to the located printer name If the service does not permit guest access and no username was given, the username is set to the located printer name.
    Note that the [printers] service MUST be printable - if you specify otherwise, the server will refuse to load the configuration file. Typically the path specified would be that of a world-writable spool directory with the sticky bit set on it. A typical [printers] entry would look like this:
         [printers]
             path = /usr/spool/public
             writable = no
             public = yes
             printable = yes All aliases given for a printer in the printcap file are legitimate printer names as far as the server is concerned. If your printing subsystem doesn't work like that, you will have to set up a pseudo-printcap. This is a file consisting of one or more lines like this:
            alias|alias|alias|alias... Each alias should be an acceptable printer name for your printing subsystem. In the [global] section, specify the new file as your printcap. The server will then only recognise names found in your pseudo-printcap, which of course can contain whatever aliases you like. The same technique could be used simply to limit access to a subset of your local printers. An alias, by the way, is defined as any component of the first entry of a printcap record. Records are separated by newlines, components (if there are more than one) are separated by vertical bar symbols ("|").

PARAMETERS
Parameters define the specific attributes of services. Some parameters are specific to the [global] section (eg., guest account). Some parameters are usable in all sections (eg., create mode). All others are permissible only in normal sections. For the purposes of the following descriptions the [homes] and [printers] sections will be considered normal. The letter 'G' in parentheses indicates that a parameter is specific to the [global] section. The letter 'S' indicates that a parameter is specific to a normal service section. The letter 'B' indicates that a parameter may be used in both the [global] section and in normal service sections. Parameters are arranged here in alphabetical order - this may not create best bedfellows, but at least you can find them! Where there are synonyms, the preferred synonym is described, others refer to the preferred synonym.

  allow hosts (B)
A synonym for this parameter is 'hosts allow'. This parameter is a comma delimited set of hosts which are permitted to access a services. If specified in the [global] section, matching hosts will be allowed access to any service that does not specifically exclude them from access. Specific services my have their own list, which override those specified in the [global] section. You can specify the hosts by name or IP number. For example, you could restrict access to only the hosts on a Class C subnet with something like "allow hosts = 150.203.5.". The full syntax of the list is described in the man page hosts_access (5). You can also specify hosts by network/netmask pairs and by netgroup names if your system supports netgroups. The EXCEPT keyword can also be used to limit a wildcard list. The following examples may provide some help: Example 1: allow all IPs in 150.203.*.* except one
    hosts allow = 150.203. EXCEPT 150.203.6.66 Example 2: allow hosts that match the given network/netmask
    hosts allow = 150.203.15.0/255.255.255.0 Example 3: allow a couple of hosts
    hosts allow = lapland, arvidsjaur Example 4: allow only hosts in netgroup "foonet" or localhost, but deny access from one particular host
     hosts allow = @foonet, localhost
     hosts deny = pirate Note that access still requires suitable user-level passwords. See testparm(1) for a way of testing your host access to see if it does what you expect. Default:
     none (ie., all hosts permitted access) Example:
     allow hosts = 150.203.5. myhost.mynet.edu.au

  available (S)
This parameter lets you 'turn off' a service. If 'available = no', then ALL attempts to connect to the service will fail. Such failures are always logged. Default:
     available = yes Example:
     available = no

  copy (S)
This parameter allows you to 'clone' service entries. The specified service is simply duplicated under the current service's name. Any parameters specified in the current section will override those in the section being copied. This feature lets you set up a 'template' service and create similar services easily. Note that the service being copied must occur earlier in the configuration file than the service doing the copying. Default:
     none Example:
     copy = otherservice

  create mask (B)
A synonym for this parameter is 'create mode'. This parameter is the octal modes which are used when converting DOS modes to Unix modes. If specified in the [global] section, this value will be used for all services that do not override it specifically. Default:
     specified at compile time Example:
     create mask = 0755

  create mode (B)
See create mask.

  dead time (G)
The value of the parameter (a decimal integer) represents the number of minutes of inactivity before a connection is considered dead, and it is disconnected. The deadtime only takes effect if the number of open files is zero. This is useful to stop a server's resources being exhausted by a large number of inactive connections. Most clients have an auto-reconnect feature when a connection is broken so in most cases this parameter should be transparent to users. A deadtime of zero indicates that no auto-disconnection should be performed. Default:
     dead time = 0 Example:
     dead time = 15

  debug level (G)
The value of the parameter (an integer) allows the debug level (logging level) to be specified in the smb.conf file. This is to give greater flexibility in the configuration of the system. The default will be the debug level specified on the command line. Example:
     debug level = 3

  default (G)
See default service.

  default service (G)
A synonym for this parameter is 'default'. This parameter specifies the name of a service which will be connected to if the service actually requested cannot be found. Note that the square brackets are NOT given in the parameter value (see example below). There is no default value for this parameter. If this parameter is not given, attempting to connect to a nonexistent service results in an error. Typically the default service would be a public, read-only service. Example:
     default service = def_serv

  deny hosts (B)
A synonym for this parameter is 'hosts deny'. The opposite of 'allow hosts' - hosts listed here are NOT permitted access to services unless the specific services have their own lists to override this one. Where the lists conflict, the 'allow' list takes precedence. Default:
     none (ie., no hosts specifically excluded) Example:
      deny hosts = 150.203.4. badhost.mynet.edu.au

  dfree command (G)
The dfree command setting should only be used on systems where a problem occurs with the internal disk space calculations. This has been known to happen with Ultrix, but may occur with other operating systems. The symptom that was seen was an error of "Abort Retry Ignore" at the end of each directory listing. This setting allows the replacement of the internal routines to calculate the total disk space and amount available with an external routine. The example below gives a possible script that might fulfill this function. The external program will be passed a single parameter indicating a directory in the filesystem being queried. This will typically consist of the string "./". The script should return two integers in ascii. The first should be the total disk space in blocks, and the second should be the number of available blocks. An optional third return value can give the block size in bytes. The default blocksize is 1024 bytes. Note: Your script should NOT be setuid or setgid and should be owned by (and writable only by) root! Default:
     By default internal routines for determining the disk capacity and remaining space will be used. Example:
     dfree command = /usr/local/smb/dfree
    Where the script dfree (which must be made executable) could be
     #!/bin/sh
     df $1 | tail -1 | awk '{print $2" "$4}'
    Note that you may have to replace the command names with full path names on some systems.

  directory (S)
See path.

  dont descend (S)
There are certain directories on some systems (eg., the /proc tree under Linux) that are either not of interest to clients or are infinitely deep (recursive). This parameter allows you to specify a comma-delimited list of directories that the server should always show as empty. Default:
     none (ie., all directories are OK to descend) Example:
      dont descend = /proc,/dev

  guest account (G)
This is a username which will be used for access to services which are specified as 'guest ok' (see below). Whatever privileges this user has will be available to any client connecting to a guest service. Typically this user will exist in the password file, but will not have a valid login. If a username is specified in a given service, the specified username overrides this one. Default:
     specified at compile time Example:
     guest account = nobody

  guest ok (S)
See public.

  guest only (S)
If this parameter is 'yes' for a service, then only guest connections to the service are permitted. This parameter will have no affect if "guest ok" or "public" is not set for the service. See the section below on user/password validation for more information about this option. Default:
     guest only = no Example:
     guest only = yes

  hosts allow (B)
See allow hosts.

  hosts deny (B)
See deny hosts.

  keep alive (G)
The value of the parameter (an integer) represents the number of seconds between 'keepalive' packets. If this parameter is zero, no keepalive packets will be sent. Keepalive packets, if sent, allow the server to tell whether a client is still present and responding. Keepalives should NOT be used if the socket being used has the SO_KEEPALIVE attribute set on it. The server will attempt to set this attribute on client connections anyway. Basically you should only use this option if you strike difficulties. Default:
     keep alive = 0 Example:
     keep alive = 60

  locking (B)
This controls whether or not locking will be performed by the server in response to lock requests from the client. If "locking = no", all lock and unlock requests will appear to succeed and all lock queries will indicate that the queried lock is clear. If "locking = yes", real locking will be performed by the server. Locking may be controlled on a service-by-service basis, but would usually be specified globally. Be careful about disabling locking either globally or in a specific service, as lack of locking may result in data corruption. Default:
     locking = yes Example:
     locking = no

  lpq command (B)
This parameter specifies the command to be executed on the server host in order to obtain "lpq"-style printer status information. This information will be parsed by the server and returned to clients connected using the COREPLUS level protocol or lower ONLY. This command should be a program or script which takes a printer name as its only parameter and outputs printer status information for the specified printer in the lpq format. See lpq (1). Some clients (notably Windows for Workgroups) do not correctly send the connection number for the printer they are requesting status information about. To get around this, the server reports on the first printer service connected to by the client. This only happens if the connection number sent is invalid. Note that it is good practice to include the absolute path in the lpq command as the PATH may not be available to the server. Default:
     lpq command = lpq -P Example:
     lpq command = /usr/local/samba/mylpq.scr

  magic output (B)
This parameter specifies the name of a file which will contain output created by a magic script (see magic script below). Warning: If two clients use the same magic script in the same directory the output file content is undefined. Default:
     magic output = <magic script name>.out Example:
     magic output = myfile.txt

  magic script (B)
This parameter specifies the name of a file which, if opened, will be executed by the server when the file is closed. This allows a Unix script to be sent to the Samba host and executed on behalf of the connected user. Scripts executed in this way will be deleted upon completion, permissions permitting. If the script generates output, output will be sent to the file specified by the magic output parameter (see above). Note that some shells are unable to interpret scripts containing carriage-return-linefeed instead of linefeed as the end-of-line marker. Magic scripts must be executable "as is" on the host, which for some hosts and some shells will require filtering at the DOS end. Magic scripts are EXPERIMENTAL and should NOT be relied upon. Default:
     None. Magic scripts disabled. Example:
     magic script = user.csh

  mangled names (G)
This controls whether non-DOS names under Unix should be mapped to DOS-compatible names ("mangled") and made visible, or whether non-DOS names should simply be ignored. The mangling algorithm is as follows:
    - the first (up to) five alphanumeric characters before the rightmost dot of the filename are preserved, forced to upper case, and appear as the first (up to) five characters of the mangled name. - a tilde ("~") is appended to the first part of the mangled name, followed by a two-character unique sequence, based on the origonal root name (i.e., the original filename minus its final extension). The final extension is included in the hash calculation only if it contains any upper case characters or is longer than three characters. - the first three alphanumeric characters of the final extension are preserved, forced to upper case and appear as the extension of the mangled name. The final extension is defined as that part of the original filename after the rightmost dot. If there are no dots in the filename, the mangled name will have no extension (except in the case of hidden files - see below). - files whose Unix name begins with a dot will be presented as DOS hidden files. The mangled name will be created as for other filenames, but with the leading dot removed and "___" as its extension regardless of actual original extension (that's three underscores).
The two-digit hash value consists of upper case alphanumeric characters. This algorithm can cause name collisions only if files in a directory share the same first five alphanumeric characters. The probability of such a clash is 1/1300. The name mangling (if enabled) allows a file to be copied between Unix directories from DOS while retaining the long Unix filename. Unix files can be renamed to a new extension from DOS and will retain the same basename. Mangled names do not change between sessions. Default:
     mangled names = yes Example:
     mangled names = no

  mangled stack (G)
This parameter controls the number of mangled names that should be cached in the Samba server. This stack is a list of recently mangled base names (extensions are only maintained if they are longer than 3 characters or contains upper case characters). The larger this value, the more likely it is that mangled names can be successfully converted to correct long Unix names. However, large stack sizes will slow most directory access. Smaller stacks save memory in the server (each stack element costs 256 bytes). It is not possible to guarantee correct long file names, so be prepared for some surprises! Default:
     mangled stack = 50 Example:
     mangled stack = 100

  map hidden (B)
This controls whether DOS style hidden files should be mapped to Unix execute bits. Default:
     map hidden = no Example:
     map hidden = yes

  map system (B)
This controls whether DOS style system files should be mapped to Unix execute bits. Default:
     map system = no Example:
     map system = yes

  max packet (G)
See packet size.

  max xmit (G)
This is the upper limit on the packet size that will be negotiated with the client. This is normally set to quite a high value and the negotiation ensures that a value appropriate for the client is chosen. In some cases a buggy client may negotiate a packet size beyond it's capabilities so this parameter can be used to ensure correct operation. The negotiated xmit size affects all packets except the raw read and write protocols. These are covered by the "packet size" parameter. Default:
     32767 Example:
     max xmit = 1024

  packet size (G)
The maximum transmit packet size during a raw read. This option is no longer implemented as of version 1.7.00, and is kept only so old configuration files do not become invalid.

  password level (G)
Some client/server conbinations have difficulty with mixed-case passwords. One offending client is Windows for Workgroups, which for some reason forces passwords to upper case when using the LANMAN1 protocol, but leaves them alone when using COREPLUS! This parameter defines the maximum number of characters that may be upper case in passwords. For example, say the password given was "FRED". If password level is set to 1 (one), the following combinations would be tried if "FRED" failed: "Fred", "fred", "fRed", "frEd", "freD". If password level was set to 2 (two), the following combinations would also be tried: "FRed", "FrEd", "FreD", "fREd", "fReD", "frED". And so on. The higher value this paraneter is set to the more likely it is that a mixed case password will be matched against a single case password. However, you should be aware that use of this parameter reduces security and increases the time taken to process a new connection. A value of zero will cause only two attempts to be made - the password as is and the password in all-lower case. Default:
     password level = 0 Example:
     password level = 8

  path (S)
A synonym for this parameter is 'directory'. This parameter specifies a directory to which the user of the service is to be given access. In the case of printable services, this is where print data will spool prior to being submitted to the host for printing. For a printable service offering guest access, the service should be readonly and the path should be world-writable and have the sticky bit set. This is not mandatory of course, but you probably won't get the results you expect if you do otherwise. Note that this path will be based on 'root dir' if one was specified. Default:
     none Example:
     path = /home/fred

  print command (B)
After a print job has finished spooling to a service, this command will be used via a system() call to process the spool file. Typically the command specified will submit the spool file to the host's printing subsystem, but there is no requirement that this be the case. The server will not remove the spool file, so whatever command you specify should remove the spool file when it has been processed, otherwise you will need to manually remove old spool files. The print command is simply a text string. It will be used verbatim, with two exceptions: The first occurrence of "%s" will be replaced by the appropriate spool file name, and the first occurrence of "%p" will be replaced by the appropriate printer name. The spool file name is generated automatically by the server, the printer name is discussed below. The print command MUST contain at least one occurrence of "%s" - the "%p" is optional. At the time a job is submitted, if no printer name is supplied the "%p" will be silently removed from the printer command. If specified in the [global] section, the print command given will be used for any printable service that does not have its own print command specified. If there is neither a specified print command for a printable service nor a global print command, spool files will be created but not processed and (most importantly) not removed. Default:
     none Example:
     print command = lpr -r -P%p %s

  print ok (S)
See printable.

  printable (S)
A synonym for this parameter is 'print ok'. If this parameter is 'yes', then clients may open, write to and submit spool files on the directory specified for the service. Note that a printable service will ALWAYS allow writing to the service path (user privileges permitting) via the spooling of print data. The 'read only' parameter controls only non-printing access to the resource. Default:
     printable = no Example:
     printable = yes

  printcap name (G)
This parameter may be used to override the compiled-in default printcap name used by the server (usually /etc/printcap). See the discussion of the [printers] section above for reasons why you might want to do this. Default:
     printcap name = /etc/printcap Example:
     printcap name = /etc/myprintcap

  printer (B)
A synonym for this parameter is 'printer name'. This parameter specifies the name of the printer to which print jobs spooled through a printable service will be sent. If specified in the [global] section, the printer name given will be used for any printable service that does not have its own printer name specified. Default:
     none (but may be 'lp' on many systems) Example:
     printer name = laserwriter

  printer name (B)
See printer.

  protocol (G)
The value of the parameter (a string) is the highest protocol level that will be supported by the server. Possible values are CORE, COREPLUS and LANMAN1. It is currently recommended that COREPLUS (the default) is used as it is the most tested and stable. You may, however, get better performance out of LANMAN1, and in the interests of academic research it is the default protocol :-). Default:
    protocol = LANMAN1 Example:
    protocol = COREPLUS

  public (S)
A synonym for this parameter is 'guest ok'. If this parameter is 'yes' for a service, then no password is required to connect to the service. Privileges will be those of the specified user, or of the global guest account if no specific user is given for the service. See the section below on user/password validation for more information about this option. Default:
     public = no Example:
     public = yes

  read only (S)
See writable and write ok. Note that this is an inverted synonym for writable and write ok.

  read raw (G)
This parameter controls whether or not the server will support raw reads when transferring data to clients. If enabled, raw reads allow reads of 65535 bytes in one packet. This typically provides a major performance benefit. However, some clients either negotiate the allowable block size incorrectly or are incapable of supporting larger block sizes, and for these clients you may need to disable raw reads. In general this parameter should be viewed as a system tuning tool and left severely alone. See also write raw. Default:
     read raw = yes Example:
     read raw = no

  root (G)
See root directory.

  root dir (G)
See root directory.

  root directory (G)
Synonyms for this parameter are 'root dir' and 'root'. The server will chroot() to this directory on startup. This is not strictly necessary for secure operation. Even without it the server will deny access to files not in one of the service entries. It will also check for, and deny access to, soft links to other parts of the filesystem, or attempts to use .. in file names to access other directories. Adding a "root dir" entry other than "/" adds an extra level of security, but at a price. It absolutely ensures that no access is given to files not in the sub-tree specified in the "root dir" option, *including* some files needed for complete operation of the server. To maintain full operability of the server you will need to mirror some system files into the "root dir" tree. In particular you will need to mirror /etc/passwd (or a subset of it), and any binaries or configuration files needed for printing (if required). The set of files that must be mirrored is operating system dependent. Default:
     root directory = / Example:
     root directory = /homes/smb

  security (G)
This option does NOT affect how Samba (smbd) handles security, but it does affect how clients respond to Samba. The option sets the "security mode bit" in replies to protocol negotiations to turn share level security on or off. Clients decide based on this bit whether (and how) to transfer user and password information to the server. The default is "security=SHARE", mainly because Windows for Workgroups will ignore user-supplied passwords when connecting network drives if this parameter is set to USER. This is an annoying bug in Windows for Workgroups. Default:
     security = SHARE Example:
     security = USER

  set directory (S)
If 'set directory = no', then users of the service may not use the setdir command to change directory. The setdir comand is only implemented in the Digital Pathworks client. See the Pathworks documentation for details. Default:
     set directory = no Example:
     set directory = yes

  user (S)
See username.

  username (S)
A synonym for this parameter is 'user'. This parameter specifies the default user name (login name) used to access this service. If none is specified AND the service is not a guest access service, this parameter will default to the name of the service. Multiple users may be specified in a comma-delimited list, in which case the supplied password will be tested against each username in turn (left to right). See the section below on username/password validation for more information on how this parameter determines access to the services. Default:
     The guest account if a guest service, else the name of the service. Examples:
     username = fred
     username = fred,mary,jack,jane

  wide links (B)
This parameter controls whether or not links in the Unix file system may be followed by the server. Links that point to areas within the directory tree exported by the server are always allowed; this parameter controls access only to areas that are outside the directory tree being exported. Default:
     wide links = yes Example:
     wide links = no

  write ok (S)
See writable and read only.

  writable (S)
A synonym for this parameter is 'write ok'. An inverted synonym is 'read only'. If this parameter is 'no', then users of a service may not create or modify files in the service's directory. Note that a printable service ('printable = yes') will ALWAYS allow writing to the directory (user privileges permitting), but only via spooling operations. Default:
     writable = no Examples:
     read only = no
     writable = yes
     write ok = yes

  write raw (G)
This parameter controls whether or not the server will support raw writes when transferring data from clients. If enabled, raw writes allow writes of up to 65535 bytes in a single message. This typically provides a major performance benefit. However, some clients either negotiate the allowable block size incorrectly or are incapable of supporting larger block sizes, and for these clients you may need to disable raw writes. In general this parameter should be viewed as a system tuning tool and left severely alone. See also read raw. Default:
     write raw = yes Example:
     write raw = no

NOTE ABOUT USERNAME/PASSWORD VALIDATION
There are a number of ways in which a user can connect to a service. The server follows the following steps in determining if it will allow a connection to a specified service. If all the steps fail then the connection request is rejected. If one of the steps pass then the following steps are not checked. If the service is marked "guest only = yes" then steps 1,2 and 3 are skipped Step 1: If the client has passed a username/password pair and that username/password pair is validated by the unix systems password programs then the connection is made as that username. Step 2: If a "user = " field is given in the smb.conf file for the service and the client has supplied a password, and that password matches (according to the unix systems password checking) with the username from the user= field then the connection is made as the username in the "user=" line. Step 3: If the client has made a earlier "validation request" which was successful, and has supplied the validation user id from that request then the connection is made as the username from the earlier validation request. An extra condition applies to this, that if the earlier validation request was a guest validation and the current service being requested is not guest accessible then the connection is not made (ie. this step fails). Step 4: If a "user =" line was specified for the service and the service is a guest service then the connection is made as the username from the "user=" line irrespective of the supplied password. Step 5: If the service is a guest service then a connection is made as the username given in the "guest account =" in the [globals] section, or as the guest user given in the makefile if no "guest account=" is specified, irrespective of the supplied password.

WARNINGS
Although the configuration file permits service names to contain spaces, your client software may not. Spaces will be ignored in comparisons anyway, so it shouldn't be a problem - but be aware of the possibility. On a similar note, many clients - especially DOS clients - limit service names to eight characters. Smbd has no such limitation, but attempts to connect from such clients will fail if they truncate the service names. For this reason you should probably keep your service names down to eight characters in length. Use of the [homes] and [printers] special sections make life for an administrator easy, but the various combinations of default attributes can be tricky. Take extreme care when designing these sections. In particular, ensure that the permissions on spool directories are correct.

VERSION
This man page is correct for version 1.7.00 of the Samba suite, plus some of the recent patches to it. These notes will necessarily lag behind development of the software, so it is possible that your version of the server has extensions or parameter semantics that differ from or are not covered by this man page. Please notify these to the address below for rectification. Prior to version 1.5.21 of the Samba suite, the configuration file was radically different (more primitive). If you are using a version earlier than 1.5.21, it is STRONGLY recommended that you upgrade.

OPTIONS
Not applicable.

FILES
Not applicable.

ENVIRONMENT VARIABLES
Not applicable.

SEE ALSO
smbd (8), smbclient (1), nmbd (8), testparm (1), testprns (1), lpq (1), hosts_access (5)

DIAGNOSTICS
[This section under construction] Most diagnostics issued by the server are logged in a specified log file. The log file name is specified at compile time, but may be overridden on the smbd (see smbd(8)) command line. The number and nature of diagnostics available depends on the debug level used by the server. If you have problems, set the debug level to 3 and peruse the log files. Most messages are reasonably self-explanatory. Unfortunately, at time of creation of this man page the source code is still too fluid to warrant describing each and every diagnostic. At this stage your best bet is still to grep the source code and inspect the conditions that gave rise to the diagnostics you are seeing.

BUGS
None known. Please send bug reports, comments and so on to:
    Andrew.Tridgell@anu.edu.au (Andrew Tridgell)
        or to the mailing list
    samba@listproc.anu.edu.au
You may also like to subscribe to the announcement channel
    samba-announce@listproc.anu.edu.au
To subscribe to these lists send a message to listproc@listproc.anu.edu.au with a body of "subscribe samba Your Name" or "subscribe samba-announce Your Name". Errors or suggestions for improvements to the Samba man pages should be mailed to:
    Karl.Auer@anu.edu.au (Karl Auer)

CREDITS
The original Samba software and related utilities were created by Andrew Tridgell (Andrew.Tridgell@anu.edu.au). Andrew is also the Keeper of the Source for this project. This man page written by Karl Auer (Karl.Auer@anu.edu.au) Contributors to the project are (in alphabetical order by email address):
 Adams, Graham
     (gadams@ddrive.demon.co.uk)
 Allison, Jeremy
     (jeremy@netcom.com)
 Andrus, Ross
     (ross@augie.insci.com)
 Auer, Karl
     (Karl.Auer@anu.edu.au)
 Bogstad, Bill
     (bogstad@cs.jhu.edu)
 Boreham, Bryan
     (Bryan@alex.com)
 Boreham, David
     (davidb@ndl.co.uk)
 Butler, Michael
     (imb@asstdc.scgt.oz.au)
 ???
    (charlie@edina.demon.co.uk)
 Chua, Michael
     (lpc@solomon.technet.sg)
 Cochran, Marc
    (mcochran@wellfleet.com)
 Dey, Martin N
     (mnd@netmgrs.co.uk)
 Errath, Maximilian
     (errath@balu.kfunigraz.ac.at)
 Fisher, Lee
     (leefi@microsoft.com)
 Foderaro, Sean
     (jkf@frisky.Franz.COM)
 Greer, Brad
     (brad@cac.washington.edu)
 Griffith, Michael A
     (grif@cs.ucr.edu)
 Grosen, Mark
     (MDGrosen@spectron.COM)
 ????
     (gunjkoa@dep.sa.gov.au)
 Haapanen, Tom
     (tomh@metrics.com)
 Hench, Mike
    (hench@cae.uwm.edu)
 Horstman, Mark A
     (mh2620@sarek.sbc.com)
 Hudson, Tim
     (tim.hudson@gslmail.mincom.oz.au)
 Hulthen, Erik Magnus
     (magnus@axiom.se)
 ???
    (imb@asstdc.scgt.oz.au)
 Iversen, Per Steinar
     (iversen@dsfys1.fi.uib.no)
 Kaara, Pasi
     (ppk@atk.tpo.fi)
 Karman, Merik
     (merik@blackadder.dsh.oz.au)
 Kiff, Martin
     (mgk@newton.npl.co.uk)
 Kiick, Chris
     (cjkiick@flinx.b11.ingr.com)
 Kukulies, Christoph
     (kuku@acds.physik.rwth-aachen.de)
 ???
    (lance@fox.com)
 Lendecke, Volker
     (lendecke@namu01.gwdg.de)
 ???
     (lonnie@itg.ti.com)
 Mahoney, Paul Thomas
     (ptm@xact1.xact.com)
 Mauelshagen, Heinz
     (mauelsha@ez.da.telekom.de)
 Merrick, Barry G
     (bgm@atml.co.uk)
 Mol, Marcel
     (marcel@fanout.et.tudeflt.nl)
 ???
    (njw@cpsg.com.au)
 ???
    (noses@oink.rhein.de)
 Owens, John
     (john@micros.com)
 Pierson, Jacques
     (pierson@ketje.enet.dec.com)
 Powell, Mark
     (mark@scot1.ucsalf.ac.uk)
 Reiz, Steven
     (sreiz@aie.nl)
 Schlaeger, Joerg
     (joergs@toppoint.de)
 S{rkel{, Vesa
     (vesku@rankki.kcl.fi)
 Tridgell, Andrew
     (Andrew.Tridgell@anu.edu.au)
 Troyer, Dean
     (troyer@saifr00.ateng.az.honeywell.com)
 Wakelin, Ross
     (rossw@march.co.uk)
 Wessels, Stefan
     (SWESSELS@dos-lan.cs.up.ac.za)
 Young, Ian A
     (iay@threel.co.uk)
 van der Zwan, Paul
     (paulzn@olivetti.nl) (These Credits are simply those who appear in the change log for this project as having contributed material. If you want your place in the sun, patch the an page!)