How to Set Up Samba on Linux: Share Files With Windows and Linux Clients

If you’ve ever tried to share files between a Linux box and a Windows machine and ended up rage-quitting into Stack Overflow tabs, this is for you. Learning how to set up Samba on Linux is one of those skills that pays off forever — it’s the bridge between your penguin-powered file server and every other device on your network. I’ll walk you through the whole thing the way I wish someone had walked me through it back in my Ubuntu 8.04 days.

I still remember sitting on my dorm floor trying to copy game saves from my Linux laptop to my Windows gaming rig over the LAN. I had NFS running. I was so proud of NFS. Windows did not care about NFS. After three hours of /etc/exports tweaks, my roommate (who, bless him, did not use Linux) said something like “why don’t you just use the Microsoft thing?” That Microsoft thing was SMB. The Linux implementation is Samba. We’re going to set it up properly this time.

What Is Samba (and Why Not Just Use NFS)

Samba is the open source implementation of the SMB/CIFS protocol — the same protocol Windows has used natively for decades. When you “Map Network Drive” in Windows, you’re talking SMB. Samba lets your Linux server speak that same language, so Windows, macOS, and other Linux machines can all mount the same share without arguing about who speaks what.

It does more than file sharing too. Samba can act as a print server, a domain controller for Active Directory environments, and a guest share for that one media folder you want available without passwords. It’s enterprise-grade software dressed up in homelab-friendly clothing.

Get a VPS from as low as $11/year! WOW!

Samba vs NFS: When to Use Which

Quick rule of thumb from my own homelab: NFS is faster for pure Linux-to-Linux setups, and it integrates beautifully with Linux permissions because it speaks UID/GID natively. If every client in your network runs Linux, look at setting up an NFS server on Linux instead — you’ll get less overhead and tighter integration.

But the second a Windows or macOS device joins the party, Samba is the answer. Even if you only have one Windows laptop, running Samba on the server side is simpler than juggling two file sharing stacks. If you’re building a full network-attached storage box, take a look at our roundup of the best Linux NAS software — most of those distributions are running Samba under the hood anyway.

Install Samba on Linux

Installation is genuinely the easy part. Pick your distro and run two commands. Then we’ll move on to the part where things get interesting.

Ubuntu and Debian

sudo apt update
sudo apt install samba

The Ubuntu package pulls in smbd, nmbd, and the client tools you’ll want for testing. Verify with whereis samba — you should see paths to both the binary and the man pages. Start and enable the services:

sudo systemctl enable --now smbd nmbd

RHEL, Rocky Linux, and Fedora

sudo dnf install samba samba-common-tools

On Red Hat-family distros the service names are smb and nmb (no trailing d). Start them with:

sudo systemctl enable --now smb nmb

If systemctl enable --now is new to you, I wrote a whole piece on how systemd service management works that’s worth a skim. Knowing what enable --now actually does is one of those things that makes every other tutorial easier to follow.

Configure smb.conf

This is where most tutorials lose people. The config file at /etc/samba/smb.conf looks intimidating because the defaults ship with a wall of comments. Ignore most of it. There are maybe ten lines that actually matter for a basic share.

Global Settings That Actually Matter

Open /etc/samba/smb.conf in your editor of choice (I’m a vim person, you do you), and make sure your [global] section has these lines:

[global]
   workgroup = WORKGROUP
   security = user
   passdb backend = tdbsam
   min protocol = SMB2
   server string = Samba Server %v
   log file = /var/log/samba/log.%m
   max log size = 1000

That min protocol = SMB2 line is non-negotiable. SMB1 has been deprecated since Samba 4.11, and it’s the exact protocol version the EternalBlue exploit targeted to spread WannaCry across half the planet in 2017.

“SMBv1 is a relic that’s more liability than asset — businesses clinging to it risk data breaches, operational halts, and regulatory headaches.” — Black Belt Secure

If you’re curious about hardening beyond this, the Samba’s official server security documentation is the canonical reference. Bookmark it.

Defining Your First Share

Scroll to the bottom of smb.conf and add a share block. Here’s the one I use for a typical group-accessible share:

[teamshare]
   path = /srv/samba/share
   browsable = yes
   read only = no
   valid users = @sambashare
   create mask = 0660
   directory mask = 2770

The @sambashare in valid users means “anyone in the sambashare Linux group can access this.” This pattern is so much cleaner than listing individual users. Add a new teammate? Just add them to the group. Done.

Before you restart anything, run testparm /etc/samba/smb.conf. It validates your syntax, dumps the effective config, and flags deprecated options. I run testparm reflexively now, the same way I run nginx -t before reloading nginx. It has saved me from at least three “why is the service refusing to start” panics.

Create a Samba User and Set Directory Permissions

Here’s the part that trips up almost every newcomer: Samba has its own password database, completely separate from /etc/shadow. Adding a user to Linux does not add them to Samba. You need both.

Adding a Samba User with smbpasswd

First, create the system user (or skip this if they already exist). I usually create a shell-less account for pure file sharing roles:

sudo useradd -M -s /usr/sbin/nologin alexa
sudo smbpasswd -a alexa

The smbpasswd -a command prompts for the Samba password — make it different from the Linux password. The Ubuntu docs put it bluntly:

“Since Samba doesn’t use the system account password, we need to set up a Samba password for our user account using smbpasswd.” — Ubuntu Official Documentation

If you’re new to Linux user management, my guide on adding users in Linux covers the system-side basics that make this step click.

Ownership and Mode on the Share Directory

Now create the share directory, set group ownership, and turn on the setgid bit:

sudo groupadd sambashare
sudo usermod -aG sambashare alexa
sudo mkdir -p /srv/samba/share
sudo chown -R :sambashare /srv/samba/share
sudo chmod 2770 /srv/samba/share

That leading 2 in 2770 is the setgid bit. It means any new file created inside /srv/samba/share automatically inherits the sambashare group instead of the creator’s primary group. Without it, you get permission drift where Alice’s files are unreadable to Bob even though they’re both in the group. Ask me how many hours I lost to this in my first sysadmin job before I learned about setgid.

Open Your Firewall

Samba needs four ports open: 137 and 138 UDP for NetBIOS name resolution and datagram services, and 139 and 445 TCP for SMB sessions. If your firewall blocks any of these, the share will be invisible or unreachable.

• Ubuntu/Debian (ufw): sudo ufw allow samba — one command, all four ports.
• RHEL/Rocky/Fedora (firewalld): sudo firewall-cmd --add-service=samba --permanent && sudo firewall-cmd --reload
• Minimal installs (nftables): add rules for dport { 137, 138, 139, 445 } on the appropriate chain.

For deeper firewall work on Red Hat systems, my guide on how to manage firewalld zones and rules covers zone-based configuration so you can scope Samba access to your trusted LAN only. Running a custom minimal distro? My nftables for modern firewall management walkthrough has you covered.

Handle SELinux on RHEL, Rocky, and AlmaLinux

This is the section I wish every Samba tutorial included, because SELinux quietly breaks more first-time Samba setups than every misconfigured smb.conf in history. The config is right. The user exists. The firewall is open. Connection refused. Sound familiar?

SELinux ships with a label-based access model. By default, it does not let smbd read arbitrary directories — it only allows access to directories tagged with the samba_share_t context. Your shiny new /srv/samba/share directory has the wrong label out of the box.

Fix the context temporarily (good for testing):

sudo chcon -t samba_share_t /srv/samba/share

Make it persistent across relabels (this is what you actually want):

sudo semanage fcontext -a -t samba_share_t '/srv/samba/share(/.*)?'
sudo restorecon -Rv /srv/samba/share

Ubuntu and Debian use AppArmor instead of SELinux. The Samba AppArmor profile is usually permissive enough that you don’t have to do anything, but if you’re tightening it, my AppArmor configuration on Ubuntu guide is the place to start.

Test the Share and Connect From Clients

Time for the satisfying part — actually connecting to your share. We’ll validate the config, restart services, and then connect from Windows, Linux, and macOS.

Validate Config with testparm

sudo testparm
sudo systemctl restart smbd nmbd

If testparm throws warnings about deprecated options, fix them before restarting. Stale options can prevent the service from starting cleanly.

Connect From Windows

Open File Explorer and type \\server-ip\teamshare into the address bar. Windows will prompt for credentials — that’s your Samba password, not your Linux password. To make it stick, right-click “Network” in the sidebar and choose “Map Network Drive.”

Connect From Linux

From the command line, the smbclient tool is your friend for one-off testing:

smbclient //server-ip/teamshare -U alexa

For a proper mount that behaves like a local directory:

sudo mkdir -p /mnt/teamshare
sudo mount -t cifs //server-ip/teamshare /mnt/teamshare \
  -o username=alexa,uid=1000,gid=1000

For RHEL clients specifically, Red Hat’s official guide to mounting SMB shares covers the cifs-utils package details.

To make the mount persistent across reboots, add it to /etc/fstab with a credentials file:

//server-ip/teamshare /mnt/teamshare cifs credentials=/etc/samba/.creds,uid=1000,gid=1000 0 0

Then create /etc/samba/.creds with username=alexa and password=yourpass, and lock it down: sudo chmod 600 /etc/samba/.creds. Storing passwords directly in fstab is bad practice — the file is world-readable. My deeper guide on how to configure /etc/fstab for persistent mounts covers credential files and mount option tuning in detail.

macOS users: Finder > Go > Connect to Server, then enter smb://server-ip/teamshare. Same credentials.

Common Samba Errors and How to Fix Them

Every Samba setup hits at least one of these. Here’s the cheat sheet I keep in my notes app:

• NT_STATUS_ACCESS_DENIED: Filesystem permissions on the share directory are too tight, or the user isn’t in the Samba password database. Re-run smbpasswd -a username and check group membership.
• NT_STATUS_BAD_NETWORK_NAME: Typo in the share name, or smbd isn’t running. Verify with systemctl status smbd.
• Share invisible from Windows: Firewall blocking port 445, or nmbd isn’t running. NetBIOS browsing depends on nmbd.
• Password rejected: Remember, the Samba password is separate from the Linux password. Run smbpasswd -a again to reset it.
• SELinux audit denial: Run ausearch -m avc -c smbd to find the exact denial, then fix the context.
• Mystery defaults: Run testparm -s to dump the effective config — sometimes a default you didn’t set is biting you.

Samba Security Best Practices

Samba is one of those services that gets put on a network and forgotten. That’s how you end up on someone’s CVE writeup three years later. A handful of habits prevent 95% of the trouble.

1. Pin min protocol = SMB2 in [global]. SMB1 is the EternalBlue attack vector. Disable it. Always.
2. Use valid users on every share. Never ship a world-accessible share unless that’s the explicit goal.
3. Restrict by IP range. Add hosts allow = 192.168.1. 127. and hosts deny = ALL if the share should only be reachable from your LAN.
4. Encrypt the underlying storage. If the data is sensitive, layer LUKS disk encryption on Linux underneath the share so even physical theft doesn’t leak the files.
5. Rotate Samba passwords. Same discipline as any service account. smbpasswd is your friend.

For exhaustive reference material, the Arch Wiki Samba reference is, as usual, the gold standard. Even if you don’t run Arch, it’s the most comprehensive community documentation for Samba on Linux.

Wrapping Up

Once you’ve done a clean Samba install and watched a Windows laptop mount a share from your Linux server, something clicks. The penguin and the windowed OS are not enemies — they just needed a translator. Samba is that translator, and now you know how to run it.

If you’re building out a broader homelab, a few logical next steps: harden your firewall with my deep-dive on how to manage firewalld zones and rules, lock down sensitive shares with LUKS disk encryption on Linux, or, if Samba is too heavy for an all-Linux network, set up an NFS server on Linux instead.

Got a Samba war story or a config tip I missed? I read every comment. Drop your setup in the discussion below, and if this guide saved you some hair-pulling, share it with the next homelabber who’s about to learn the hard way that SMB1 is not a feature.

Alexa Velinxs

I'm Alexa Velinxs, a cryptocurrency trading expert passionate about demystifying digital assets for both beginners and seasoned investors. Through my writing, I share actionable strategies, market insights, and practical tips to help you navigate the crypto landscape with confidence. Let's explore the future of finance together.

See Full Bio