Linucate
~ Linucate_

209.1 Samba Server Configuration

All Levels

Introduction

Samba provides SMB services to Windows, Linux, and other clients. Access succeeds only when share policy, Samba identity, Unix permissions, and network reachability all agree.

What you should be able to do after this lesson:

  • Configure a standalone Samba server and shares.
  • Manage Samba users and Unix permission interaction.
  • Validate configuration and inspect sessions.
  • Use smbclient and mount CIFS shares on Linux.
  • Recognize Active Directory member and winbind components.

Big Idea: Access Is the Intersection of Four Policies

A successful SMB file operation requires all of these layers to agree:

network reachability + SMB authentication + share authorization
+ Unix identity and filesystem permissions

An authenticated Samba user can still receive access denied from a share rule or Unix ACL. Troubleshoot each layer independently instead of repeatedly resetting the password.

Daemons and Files

Configuration normally lives at /etc/samba/smb.conf. Important processes include:

  • smbd for SMB file and printer service
  • nmbd for legacy NetBIOS name service
  • winbindd for domain identity integration

Modern service names and process layouts vary by distribution and role.

Basic Standalone Configuration

[global]
    workgroup = WORKGROUP
    security = user
    server role = standalone server

[projects]
    path = /srv/samba/projects
    browseable = yes
    read only = no
    valid users = @project

Validate before reload:

testparm

Modern standalone servers normally use user-level security. Historical share-level security may appear in older documentation but does not provide modern per-user accountability. Active Directory member security delegates identity validation to the domain and requires additional Kerberos, DNS, time, and ID-mapping configuration.

Users and Permissions

A local Samba user normally also needs a corresponding Unix account:

sudo smbpasswd -a alice
sudo smbpasswd -e alice

Samba share permissions cannot grant access that Unix mode bits or ACLs deny. Check both layers:

namei -l /srv/samba/projects
getfacl /srv/samba/projects

Options such as force group, create mask, and directory mask influence newly created content but should not conceal a poor ownership model.

Client Tests

smbclient -L //server -U alice
smbclient //server/projects -U alice

Mount from Linux:

mount -t cifs //server/projects /mnt/projects -o credentials=/root/.smb-projects,vers=3.0

Protect credential files and choose an SMB protocol version supported by both sides.

Inspect and Control

smbstatus
smbcontrol all reload-config
nmblookup <name>

Logs commonly live below /var/log/samba/. Separate authentication, name resolution, share policy, and Unix permissions during troubleshooting.

Active Directory Member Awareness

An AD member server relies on DNS, synchronized time, Kerberos, Samba domain configuration, and identity mapping. net, samba-tool, and winbind utilities manage or inspect integration. winbindd exposes domain users and groups to Unix-facing services according to the configured ID mapping. A domain join does not bypass local filesystem permissions.

Printers and Name Mapping

Samba can expose printer shares and map Windows identities to Unix identities. Prefer explicit, auditable mappings and test effective IDs on created files.

Legacy NetBIOS discovery may involve nmbd and nmblookup; direct DNS names and modern SMB do not require every legacy broadcast mechanism. Printer shares still need spooler integration, driver policy, and authorization in addition to a share definition.

Guided Practice: Trace One Share

On an isolated lab server:

  1. Create a Unix group and a directory owned by that group.
  2. Define a writable share limited with valid users = @group.
  3. Add one corresponding Samba user with smbpasswd.
  4. Validate configuration with testparm.
  5. Connect with smbclient and create a test file.

Inspect the complete result:

smbstatus
namei -l /srv/samba/projects/test-file
getfacl /srv/samba/projects/test-file
smbclient //localhost/projects -U alice -c 'ls'

Then mount the share from a Linux client with mount.cifs. Verify the negotiated protocol version and effective file ownership. Store credentials in a protected file rather than placing passwords directly in shell history or /etc/fstab.

Troubleshooting Scenario

A domain user can list a share but cannot create files. smbclient authentication succeeds and smbstatus shows the session; the directory is owned by an unmapped numeric group and lacks a writable ACL.

Verify identity mapping with NSS/winbind tools, correct the Unix group or ACL, and retest the exact file operation. Rejoining the domain is unnecessary when authentication and session establishment already work.

Exam Focus

  • Know smbd, nmbd, and winbindd responsibilities.
  • Use testparm, smbstatus, smbcontrol, smbpasswd, nmblookup, net, and samba-tool appropriately.
  • Configure and test smbclient and mount.cifs from a client.
  • Distinguish standalone user security, historical share security, and AD member integration.

Recap

  • Validate smb.conf with testparm.
  • Samba authorization and Unix permissions must both permit access.
  • smbclient isolates server behavior before kernel CIFS mounting is involved.
  • AD integration depends heavily on correct DNS, time, and identity mapping.
🎯

Test Your Knowledge

Complete the quiz to assess your understanding of this course's concepts.