Setting up Samba as a Standalone Server
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:
[global] workgroup = WORKGROUP netbios name = SA map to guest = Bad User log file = /var/log/samba/%m log level = 1 [guest] # This share allows anonymous (guest) access # without authentication! path = /srv/samba/guest/ read only = no guest ok = yes [demo] # 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
If the shared directories are not already existing, we're creating them:
# mkdir -p /srv/samba/guest/ # mkdir -p /srv/samba/demo/
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 by using the intended way of your OS (init script, systemctl command, etc.) or start the daemon manually:
- 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
Find below some typical advanced share configurations. See the smb.conf man page for detailed information about the parameters used.
[demo] 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!