There are sample configuration files in the examples subdirectory in the source code distribution tarball
package. It is suggested you read them carefully so you can see how the options go together in practice. See
the man page for all the options. It might be worthwhile to start out with the
smb.conf.default configuration file and adapt it to your needs. It contains plenty of comments.
The simplest useful configuration file would contain something like that shown in
Another simple smb.conf File.
Example1.2.Another simple smb.conf File
workgroup = MIDEARTH
guest ok = no
read only = no
This will allow connections by anyone with an account on the server, using either
their login name or
as the service name.
(Note: The workgroup that Samba should appear in must also be set. The default
workgroup name is WORKGROUP.)
Make sure you put the
smb.conf file in the correct place. Note, the correct location of this file
depends on how the binary files were built. You can discover the correct location by executing from
the directory that contains the
root# smbd -b | grep smb.conf
For more information about security settings for the
share, please refer to
Test Your Config File with
It's important to validate the contents of the
smb.conf file using the testparm program.
If testparm runs correctly, it will list the loaded services. If not, it will give an error message.
Make sure it runs correctly and that the services look reasonable before proceeding. Enter the command:
root# testparm /etc/samba/smb.conf
Testparm will parse your configuration file and report any unknown parameters or incorrect syntax.
It also performs a check for common misconfigurations and will issue a warning if one is found.
Always run testparm again whenever the
smb.conf file is changed!
smb.conf file is constantly checked by the Samba daemons
and every instance of
itself that it spawns,
. It is good practice to
keep this file as small as possible. Many administrators prefer to document Samba configuration settings
and thus the need to keep this file small goes against good documentation wisdom. One solution that may
be adopted is to do all documentation and configuration in a file that has another name, such as
utility can be used to generate a
smb.conf file from this master configuration and documtenation file as shown here:
root# testparm -s smb.conf.master > smb.conf
This administrative method makes it possible to maintain detailed configuration change records while at
the same time keeping the working
smb.conf file size to the minimum necessary.