Samba: SMB File Services & Active Directory on Linux

Samba

Samba is the open source implementation of the SMB/CIFS file-sharing protocol and related Windows networking services for Linux and Unix. It lets Linux servers share files and printers with Windows, macOS, and Linux clients, join Active Directory domains so users sign in with their domain accounts, and even act as an Active Directory domain controller itself. It powers NAS appliances, departmental file servers, and mixed Windows–Linux environments around the world.

Samba is powerful and old, and its configuration reflects decades of protocol history. Running it well means choosing a clear server role, disabling obsolete protocol versions, enforcing signing and encryption where needed, getting identity mapping between Windows SIDs and Unix IDs right, keeping time and DNS healthy for Kerberos, and patching promptly — Samba has had serious vulnerabilities, as any widely deployed network service does.

TL;DR

Samba speaks SMB2/SMB3; disable SMB1, require signing, and use SMB3 encryption for sensitive shares.
Pick a role: standalone server, AD domain member (most common in companies), or Samba AD DC.
Domain members use winbind (or SSSD) with Kerberos; correct DNS and time synchronization are prerequisites.
Configure ID mapping (rid, ad, or autorid backends) with non-overlapping ranges.
Manage permissions with Windows ACLs stored via vfs_acl_xattr, combined with sensible filesystem ownership.
Validate with testparm, test with smbclient and wbinfo, read logs at raised levels when troubleshooting, and patch regularly.

Quick Example

An smb.conf for a file server joined to an Active Directory domain:

Joining the domain and checking that identities resolve:

Core Concepts

Protocol Versions and Security

Signing protects messages from tampering and relay attacks; encryption protects confidentiality on the network. Require signing broadly and encryption for sensitive shares, keeping in mind that very old clients may not support them.

Server Roles

As a domain member, Samba relies on the domain's Kerberos and DNS: the server must resolve domain controllers through DNS SRV records, and its clock must be within the Kerberos tolerance (five minutes by default). See Active Directory and Group Policy and Time Synchronization and Certificate Dependencies.

Identity Mapping

Windows identifies users and groups by SIDs; Linux uses numeric UIDs and GIDs. winbind maps between them using an idmap backend:

Ranges must not overlap, and all servers sharing files (for example via NFS too) must map identically. Changing backends later changes file ownership, so decide early. SSSD can replace winbind for some member-server setups.

Shares and Permissions

Access is checked at two levels: share settings (valid users, read only, host restrictions) and filesystem permissions. With vfs objects = acl_xattr, Samba stores full Windows ACLs in extended attributes so administrators can manage permissions from Windows Explorer, while underlying POSIX permissions still apply. Keep share-level settings simple and manage access with groups. Avoid guest access except for genuinely public, read-only shares.

macOS and Special Clients

The vfs_fruit module improves macOS compatibility — extended attributes, resource forks, and Time Machine targets. Older printers, scanners, and appliances may require older protocol features; isolate them rather than weakening security for everyone.

Troubleshooting

Raise log levels temporarily (log level = 3 or per component), use smbstatus for active sessions and locks, and validate every change with testparm. See Windows Server Administration for the Windows side.

Best Practices

Disable Legacy Protocols and Require Signing

Set a minimum of SMB2, require signing, and encrypt sensitive shares.

Decide ID Mapping Up Front

Choose idmap backends and ranges before data is written, and keep them identical across servers.

Keep DNS and Time Healthy

Point servers at domain DNS and synchronize time with the domain; most join and authentication failures start here.

Patch Promptly

Track Samba security releases and update regularly; exposed file servers are high-value targets.

Common Mistakes

Leaving SMB1 Enabled

Overlapping ID Ranges

Clock Drift on a Domain Member

FAQ

What is Samba used for?

Providing SMB file and print sharing from Linux and Unix systems, integrating them with Active Directory domains, and optionally acting as an Active Directory domain controller.

Can Samba replace a Windows file server?

For many file-sharing needs, yes — especially as an Active Directory domain member with Windows ACL support. Some Windows-specific features and management workflows may differ.

Can Samba be an Active Directory domain controller?

Yes. Samba can act as an AD-compatible domain controller providing LDAP, Kerberos, DNS, and Group Policy storage, though some advanced Windows Server AD features are not supported.

What is winbind?

A Samba service that connects Linux systems to Windows domains, resolving domain users and groups, mapping SIDs to Unix IDs, and handling authentication.

Why does joining Samba to Active Directory fail?

Most often because of DNS (the server cannot find domain controllers), time differences beyond Kerberos tolerance, incorrect realm or workgroup settings, or insufficient join permissions.