If you've got a Linux box and a Windows machine on the same network, you shouldn't need a USB stick to move files between them. That's the whole reason Samba exists: it makes a Linux server show up as an ordinary network drive to Windows — and to other Linux machines too — so anyone on the network can open, save, and edit files without ever touching a terminal on the other end.
I set this up on a Debian server as part of a networking course, and tested it two different ways: once completely open, no login required, and once locked down behind real user accounts and group permissions. This article walks through both, roughly in the order I actually did them, along with the errors that came up and what actually fixed them.
By the end you'll have a working guest share, a working authenticated share, and you'll know how to reach either one from a second Linux machine acting as the client.
What You'll Need
2 Debian or Ubuntu machines (a VM works fine) with root access
A Windows machine on the same network, to test from the client side
Enough terminal comfort to edit a file with nano or vi and run a few commands as root
What Samba Actually Does
Windows shares files over a protocol called SMB/CIFS. Linux doesn't speak that natively, so Samba sits on top of it and translates: it makes a Linux folder look exactly like a normal Windows network share, and lets a Windows folder be mounted from Linux too.
Two background processes do the actual work:
smbd handles file transfers, permissions, and logins.
nmbd handles name resolution — the reason you can type \myserver instead of memorizing an IP address every time.
Everything is controlled from a single file, /etc/samba/smb.conf. It's split into sections — global settings, authentication, printing, and so on — but almost everything in this guide happens in the last one, Share Definitions, where each shared folder gets its own block. The exhaustive parameter list lives in Samba's own documentation.
**
Installing Samba**
Update your packages, then install Samba itself:
bash
apt update && apt upgrade
apt install samba
apt install vim
Before touching the config file, back it up. It takes five seconds and it's saved me more than once:
bash
cp /etc/samba/smb.conf /etc/samba/smb.conf.bak
Two commands you'll run constantly from here on:
testparm checks the config file for mistakes.
systemctl restart smbd applies whatever you just changed.
Get in the habit of running testparm before restarting — it catches a typo before it takes your shares down, not after. A misplaced ys instead of yes on a boolean parameter is enough to break the whole config, and testparm will tell you exactly that:
Load smb config files from /etc/samba/smb.conf
set_variable_helper(ys): value is not boolean!
Error loading services.
Part 1: A Share With No Login Required
Start with the simplest version: a folder anyone on the network can open, read from, and write to, with no username or password involved. This is a good fit for a home lab or a quick internal drop folder — not something you'd want facing a shared office network.
Create the folder, then open the config file:
bash
mkdir -p /srv/samba/share
vi /etc/samba/smb.conf
At the bottom, under Share Definitions, add this block:
ini
[shared_folder]
comment = Public share on Debian
path = /srv/samba/share
browseable = yes
guest ok = yes
read only = no
What each line is actually doing:
Parameter What it does
[shared_folder] The name that shows up on the network, as \your-server\shared_folder
comment Just a description — doesn't affect functionality
path The real folder on disk behind the share
browseable Whether the share appears when someone browses the network. Set to no and the share still works, it just won't show up unless someone types the exact path
guest ok This is what actually skips the login
read only Set to no, this means people can create and delete files, not just open them
Filesystem Permissions vs. Samba Permissions
Samba's config decides who gets let in the door; Linux's own file permissions decide what they can do once they're inside. Both layers have to agree, or you'll get a share that "should" work and doesn't.
The fast way to make sure nothing gets blocked:
bash
chmod -R 777 /srv/samba/share
That's fine for a quick lab test, but 777 also gives every local user write access on the Linux side, which is rarely what you actually want. The more deliberate version restricts write access to a specific group instead of the whole world:
bash
chmod -R 755 /srv/samba/share
ini
[PublicShare]
path = /srv/samba/share
public = yes
writable = no
write list = @admin
Here, everyone can read and browse the folder, but only members of the admin group can write to it — even though the share itself isn't guest-restricted. (public is just an older name for guest ok — they do the same thing.)
Validate the config and restart the service:
bash
testparm
systemctl restart smbd
Worth saying plainly: guest ok = yes combined with read only = no means anyone on the network can add, edit, or delete files here with zero credentials. That's the trade you're making for the convenience — fine on a trusted home network, not something to leave running anywhere more exposed.
**
Testing From Windows
**
Open File Explorer on the Windows machine and type the server's IP straight into the address bar — \192.168.1.150. The share should show up; open it, drop a test file in, and close the window.
Then flip browseable to no and restart smbd again. Now \192.168.1.150 on its own won't list the share, but \192.168.1.150\shared_folder still opens it directly. This is the part that catches people out: browseable = no hides a share from casual browsing, it doesn't protect it. Anyone who already knows or guesses the name walks straight in. Real protection is guest ok = no plus actual user accounts — which is where Part 2 goes.
Mounting the Guest Share From Another Linux Machine
Windows isn't the only client here — a second Linux machine can mount the same share using cifs-utils:
bash
apt install cifs-utils
mkdir /mnt/remote-share
mount -t cifs -o guest //192.168.1.150/shared_folder /mnt/remote-share
Confirm it worked:
bash
ls /mnt/remote-share
df -h | grep remote-share
That's the open version fully working in both directions. Now let's lock it down.
Part 2: Adding Authentication
This time, instead of guest ok = yes, flip it the other way and back it with real user accounts.
Create the folder and add a new block:
bash
mkdir -p /srv/samba/docs_privados
ini
[private]
comment = Authenticated file share
path = /srv/samba/docs_privados
browseable = yes
guest ok = no
read only = no
guest ok = no is the entire change — Samba now asks for a username and password before letting anyone connect.
Controlling Permissions on New Files
There are two different ways to control what permissions new files and folders get once people start writing here.
Option 1 — cap the permission bits:
ini
create mask = 750
directory mask = 770
create mask limits files, directory mask limits folders — think of them as a ceiling on top of whatever the client asks for.
Option 2 — inherit the parent folder's permissions:
ini
inherit permissions = yes
With this on, new folders get an exact copy of the parent directory's permissions, and new files inherit just the read/write bits.
Pick one. inherit permissions overrides the two masks above if both happen to be present — combining them doesn't get you "the strictest of both," it just makes inherit permissions win silently.
Creating Samba Users
Samba keeps its own password list, completely separate from the regular Linux login. A user has to already exist as a Linux account before you can give them Samba access:
bash
smbpasswd -a username # adds a user and sets their Samba password
smbpasswd -d username # disables a user
smbpasswd -e username # re-enables a user
smbpasswd -x username # removes a user entirely
pdbedit -L lists every Samba user currently configured, if you ever lose track of who's in there.
Restart the service and test from Windows — \192.168.1.150\private should now prompt for credentials instead of connecting straight away.
bash
systemctl restart smbd
Getting Specific About Who Can Do What
Once authentication is in place, you can get a lot more granular:
Parameter What it does
valid users = @pvsw Limits the whole share to one group
invalid users = xpto Blocks one account outright even if they'd otherwise qualify
read list = @editores Gives that group read access even on a share that's otherwise writable
write list = @editores, alex Gives write access to a group plus one extra user, even on a read-only share
hosts allow = 192.168.2.0/24 192.168.3.0/24 Restricts by network instead of by account
hosts deny = 10.0.0.0/24 Blocks a whole network range, independently of any user-based rule
The Automatic Home Directory Share
One thing worth knowing about: Samba automatically shares every user's home directory as \server\username, through a block called [homes] that ships enabled by default:
ini
[homes]
comment = Home Directories
browseable = no
read only = yes
create mask = 0700
directory mask = 0700
valid users = %S
%S resolves to whichever share is being connected to — in a [homes] context, that's effectively "the username logging in," which is what stops one person browsing into someone else's home folder. If you don't want this feature at all, comment out (or delete) the entire [homes] block and restart smbd.
Mounting an Authenticated Share From Linux
Same idea as the guest mount, just with credentials attached:
bash
apt install smbclient cifs-utils
mkdir /media/pc_windows
mount -t cifs -o username=youruser,password=yourpassword \
//192.168.1.50/sharename /media/pc_windows
Typing the password directly into the command works, but it also lands in your shell history and shows up to anyone running ps aux while it executes. A credentials file avoids both problems. Save this as its own file:
username=youruser
password=yourpassword
Lock the file down, then reference it instead of typing the password directly:
bash
chmod 600 /etc/samba/credentials/windows-share
mount -t cifs -o credentials=/etc/samba/credentials/windows-share \
//192.168.1.50/sharename /media/pc_windows
If you change a Samba password later and Windows keeps rejecting the new one, it's almost always a cached credential rather than an actual failure. Clear it and try again:
Windows 7/8: net use * /DELETE then klist purge
Windows 10/11: klist purge
What Actually Went Wrong (And What It Actually Meant)
A few things tripped me up while testing this — here's what each one actually meant, so you don't have to burn the same twenty minutes I did.
testparm refusing to load, with "value is not boolean" A yes/no parameter has a typo somewhere — ys instead of yes is the classic one. Exactly why running testparm before restarting is worth the habit.
Windows popping up "You don't have permission to open this file" This shows up the moment someone tries to write to a share that's actually read-only, or isn't on the right write list. read only, write list, and valid users are the three places to check — a share can feel writable in your head and still be read only = yes in the file.
The share not showing up at all, despite guest ok = yes Check browseable. If it's no, that's expected — the share is hidden from browsing, not from access, and typing the full path directly still gets you in.
A correct-looking username and password still getting rejected Confirm the Linux user actually exists (id username), and that a Samba password was set for them with smbpasswd -a. Creating the Linux account alone isn't enough — Samba keeps its own, separate user list.
Permission denied even though smb.conf looks completely right The config controls who Samba lets in; the actual filesystem permissions on the folder still apply underneath that. ls -la on the shared folder itself usually explains it — a share defined as read only = no still won't let anyone write if the folder is chmod 700 and owned by someone else entirely.
**
Wrapping Up
**
That's Samba working both ways: a wide-open share for quick, no-friction access, and a properly authenticated one with real accounts, group permissions, and network-level restrictions on top. You've tested both from Windows and from a second Linux machine, and you've got a short list of the errors most likely to trip you up along the way.
This one stuck to Samba and the CIFS protocol on purpose — making these mounts survive a reboot (fstab, autofs, systemd units) is its own can of worms, and it's getting a dedicated article of its own rather than a rushed paragraph at the end of this one.
SOCIAL SHARE CARD GENERATOR