Network Sharing · Lesson 5

Samba

Learn how to configure, validate, access, and secure a basic Samba file share.

Samba implements the Server Message Block protocol on Unix-like systems, allowing Linux, Windows, macOS, and other clients to share files and printers. Modern deployments use current SMB dialects; the older term CIFS is still visible in Linux client tooling but should not be read as a reason to enable obsolete SMB1.

Planning the Share

Before installing or changing Samba, define the authorized clients, identities, read/write needs, network zone, data owner, backup policy, and required SMB dialect. Use a dedicated directory rather than exposing a home or system tree unintentionally.

Access is controlled by both Samba policy and underlying filesystem permissions. Allowing writes in smb.conf cannot grant an account filesystem access it does not have.

What must allow a user to write through a Samba share?

Defining a Basic Share

The main configuration is commonly /etc/samba/smb.conf. A restricted example is:

[team]
    path = /srv/samba/team
    browseable = yes
    read
    valid users = @teamshare

Create the directory and apply reviewed ownership and permissions for the Unix group:

$ sudo install -d -o root -g teamshare -m 2770 /srv/samba/team

The set-group-ID bit helps new entries inherit the directory group, but collaborative access may also require an ACL or a carefully chosen create mask. Test the actual file and directory results rather than assuming inheritance is sufficient.

What does valid users = @teamshare express?

Configuring Identity

In a standalone Samba configuration, an account generally needs a corresponding Unix identity and an enabled Samba credential:

$ sudo smbpasswd -a alice

Directory-domain deployments use a different identity design. Do not place passwords in shell history or configuration readable by unrelated users, and do not assume a Samba password is automatically identical to the Unix account password.

What does smbpasswd -a alice commonly do on a standalone server?

Validating and Applying Configuration

Check the parsed configuration before reloading services:

$ testparm -s

Review unexpected defaults and errors, then reload the distribution's Samba service through its service manager. Service names vary, commonly including smbd.service or smb.service. A reload is less disruptive than a restart when supported, but still verify status, listening sockets, firewall scope, and logs.

Test from a client with an explicit user:

$ smbclient //server.example.net/team -U alice

Why run testparm -s before applying a Samba change?

Mounting from Linux

Linux clients commonly use the cifs filesystem driver and mount helpers. Avoid passwords in the command line because arguments can leak through history or process inspection. Use a root-readable credentials file or an approved credential mechanism:

$ sudo mount -t cifs //server.example.net/team /mnt/team \
    -o credentials=/root/.smb-team,vers=3.1.1

Protect the credential file, confirm the dialect supported by both sides, and define UID, GID, permission, and encryption requirements deliberately. After mounting, verify with findmnt, perform authorized read/write tests, and unmount after coordinating active users.

Why avoid password=... directly in a mount command?

Lesson complete

You finished Samba

You can now configure a Samba share while accounting for both protocol and filesystem security.

Define clients, identities, network scope, and data policy first.
Restrict the share and align underlying permissions.
Manage Samba credentials through the correct identity model.
Validate with testparm and perform an end-to-end client test.
Protect client credentials and verify mounted access.

Keep your learning progress

Create a free account to save this lesson and continue learning on any device.

Create a free account

Back to Network Sharing