Smb.conf

from HTYP, the free directory anyone can edit if they can prove to me that they're not a spambot
Revision as of 17:38, 22 January 2006 by Woozle (talk | contribs) (partial transcription)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Computing: Linux: Samba: smb.conf

Manpage

NAME

smb.conf - The configuration file for the Samba suite

SYNOPSIS

The smb.conf file is a configuration file for the Samba suite. smb.conf contains runtime configuration information for the Samba programs. The smb.conf file is designed to be configured and administered by the swat(8) program. The complete description of the file format and possible parameters held within are here for reference purposes.

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 (``;) or a hash (``#) character is ignored, as are lines containing only whitespace.

Any line ending in a ``\ is continued on the next line in the customary UNIX fashion.

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.

SECTION DESCRIPTIONS

Each section in the configuration file (except for the [global] section) describes a shared resource (known as a ``share). The section name is the name of the shared resource and the parameters within the section define the shares attributes.

There are three special sections, [global], [homes] and [printers], which are described under special sections. The following notes apply to ordinary section descriptions.

A share 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.

Sections are either file share 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).

Sections may be designated guest services, in which case no password is required to access them. A specified UNIX guest account is used to define access privileges in this case.

Sections other than guest services will require a password to access them. The client provides the username. As older clients only provide passwords and not usernames, you may specify a list of usernames to check against the password using the ``user = option in the share definition. For modern clients such as Windows 95/98/ME/NT/2000, this should not be necessary.

The access rights granted by the server are masked by the access rights granted to the specified or guest UNIX 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 share. The user has write access to the path /home/bar. The share is accessed via the share name "foo":

Example 1.

[foo]
 path = /home/bar
 read only = read only = no

The following sample section defines a printable share. The share is read-only, 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):

Example 2.

[aprinter]
 path   =   /usr/spool/public
 read   only   =   yes
 printable    =    yes  
 guest ok = yes

SPECIAL SECTIONS

The [global] section
Parameters in this section apply to the server as a whole, or are defaults for sections that 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 sections are scanned. If a match is found, it is used. If no match is found, the requested section name is treated as a username and looked up in the local password file. If the name exists and the correct password has been given, a share is created by cloning the [homes] section.

Some modifications are then made to the newly created share:

  • The share name is changed from homes to the located username.
  • If no path was given, the path is set to the user's home directory.

If you decide to use a path = line in your [homes] section, you may find it useful to use the %S macro. For example : 

path = /data/pchome/%S

...is useful if you have different home directories for your PCs than for UNIX access.

This is a fast and simple way to give a large number of clients access to their home directories with a minimum of fuss.

A similar process occurs if the requested section name is "homes", except that the share name is not changed to that of the requesting user.

This method of using the [homes] section works well if different users share a client PC.

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:

Example 3.

[homes]
 read only = no

An important point is that if guest access is specified in the [homes] section, all home directories will be visible to all clients without a password. In the very unlikely event that this is actually desirable, it is wise to also specify read only access.

The browseable flag for auto home directories will be inherited from the global browseable flag, not the [homes] browseable flag. This is useful as it means setting browseable = no in the [homes] section will hide the [homes] share but make any auto home directories visible.

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 sections 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 section name is treated as a printer name and the appropriate printcap file is scanned to see if the requested section name is a valid printer share name. If a match is found, a new printer share is created by cloning the [printers] section.

A few modifications are then made to the newly created share:

  • The share 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 share does not permit guest access and no username was given, the username is set to the located printer name.

The [printers] service MUST be printable - if you specify otherwise, the server will refuse to load the configuration file.

Typically the path specified is that of a world-writeable spool directory with the sticky bit set on it. A typical [printers] entry looks like this:

Example 4.

[printers]
 path    =    /usr/spool/public
 guest ok = 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...
                .fi

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 only recognize 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 ("|").

Note

On SYSV systems which use lpstat to determine what printers are defined on the system you may be able to use "printcap name = lpstat" to automatically obtain a list of printers. See the "printcap name" option for more details.

PARAMETERS

Parameters define the specific attributes of sections.

Some parameters are specific to the [global] section (e.g., security). Some parameters are usable in all sections (e.g., 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 can be specified in a service specific section. All S parameters can also be specified in the [global] section – in which case they will define the default behavior for all services.

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.

VARIABLE SUBSTITUTIONS

Many of the strings that are settable in the config file can take substitutions. For example the option ``path = /tmp/%u is interpreted as "path = /tmp/john" if the user connected with the username john.

These substitutions are mostly noted in the descriptions below, but there are some general substitutions which apply whenever they might be relevant. These are:

%U session username (the username that the client wanted, not necessarily the same as the one they got).
%G primary group name of %U.
%h the Internet hostname that Samba is running on.
%m the NetBIOS name of the client machine (very useful).
%L the NetBIOS name of the server. This allows you to change your config based on what the client calls you. Your server can have a "dual personality".

This parameter is not available when Samba listens on port 445, as clients no longer send this information.

%M the Internet name of the client machine.
%R the selected protocol level after protocol negotiation. It can be one of CORE, COREPLUS, LANMAN1, LANMAN2 or NT1.
%d The process id of the current server process.
%a the architecture of the remote machine. Only some are recognized, and those may not be 100% reliable. It currently recognizes Samba, Windows for Workgroups, Windows 95, Windows NT and Windows 2000. Anything else will be known as``UNKNOWN. If it gets it wrong sending a level 3 log to samba@samba.org should allow it to be fixed.
%I The IP address of the client machine.
%T the current date and time.
%D Name of the domain or workgroup of the current user.
%$(envvar) The value of the environment variable envvar.

The following substitutes apply only to some configuration options (only those that are used when a connection has been established):

%S the name of the current service, if any.
%P the root directory of the current service, if any.
%u username of the current service, if any.
%g primary group name of %u.
%H the home directory of the user given by %u.
%N the name of your NIS home directory server. This is obtained from your NIS auto.map entry. If you have not compiled Samba with the --with-automount option, this value will be the same as %L.
%p the path of the service's home directory, obtained from your NIS auto.map entry. The NIS auto.map entry is split up as "%N:%p".

There are some quite creative things that can be done with these substitutions and other smb.conf options.

NAME MANGLING

Samba supports "name mangling" so that DOS and Windows clients can use files that don't conform to the 8.3 format. It can also be set to adjust the case of 8.3 format filenames.

There are several options that control the way mangling is performed, and they are grouped here rather than listed separately. For the defaults look at the output of the testparm program.

All of these options can be set separately for each service (or globally, of course).

The options are:

case sensitive = yes/no/auto
controls whether filenames are case sensitive. If they aren't, Samba must do a filename search and match on passed names. The default setting of auto allows clients that support case sensitive filenames (Linux CIFSVFS and smbclient 3.0.5 and above currently) to tell the Samba server on a per-packet basis that they wish to access the file system in a case-sensitive manner (to support UNIX case sensitive semantics). No Windows or DOS system supports case-sensitive filename so setting this option to auto is that same as setting it to no for them. Default auto.
default case = upper/lower
controls what the default case is for new filenames. Default lower.
preserve case = yes/no
controls whether new files are created with the case that the client passes, or if they are forced to be the "default" case. Default yes.
short preserve case = yes/no
controls if new files which conform to 8.3 syntax, that is all in upper case and of suitable length, are created upper case, or if they are forced to be the "default" case. This option can be used with "preserve case = yes" to permit long filenames to retain their case, while short names are lowercased. Default yes.

By default, Samba 3.0 has the same semantics as a Windows NT server, in that it is case insensitive but case preserving.

NOTE ABOUT USERNAME/PASSWORD VALIDATION

There are a number of ways in which a user can connect to a service. The server uses the following steps in determining if it will allow a connection to a specified service. If all the steps fail, the connection request is rejected. However, if one of the steps succeeds, the following steps are not checked.

If the service is marked "guest only = yes" and the server is running with share-level security ("security = share", steps 1 to 5 are skipped.

  1. If the client has passed a username/password pair and that username/password pair is validated by the UNIX system's password programs, the connection is made as that username. This includes the \\server\service%username method of passing a username.
  2. If the client has previously registered a username with the system and now supplies a correct password for that username, the connection is allowed.
  3. The client's NetBIOS name and any previously used usernames are checked against the supplied password. If they match, the connection is allowed as the corresponding user.
  4. If the client has previously validated a username/password pair with the server and the client has passed the validation token, that username is used.
  5. 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 system's password checking) with one of the usernames from the "user =" field, the connection is made as the username in the "user =" line. If one of the usernames in the "user =" list begins with a "@", that name expands to a list of names in the group of the same name.
  6. If the service is a guest service, a connection is made as the username given in the ``guest account = for the service, irrespective of the supplied password.

EXPLANATION OF EACH PARAMETER

abort shutdown script (G)
This parameter only exists in the HEAD cvs branch This a full path name to a script called by smbd(8) that should stop a shutdown procedure issued by the shutdown script.
  • This command will be run as user.
  • Default: abort shutdown script =
  • Example: abort shutdown script = /sbin/shutdown -c
acl compatibility (S)
This parameter specifies what OS ACL semantics should be compatible with. Possible values are winnt for Windows NT 4,win2k for Windows 2000 and above and auto. If you specify auto, the value for this parameter will be based upon the version of the client. There should be no reason to change this parameter from the default.
  • Default: acl compatibility = Auto
  • Example: acl compatibility = win2k
add group script (G)
This is the full pathname to a script that will be runAS ROOT by smbd(8) when a new group is requested. It will expand any %g to the group name passed. This script is only useful for installations using the Windows NT domain administration tools. The script is free to create a group with an arbitrary name to circumvent unix group name restrictions. In that case the script must print the numeric gid of the created group on stdout.
  • No default
add machine script (G)
This is the full pathname to a script that will be run bysmbd(8) when a machine is added to it's domain using the administrator username and password method.
  • This option is only required when using sam back-ends tied to the Unix uid method of RID calculation such as smbpasswd. This option is only available in Samba 3.0.
  • Default: add machine script =
  • Example: add machine script = /usr/sbin/adduser -n -g machines -c Machine -d /dev/null -s /bin/false %u
addprinter command (G)
With the introduction of MS-RPC based printing support for Windows NT/2000 clients in Samba 2.2, The MS Add Printer Wizard (APW) icon is now also available in the "Printers..." folder displayed a share listing. The APW allows for printers to be add remotely to a Samba or Windows NT/2000 print server.
  • For a Samba host this means that the printer must be physically added to the underlying printing system. The add printer command defines a script to be run which will perform the necessary operations for adding the printer to the print system and to add the appropriate service definition to the smb.conf file in order that it can be shared by smbd(8).
  • The addprinter command is automatically invoked with the following parameter (in order):
    • printer name
    • share name
    • port name
    • driver name
    • location
    • Windows 9x driver location
  • All parameters are filled in from the PRINTER_INFO_2 structure sent by the Windows NT/2000 client with one exception. The "Windows 9x driver location" parameter is included for backwards compatibility only. The remaining fields in the structure are generated from answers to the APW questions.
  • Once the addprinter command has been executed, smbd will reparse the smb.conf to determine if the share defined by the APW exists. If the sharename is still invalid, then smbd will return an ACCESS_DENIED error to the client.
  • The "add printer command" program can output a single line of text, which Samba will set as the port the new printer is connected to. If this line isn't output, Samba won't reload its printer shares.
  • Default: addprinter command =
  • Example: addprinter command = /usr/bin/addprinter
add share command (G)
Samba 2.2.0 introduced the ability to dynamically add and delete shares via the Windows NT 4.0 Server Manager. Theadd share command is used to define an external program or script which will add a new service definition to smb.conf. In order to successfully execute the add share command, smbd requires that the administrator be connected using a root account (i.e. uid == 0).
  • When executed, smbd will automatically invoke theadd share command with four parameters.
    • configFile - the location of the global smb.conf file.
    • shareName - the name of the new share.
    • pathName - path to an existing directory on disk.
    • comment - comment string to associate with the new share.
  • This parameter is only used for add file shares. To add printer shares, see the addprinter command.
  • Default: add share command =
  • Example: add share command = /usr/local/bin/addshare
add user script (G)
This is the full pathname to a script that will be run AS ROOT by smbd(8) under special circumstances described below.
  • Normally, a Samba server requires that UNIX users are created for all users accessing files on this server. For sites that use Windows NT account databases as their primary user database creating these users and keeping the user list in sync with the Windows NT PDC is an onerous task. This option allows smbd to create the required UNIX usersON DEMAND when a user accesses the Samba server.
  • In order to use this option, smbd(8) must NOT be set to security = share and add user script must be set to a full pathname for a script that will create a UNIX user given one argument of %u, which expands into the UNIX user name to create.
  • When the Windows user attempts to access the Samba server, at login (session setup in the SMB protocol) time, smbd(8) contacts the password server and attempts to authenticate the given user with the given password. If the authentication succeeds then smbd attempts to find a UNIX user in the UNIX password database to map the Windows user into. If this lookup fails, and add user script is set then smbd will call the specified script AS ROOT, expanding any %u argument to be the user name to create.
  • If this script successfully creates the user then smbd will continue on as though the UNIX user already existed. In this way, UNIX users are dynamically created to match existing Windows NT accounts.
  • See also: security, password server, delete user script.
  • Default: add user script =
  • Example: add user script = /usr/local/samba/bin/add_user %u
add user to group script (G)
Full path to the script that will be called when a user is added to a group using the Windows NT domain administration tools. It will be run by smbd(8)AS ROOT. Any %g will be replaced with the group name and any %u will be replaced with the user name.
  • Note that the adduser command used in the example below does not support the used syntax on all systems.
  • Default: add user to group script =
  • Example: add user to group script = /usr/sbin/adduser %u %g
admin users (S)
This is a list of users who will be granted administrative privileges on the share. This means that they will do all file operations as the super-user (root).
  • You should use this option very carefully, as any user in this list will be able to do anything they like on the share, irrespective of file permissions.
  • Default: admin users =
  • Example: admin users = jason
afs share (S)
This parameter controls whether special AFS features are enabled for this share. If enabled, it assumes that the directory exported via the path parameter is a local AFS import. The special AFS features include the attempt to hand-craft an AFS token if you enabled --with-fake-kaserver in configure.
  • Default: afs share = no
afs username map (G)
If you are using the fake kaserver AFS feature, you might want to hand-craft the usernames you are creating tokens for. For example this is necessary if you have users from several domain in your AFS Protection Database. One possible scheme to code users as DOMAIN+User as it is done by winbind with the + as a separator.
  • The mapped user name must contain the cell name to log into, so without setting this parameter there will be no token.
  • Default: afs username map =
  • Example: afs username map = %u@afs.samba.org
algorithmic rid base (G)
This determines how Samba will use its algorithmic mapping from uids/gid to the RIDs needed to construct NT Security Identifiers.
  • Setting this option to a larger value could be useful to sites transitioning from WinNT and Win2k, as existing user and group rids would otherwise clash with sytem users etc.
  • All UIDs and GIDs must be able to be resolved into SIDs for the correct operation of ACLs on the server. As such the algorithmic mapping can't be "turned off", but pushing it "out of the way" should resolve the issues. Users and groups can then be assigned "low" RIDs in arbitary-rid supporting backends.
  • Default: algorithmic rid base = 1000
  • Example: algorithmic rid base = 100000
allow trusted domains (G)
This option only takes effect when the security option is set to server or domain. If it is set to no, then attempts to connect to a resource from a domain or workgroup other than the one which smbd is running in will fail, even if that domain is trusted by the remote server doing the authentication.
  • This is useful if you only want your Samba server to serve resources to users in the domain it is a member of. As an example, suppose that there are two domains DOMA and DOMB. DOMB is trusted by DOMA, which contains the Samba server. Under normal circumstances, a user with an account in DOMB can then access the resources of a UNIX account with the same account name on the Samba server even if they do not have an account in DOMA. This can make implementing a security boundary difficult.
  • Default: allow trusted domains = yes
announce as (G)
This specifies what type of server nmbd(8) will announce itself as, to a network neighborhood browse list. By default this is set to Windows NT. The valid options are : "NT Server" (which can also be written as "NT"), "NT Workstation", "Win95" or "WfW" meaning Windows NT Server, Windows NT Workstation, Windows 95 and Windows for Workgroups respectively. Do not change this parameter unless you have a specific need to stop Samba appearing as an NT server as this may prevent Samba servers from participating as browser servers correctly.
  • Default: announce as = NT Server
  • Example: announce as = Win95
announce version (G)
This specifies the major and minor version numbers that nmbd will use when announcing itself as a server. The default is 4.9. Do not change this parameter unless you have a specific need to set a Samba server to be a downlevel server.
  • Default: announce version = 4.9
  • Example: announce version = 2.0
auth methods (G)
This option allows the administrator to chose what authentication methods smbd will use when authenticating a user. This option defaults to sensible values based on security. This should be considered a developer option and used only in rare circumstances. In the majority (if not all) of production servers, the default setting should be adequate.
  • Each entry in the list attempts to authenticate the user in turn, until the user authenticates. In practice only one method will ever actually be able to complete the authentication.
  • Possible options include guest (anonymous access), sam (lookups in local list of accounts based on netbios name or domain name), winbind (relay authentication requests for remote users through winbindd), ntdomain (pre-winbindd method of authentication for remote domain users; deprecated in favour of winbind method), trustdomain (authenticate trusted users by contacting the remote DC directly from smbd; deprecated in favour of winbind method).
  • Default: auth methods =
  • Example: auth methods = guest sam winbind
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 logged.
  • Default: available = yes
bind interfaces only (G)
This global parameter allows the Samba admin to limit what interfaces on a machine will serve SMB requests. It affects file service smbd(8) and name service nmbd(8) in a slightly different ways.
  • For name service it causes nmbd to bind to ports 137 and 138 on the interfaces listed in the interfaces parameter. nmbd also binds to the "all addresses" interface (0.0.0.0) on ports 137 and 138 for the purposes of reading broadcast messages. If this option is not set then nmbd will service name requests on all of these sockets. If bind interfaces only is set then nmbd will check the source address of any packets coming in on the broadcast sockets and discard any that don't match the broadcast addresses of the interfaces in the interfaces parameter list. As unicast packets are received on the other sockets it allowsnmbd to refuse to serve names to machines that send packets that arrive through any interfaces not listed in theinterfaces list. IP Source address spoofing does defeat this simple check, however, so it must not be used seriously as a security feature for nmbd.
  • For file service it causes smbd(8) to bind only to the interface list given in the interfaces parameter. This restricts the networks that smbd will serve to packets coming in those interfaces. Note that you should not use this parameter for machines that are serving PPP or other intermittent or non-broadcast network interfaces as it will not cope with non-permanent interfaces.
  • If bind interfaces only is set then unless the network address 127.0.0.1 is added to the interfaces parameter list smbpasswd(8) and swat(8) may not work as expected due to the reasons covered below.
  • To change a user's SMB password, the smbpasswd by default connects to the localhost - 127.0.0.1 address as an SMB client to issue the password change request. If bind interfaces only is set then unless the network address 127.0.0.1 is added to the interfaces parameter list then smbpasswd will fail to connect in it's default mode.smbpasswd can be forced to use the primary IP interface of the local host by using its smbpasswd(8)-r remote machine parameter, with remote machine set to the IP name of the primary interface of the local host.
  • The swat status page tries to connect withsmbd and nmbd at the address127.0.0.1 to determine if they are running. Not adding 127.0.0.1 will cause smbd and nmbd to always show "not running" even if they really are. This can prevent swat from starting/stopping/restarting smbd and nmbd.
  • Default: bind interfaces only = no
blocking locks (S)
This parameter controls the behavior of smbd(8) when given a request by a client to obtain a byte range lock on a region of an open file, and the request has a time limit associated with it.
  • If this parameter is set and the lock range requested cannot be immediately satisfied, samba will internally queue the lock request, and periodically attempt to obtain the lock until the timeout period expires.
  • If this parameter is set to no, then samba will behave as previous versions of Samba would and will fail the lock request immediately if the lock range cannot be obtained.
  • Default: blocking locks = yes
block size (S)
This parameter controls the behavior of smbd(8) when reporting disk free sizes. By default, this reports a disk block size of 1024 bytes.
  • Changing this parameter may have some effect on the efficiency of client writes, this is not yet confirmed. This parameter was added to allow advanced administrators to change it (usually to a higher value) and test the effect it has on client write performance without re-compiling the code. As this is an experimental option it may be removed in a future release.
  • Changing this option does not change the disk free reporting size, just the block size unit reported to the client.
  • No default
browsable
This parameter is a synonym for browseable.
browseable (S)
This controls whether this share is seen in the list of available shares in a net view and in the browse list.
  • Default: browseable = yes
browse list (G)
This controls whether smbd(8) will serve a browse list to a client doing a NetServerEnum call. Normally set to yes. You should never need to change this.
  • Default: browse list = yes
casesignames
This parameter is a synonym for case sensitive.
case sensitive (S)
See the discussion in the section #NAME MANGLING.
  • Default: case sensitive = no
change notify timeout (G)
This SMB allows a client to tell a server to "watch" a particular directory for any changes and only reply to the SMB request when a change has occurred. Such constant scanning of a directory is expensive under UNIX, hence an smbd(8) daemon only performs such a scan on each requested directory once every change notify timeout seconds.
  • Default: change notify timeout = 60
  • Example: change notify timeout = 300 # Would change the scan time to every 5 minutes.
change share command (G)
Samba 2.2.0 introduced the ability to dynamically add and delete shares via the Windows NT 4.0 Server Manager. The change share command is used to define an external program or script which will modify an existing service definition in smb.conf. In order to successfully execute the change share command, smbd requires that the administrator be connected using a root account (i.e. uid == 0).
  • When executed, smbd will automatically invoke thechange share command with four parameters.
    • configFile - the location of the global smb.conf file.
    • shareName - the name of the new share.
    • pathName - path to an existing directory on disk.
    • comment - comment string to associate with the new share.
  • This parameter is only used modify existing file shares definitions. To modify printer shares, use the "Printers..." folder as seen when browsing the Samba host.
  • Default: change share command =
  • Example: change share command = /usr/local/bin/addshare
client lanman auth (G)
This parameter determines whether or not smbclient(8) and other samba client tools will attempt to authenticate itself to servers using the weaker LANMAN password hash. If disabled, only server which support NT password hashes (e.g. Windows NT/2000, Samba, etc... but not Windows 95/98) will be able to be connected from the Samba client.
  • The LANMAN encrypted response is easily broken, due to its case-insensitive nature, and the choice of algorithm. Clients without Windows 95/98 servers are advised to disable this option.
  • Disabling this option will also disable the client plaintext auth option
  • Likewise, if the client ntlmv2 auth parameter is enabled, then only NTLMv2 logins will be attempted.
  • Default: client lanman auth = yes
client ntlmv2 auth (G)
This parameter determines whether or not smbclient(8) will attempt to authenticate itself to servers using the NTLMv2 encrypted password response.
  • If enabled, only an NTLMv2 and LMv2 response (both much more secure than earlier versions) will be sent. Many servers (including NT4 < SP4, Win9x and Samba 2.2) are not compatible with NTLMv2.
  • Similarly, if enabled, NTLMv1, client lanman auth and client plaintext auth authentication will be disabled. This also disables share-level authentication.
If disabled, an NTLM response (and possibly a LANMAN response) will be sent by the client, depending on the value of client lanman auth.
  • Note that some sites (particularly those following 'best practice' security polices) only allow NTLMv2 responses, and not the weaker LM or NTLM.
  • Default: client ntlmv2 auth = no
client plaintext auth (G)
Specifies whether a client should send a plaintext password if the server does not support encrypted passwords.
  • Default: client plaintext auth = yes
client schannel (G)
This controls whether the client offers or even demands the use of the netlogon schannel. client schannel = no does not offer the schannel, client schannel = auto offers the schannel but does not enforce it, and client schannel = yes denies access if the server is not able to speak netlogon schannel.
  • Default: client schannel = auto
  • Example: client schannel = yes
client signing (G)
This controls whether the client offers or requires the server it talks to to use SMB signing. Possible values are auto, mandatory and disabled.
  • When set to auto, SMB signing is offered, but not enforced. When set to mandatory, SMB signing is required and if set to disabled, SMB signing is not offered either.
  • Default: client signing = auto
client use spnego (G)
This variable controls whether Samba clients will try to use Simple and Protected NEGOciation (as specified by rfc2478) with supporting servers (including WindowsXP, Windows2000 and Samba 3.0) to agree upon an authentication mechanism. This enables Kerberos authentication in particular.
  • Default: client use spnego = yes
comment (S)
This is a text field that is seen next to a share when a client does a queries the server, either via the network neighborhood or via net view to list what shares are available.
  • If you want to set the string that is displayed next to the machine name then see the server string parameter.
  • Default: comment = # No comment
  • Example: comment = Fred's Files
config file (G)
This allows you to override the config file to use, instead of the default (usually smb.conf). There is a chicken and egg problem here as this option is set in the config file!
  • For this reason, if the name of the config file has changed when the parameters are loaded then it will reload them from the new config file.
  • This option takes the usual substitutions, which can be very useful.
  • If the config file doesn't exist then it won't be loaded (allowing you to special case the config files of just a few clients).
Retrieved from "https://htyp.org/mw/index.php?title=Smb.conf&oldid=3056"