Right, let’s get our hands dirty with smb.conf. This file is the beating heart of your Samba server, and it’s where you’ll either achieve glorious cross-platform file-sharing nirvana or descend into a frustrating hellscape of authentication errors. I’m here to make sure it’s the former.

Think of smb.conf not as a monolithic config, but as a set of Russian nesting dolls. The outermost doll is [global], which sets the rules for the entire server. Inside that, you define your individual share dolls, like [Documents] or [PrinterShare]. A setting in a share can override the global setting, but if you don’t set it there, it inherits from [global]. This structure is your best friend and will keep you from repeating yourself.

The [global] Section: Your Server’s Personality

This is where you tell the world who you are. Get this wrong, and other machines might not even see your server in their network neighborhood. The most critical settings here are your workgroup and netbios name.

[global]
    # Make this match your Windows workgroup. The default is 'WORKGROUP'.
    # Get this wrong and you'll be the lonely kid at the network party.
    workgroup = MYDOMAIN

    # This is the legacy NetBIOS name for your server. Keep it short, simple, and without spaces or weird chars.
    # This is what older Windows versions will see.
    netbios name = MYCOOLSERVER

    # The modern way to identify your server. FQDN is best practice.
    server string = %h file server (%v)

    # Security is next. This is a big one. 'user' means Samba handles the authentication itself.
    # You'll need a local Samba user (set with `smbpasswd -a`) for this to work.
    security = user

    # Tell Samba to use the modern, secure protocol. Never set this to anything less than SMB2.
    # Setting it to SMB3 lets it auto-negotiate the best version.
    server min protocol = SMB2_10
    server max protocol = SMB3

    # For God's sake, please don't let your server talk ancient, insecure LAN Manager protocols.
    lanman auth = no
    ntlm auth = no

The %h in server string is a magic variable that expands to the hostname of your machine. Samba is full of these, and they’re fantastic for making dynamic configurations.

Defining Your First Share

Now for the fun part: making a directory actually accessible. Let’s create a share for our important documents. Notice how the share name in brackets doesn’t have to match the filesystem path.

[ImportantDocs]
    # This is the absolute path on the server's filesystem to the folder you're sharing.
    path = /srv/samba/important_docs

    # This is the text that appears when users browse the share. Be witty here, it's your only chance.
    comment = Where we keep the plans for world domination (and budget reports)

    # Let users read and write files. 'yes' means the share is visible when browsing.
    read only = no
    browseable = yes

    # A crucial one: which users are allowed access? You can list them or use @group.
    valid users = bob, alice, @finance

Here’s the first pitfall: file permissions. Samba is bound by the Linux filesystem permissions and its own settings. If the Linux permissions on /srv/samba/important_docs don’t allow the user ‘bob’ to create a file, it doesn’t matter what you set read only = no to. He’ll get a permission denied error. Always, always check the underlying Unix perms. I use chmod 2770 and chgrp finance on the directory so that the finance group has full access, and new files inherit that group.

Authentication: The Usual Suspects

The security = user setting means Samba is the bouncer at the door. It checks its own password database, which is separate from the system’s Linux logins. This is a common point of confusion. Just because you have a user ‘bob’ on the Linux box doesn’t mean Samba knows about him. You have to introduce them:

# This adds 'bob' to the Samba user database. It will prompt you to set a password.
# This password is what Windows/Mac clients will use to authenticate.
sudo smbpasswd -a bob

If you mess up the password, the client will just keep throwing “access denied” errors at you, offering exactly zero useful debugging info. It’s infuriating. The smbclient tool is your best friend for testing this locally without involving a Windows VM:

# Try to list the shares on your own server as 'bob'. It will prompt for the password you set with smbpasswd.
smbclient -L localhost -U bob

# If that works, try to actually connect to the share.
smbclient //localhost/ImportantDocs -U bob

If this works but your Windows client still can’t connect, you’ve just eliminated half the problem—your Samba config is good, and the issue is likely network-related (firewalls, name resolution, etc.). This is the kind of trench-work debugging that saves you hours.

The Guest Share Trap

Sometimes you want a share with no authentication. This is a minefield. You must explicitly define the Linux user that guest access maps to, usually the unprivileged nobody user.

[PublicDropbox]
    path = /srv/samba/public
    comment = Dump files here, but they're public. No complaining.
    read only = no
    browseable = yes
    guest ok = yes
    force user = nobody

The force user = nobody is the key. It makes every file operation on that share happen as the nobody user, regardless of who connected. Without it, you’ll get permission errors because the guest user doesn’t have a real identity on the Linux system. This is a classic “it-seems-simple-but-isn’t” scenario that Samba is famous for. Use guest shares sparingly, and never for anything remotely important.