Setting Up a Secure Samba Server on Linux: Hardening and Configuration Guide

Bridging Compatibility and Security with Samba

If you run a mixed environment where Linux servers need to share files with Windows machines, Samba is the go-to solution. It implements the Server Message Block (SMB) protocol natively on Unix/Linux, so Windows clients see your Linux shares just like they would any other network drive.

The catch is that SMB has a troubled security history. The WannaCry and NotPetya ransomware attacks of 2017 exploited EternalBlue, a vulnerability in the long-deprecated SMBv1 protocol, and the damage ran into billions of dollars worldwide. That era made one thing painfully clear: default Samba configurations are not production-ready. You need to actively harden them.

This guide walks through a defense-in-depth approach — modern protocol enforcement, transport encryption, strict directory permissions, network access controls, and full audit logging. By the end, your Samba server will be a secure, reliable file-sharing platform rather than a liability on your network.

How SMB Negotiates a Secure Connection

Before diving into configuration, it helps to understand what actually happens when a client connects to your Samba server. Modern SMB (version 3.x) supports cryptographic integrity validation and full message encryption. The diagram below shows how a properly hardened server negotiates an encrypted session, compared to the unencrypted legacy flow that made SMBv1 so dangerous.

1. Installing Samba

Start by installing Samba. The package names differ slightly between distributions, but the process is straightforward.

For Debian and Ubuntu-based systems:

sudo apt update
sudo apt install samba samba-common-bin -y

For RHEL, Rocky Linux, or AlmaLinux:

sudo dnf install samba samba-common -y

Once installed, check that the service is running:

systemctl status smbd

[!WARNING] Some distributions start Samba immediately after installation with no access controls in place. Stop the service while you configure it, or make sure your firewall is blocking port 445 from external access:

sudo systemctl stop smbd

2. Creating a Secure Shared Directory

Plenty of quick-start tutorials tell you to run chmod 777 on your share directory. Don’t do it. That permission grants every local user — and any compromised service account — full read, write, and execute access. Instead, create a dedicated group and enforce group-based ownership.

Create a dedicated group for Samba users:

sudo groupadd smbshares

Create the shared directory outside user home folders:

sudo mkdir -p /srv/samba/secure_share

Set ownership and permissions with the SetGID bit:

sudo chown -R root:smbshares /srv/samba/secure_share
sudo chmod -R 2770 /srv/samba/secure_share

The 2770 permission does three things: root and group members get full access, everyone else gets nothing, and the SetGID bit (2) ensures that new files created inside the directory automatically inherit the smbshares group — so you don’t end up with permission mismatches as users add files.

Create a Samba-only system user with no shell access:

sudo useradd -M -s /usr/sbin/nologin -g smbshares smbuser

Register the user in Samba’s password database:

sudo smbpasswd -a smbuser

Use a strong, complex password. NTLMv2 hashes can be captured on the wire and subjected to offline cracking attacks, so password strength matters even when encryption is enforced.

3. Hardening the Samba Configuration

Everything security-critical lives in /etc/samba/smb.conf. The default configuration enables legacy protocols and leaves the server broadly accessible. Before editing, back up the original:

sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak

Open the file for editing:

sudo nano /etc/samba/smb.conf

Replace the contents with this hardened configuration:

[global]
   workgroup = WORKGROUP
   server string = Hardened File Server
   log file = /var/log/samba/log.%m
   max log size = 1000
   logging = file

   # ================= Security Hardening =================
   
   # Enforce modern SMB protocols (Disable SMBv1)
   server min protocol = SMB2_10
   client min protocol = SMB2_10
   
   # Enforce SMB3 transport encryption (Protects against eavesdropping)
   smb encrypt = required
   
   # Disable guest/anonymous access entirely
   guest ok = no
   map to guest = Never
   restrict anonymous = 2
   
   # Network Isolation: Bind to internal interfaces only
   bind interfaces only = yes
   interfaces = lo eth0 192.168.1.0/24
   
   # IP-based Access Control List (ACL)
   hosts allow = 127. 192.168.1.
   hosts deny = 0.0.0.0/0

   # Disable printer sharing unless explicitly needed (Reduces attack surface)
   load printers = no
   printing = bsd
   printcap name = /dev/null
   disable spoolss = yes

# ================= Shared Directories =================

[SecureShare]
   comment = Secure Collaborative Share
   path = /srv/samba/secure_share
   valid users = @smbshares
   force group = smbshares
   writable = yes
   browseable = yes
   guest ok = no
   
   # Secure File Creation Masks (Files: 660, Directories: 770)
   create mask = 0660
   directory mask = 0770
   force create mode = 0660
   force directory mode = 0770

Here’s what the key directives actually do:

• server min protocol = SMB2_10 — Refuses connections from any client still using SMBv1. If all your clients run Windows 10/11, modern macOS, or a recent Linux distro, you can push this even higher to SMB3 for maximum security.
• smb encrypt = required — The server will refuse to communicate with clients that don’t support transport encryption. This protects your file traffic from being read or tampered with in transit.
• restrict anonymous = 2 — Prevents unauthenticated users from browsing or listing shares at all.
• hosts allow and hosts deny — A secondary layer of defense built directly into Samba. Only clients from the loopback and your designated subnet can connect, regardless of what your main firewall allows.
• create mask = 0660 — Files created through the share can’t be read or written by arbitrary system users, keeping the principle of least privilege intact.

4. Auditing with VFS Modules

In a corporate environment, you need more than just access controls — you need a record of who did what. Samba’s virtual file system (VFS) framework includes a full_audit module that logs file operations directly to syslog.

Add the following to your share definition:

[SecureShare]
   ...
   # Enable VFS auditing module
   vfs objects = full_audit
   
   # Logging Prefix: Username|IP Address|Machine Name|Share Name
   full_audit:prefix = %u|%I|%m|%S
   
   # Operations to log (Focus on write, delete, and connection activities)
   full_audit:success = mkdir rename unlink rmdir open pwrite write
   full_audit:failure = connect open
   
   # Log configuration
   full_audit:facility = local7
   full_audit:priority = NOTICE

Route audit logs to a dedicated file by creating /etc/rsyslog.d/samba-audit.conf:

local7.notice /var/log/samba/audit.log
& stop

Then restart both services:

sudo systemctl restart rsyslog
sudo systemctl restart smbd

From this point, every file creation, rename, deletion, and failed connection attempt will be timestamped and logged with the username and source IP — exactly the kind of data you need for incident response or compliance audits.

5. Testing and Connecting to the Share

Before restarting Samba, always run testparm to catch configuration syntax errors:

testparm

If the output looks clean, restart the daemon:

sudo systemctl restart smbd

From Windows: Open File Explorer and type the UNC path in the address bar:

\\<server_ip>\SecureShare

Enter the smbuser credentials when prompted. Because smb encrypt = required is active, Windows will automatically negotiate an encrypted session using AES-CCM or AES-GCM.

From Linux using smbclient:

smbclient //<server_ip>/SecureShare -U smbuser -e

The -e flag explicitly requests encryption. If the client can’t support it, the server drops the connection — by design.

Permanent mount via /etc/fstab:

//<server_ip>/SecureShare /mnt/share cifs credentials=/etc/samba/auth.cred,iocharset=utf8,seal 0 0

Create /etc/samba/auth.cred with the username and password, then lock down the file:

sudo chmod 600 /etc/samba/auth.cred

6. Ongoing Monitoring

Check active connections and encryption status:

sudo smbstatus

Look for Encryption: AES-128-GCM or AES-256-GCM in the output. If you see Unencrypted against any session, investigate immediately.

Hunt for authentication brute-force attempts:

sudo grep -i "auth" /var/log/samba/log.smbd

Multiple failed logins from the same IP are a strong indicator of credential stuffing. Consider integrating Fail2ban to automatically ban offending IPs after a configurable threshold of failures.

Hardening Checklist

Run through this before putting the server into production:

A Samba server configured this way gives you dependable cross-platform file sharing without creating an easy target for attackers moving laterally through your network.