Setting up Samba as a Standalone Server

From SambaWiki
Revision as of 22:00, 3 January 2016 by Mmuehlfeld (talk | contribs) (Initial documentation about how to setup a Samba standalone server)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


In some environments like home networks or to temporary share folders on a host that is not part of a domain, it is not wanted or necessary to setup an Active Directory or an NT4 domain. In the following we will setup a Samba standalone installation with one share, that is accessible anonymous (guest access), and a second one, that requires authentication against a local user database on the Samba host. To setup share permissions, it is useful to read the documentation about shares with POSIX ACLs, as well as shares with Windows ACLs. Of course, a standalone server can also act as a print server. See print server support for information how to set up.

See the server information used in documentation page for used paths, hostnames, etc.

A basic smb.conf

The following configuration is a minimal setup for a standalone Samba server installation:

        workgroup = WORKGROUP
        netbios name = SA

        map to guest = Bad User

        log file = /var/log/samba/%m
        log level = 1

        # This share allows anonymous (guest) access
        # without authentication!
        path = /srv/samba/guest/
        read only = no
        guest ok = yes

        # This share requires authentication to access
        path = /srv/samba/demo/
        read only = no
        guest ok = no

The log parameters are not required for a minimal setup, but are helpful to locate the log files and increasing the log level, in case of problems. The above example includes a share that is accessible without authentication. Guest shares can be a security problem! Imagine one on a laptop, that is connected to different networks (home, school, work, etc.). So please use it with care! If you're not planning to provide anonymous (guest) access to shares, the "map to guest" parameter can either be removed or set to its default ("Never").

Create a local user

If you want to provide non-anonymous shares on your standalone host, it is required to create the users local on the Samba host and in the Samba database. Per default, Samba uses the tdbsam backend, that stores the passdb.tdb database file inside the private directory (/usr/local/samba/private/), if you haven't defined a different path via the "passdb backend" parameter.

  • Step 1: Create a local user account
# useradd -m -s /sbin/nologin demoUser
This command adds a local account named "user" without creating a home directory. Omit "-m", if you require a home. It's not necessary to assign a valid shell to that account, if no local logins (e. g. via SSH) are required.

  • Step 2: Enable the local account
# passwd demoUser
Enter new UNIX password: Passw0rd
Retype new UNIX password: Passw0rd
passwd: password updated successfully
This password is valid only for the local account and not for Samba access. That one is assigned in step 3. A local password is required - otherwise the account stays in a locked state and a login via Samba will be denied denied. Having a password assigned to a Samba-only account won't be a problem, because we didn't define a shell in step 1. In this case, local logins are denied.

  • Step 3: Add the account to the Samba database
# smbpasswd -a demoUser
New SMB password: Passw0rd
Retype new SMB password: Passw0rd
Added user demoUser.
To enable an Samba account, it is necessary to set a password. This one is required for authentication against Samba.

  • Step 4: Enable the account in the Samba database
# smbpasswd -e demoUser
Enabled user demoUser.

Create a local group (optional)

  • Step 1: Create a group "demoGroup"
# groupadd demoGroup

  • Step 2: Add account to group
# usermod -G demoGroup demoUser

The shared directories

If the shared directories are not already existing, we're creating them:

# mkdir -p /srv/samba/guest/
# mkdir -p /srv/samba/demo/

Setting ACLs on shared directories

We're using POSIX ACLs in the following examples. See shares with POSIX ACLs for further information.

# chgrp -R demoGroup /srv/samba/guest/
# chgrp -R demoGroup /srv/samba/demo/

# chmod 2775 /srv/samba/guest/
# chmod 2770 /srv/samba/demo/

Those ACLs allow write access to group "demoGroup". Accounts, who are not members of the "demoGroup" group, will have only read access on the guest share and no access on the demo share. Additionally we set the SGID bit - represented by the first bit ("2") in "2770" and "2775". This permission defines that the group is inherited on all new files and directories from the parent folder, instead of setting it to the users primary group.

Start Samba

Start Samba by using the intended way of your OS (init script, systemctl command, etc.) or start the daemon manually:

# smbd


  • Accessing the "demo" share as user "demoUser":
# smbclient -U demoUser //SA/demo
Enter demoUser's password: Passw0rd
Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba x.y.z]
smb: \> ls
  .                                   D        0  Sun Jan  3 21:00:00 2016
  ..                                  D        0  Sun Jan  3 19:00:00 2016
  demo.txt                            A        0  Sun Jan  3 21:00:00 2016

		9943040 blocks of size 1024. 7987416 blocks available
smb: \> quit

  • Accessing the "demo" share as guest will be denied as expected:
# smbclient -U guest //SA/demo
Enter guest's password: 
Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba x.y.z]
tree connect failed: NT_STATUS_ACCESS_DENIED

Advanced share settings

Find below some typical advanced share configurations. See the smb.conf man page for detailed information about the parameters used.

Force parameters

        path = /srv/samba/demo/
        read only = no
        guest ok = no
        force create mode = 0660
        force directory mode = 2770
        force user = demoUser
        force group = demoGroup

The two "force ... mode" parameters, force exactly those modes on new files and directories. The force user/group parameters map all connections to the given user/group. Please notice, that this can raise serious security issues - especially if the share is accessible anonymous!

User/group based share access

See user/group based share access.

Host based share access

See host based share access.