You just finished migrating your media library to a new Fedora machine
Your Windows laptop and your Android phone both need to access the same folder. You install Samba, point your clients to the IP, and get a permission denied error. The service is running, the firewall is open, but the share refuses to connect.
What is actually happening
Samba translates between the SMB protocol used by Windows and macOS, and the POSIX file system used by Linux. It does not share files directly. It acts as a gateway. When a client connects, Samba checks three layers in strict order. The network firewall allows the traffic. The SMB service state is active. The Linux file permissions grant read or write access. If any one of those layers blocks access, the connection fails. SELinux adds a fourth layer that enforces which directories are allowed to be served over the network. A missing SELinux context or a closed firewall port will silently drop the connection. The error message on the client side rarely tells you which layer failed.
Think of Samba as a bilingual translator at a secure facility. The client speaks SMB. The disk speaks POSIX. The translator checks the visitor badge, verifies the security clearance, and then hands over the documents. If the badge is missing, the translator stops. If the clearance is wrong, the translator stops. If the documents are locked in a drawer the translator cannot open, the translator stops. You need to check all three checkpoints.
Run testparm before you restart the service. Syntax errors in smb.conf will silently fall back to defaults and break your share.
The fix or how to
Start with the package installation. Fedora splits the server and client tools into separate packages. You need both to test the configuration without leaving the terminal.
Here is how to install the server and client tools in one transaction.
sudo dnf install samba samba-client -y
# -y skips the confirmation prompt for a clean terminal run
# samba provides the smbd and nmbd daemons
# samba-client gives you smbclient for local testing
Next, create the directory you want to share. Samba does not create directories for you. It only exposes what already exists on the disk. Set the ownership and permissions before editing the configuration file.
Here is how to create a shared directory with correct ownership.
sudo mkdir -p /srv/samba/shared
# /srv is the standard FHS location for site-specific data served by the system
sudo chown -R nobody:nobody /srv/samba/shared
# nobody is the default Samba guest user for read-only access
sudo chmod -R 0775 /srv/samba/shared
# 0775 allows group writes while keeping the directory secure from other users
Now edit the configuration file. The main configuration lives in /etc/samba/smb.conf. Never edit files in /usr/lib/samba/. Those ship with the package and get overwritten on updates. Add a new section at the bottom of the file. Each section starts with the share name in square brackets.
Here is how to define a basic read-write share in the configuration file.
[global]
workgroup = WORKGROUP
# Matches the default Windows workgroup name for easy discovery
server string = Fedora Samba Server
# Identifies the server in network browser lists
security = user
# Requires valid username and password authentication
[shared]
path = /srv/samba/shared
# Points to the directory created earlier
browseable = yes
# Makes the share visible in Windows Network tab
read only = no
# Allows authenticated users to write files
valid users = your_username
# Restricts access to specific system accounts
Samba uses its own password database. Your Linux system password does not work for SMB authentication. Set the SMB password separately. The command will prompt you twice for the new password.
Here is how to add your user to the Samba password database.
sudo smbpasswd -a your_username
# -a adds a new user to the passdb.tdb file
# The password is stored separately from /etc/shadow
Fedora's firewall blocks SMB traffic by default. Open the ports and reload the runtime configuration. The firewalld service manages both persistent and runtime rules. Reloading applies the change immediately without dropping existing connections.
Here is how to open the Samba ports in the firewall.
sudo firewall-cmd --permanent --add-service=samba
# --permanent writes the rule to the configuration file
# --add-service=samba opens TCP 139, 445 and UDP 137, 138
sudo firewall-cmd --reload
# Applies the persistent rule to the running firewall immediately
SELinux controls whether Samba is allowed to read and write to /srv/samba/shared. The default policy expects shares to live under /srv/samba/. If you place the share elsewhere, SELinux will block it. Set the correct context so the policy allows network access.
Here is how to apply the correct SELinux context to the share directory.
sudo semanage fcontext -a -t samba_share_t "/srv/samba/shared(/.*)?"
# Defines the expected context for the directory and all future files
sudo restorecon -Rv /srv/samba/shared
# Applies the context immediately and recursively
Enable the services and start them. The smb service handles file sharing. The nmb service handles NetBIOS name resolution for older Windows clients. Enable both so they survive a reboot.
Here is how to enable and start the Samba daemons.
sudo systemctl enable --now smb nmb
# --now starts the services immediately after enabling them
# systemd will automatically restart them if they crash
Restart the service after every configuration change. Samba does not hot-reload smb.conf reliably.
Verify it worked
Test the connection from the Fedora machine before pointing a Windows client at it. The smbclient tool acts as a command-line SMB client. It connects to the share and lists the contents.
Here is how to verify the share is accessible locally.
smbclient //localhost/shared -U your_username
# Connects to the share using the local loopback address
# -U specifies the Samba username to authenticate with
If the connection succeeds, you will see an smb: \> prompt. Type ls to list files. Type quit to exit. If you get a NT_STATUS_ACCESS_DENIED error, check the valid users line in smb.conf and verify the SMB password was set correctly. Run journalctl -xeu smb to read the exact denial reason. The x flag adds explanatory text and the e flag jumps to the end of the log.
Check the configuration syntax before deploying to clients. Run testparm to validate smb.conf. It prints a clean summary of active shares and flags missing parameters.
Common pitfalls and what the error looks like
The most common failure is a mismatch between Linux permissions and Samba configuration. Samba checks Linux permissions first. If the directory owner is root and permissions are 0700, Samba will deny access even if read only = no is set. Change the ownership to a user that exists in the Samba password database.
SELinux denials appear in the journal with a one-line summary. You will see type=AVC msg=audit(...): avc: denied { read } for pid=... comm="smbd" name="shared". Do not disable SELinux to fix this. Set the correct context with semanage and restorecon. Disabling SELinux removes the security boundary for the entire system.
Windows clients sometimes cache old credentials. If you change the Samba password and the client still asks for the old one, clear the Windows credential manager or disconnect the network drive and reconnect. The error The specified network password is not correct usually means the client is sending cached credentials, not that the server rejected the new password.
The browseable = no setting hides the share from network discovery. Clients can still connect if they type the path manually. This is useful for sensitive shares but confusing during initial setup. Set it to yes while testing.
Modern Windows versions disable SMBv1 by default. Samba on Fedora disables it too. If an older device tries to connect, you will see SMB1 is disabled by default in the logs. Enable SMBv1 only if you absolutely must support legacy hardware, and isolate that device on a separate VLAN.
Read the journal before guessing. journalctl -xeu smb shows the exact layer that rejected the connection.
When to use this vs alternatives
Use Samba when you need cross-platform file sharing with Windows, macOS, and Linux clients on the same network. Use NFS when all clients run Linux or BSD and you want maximum throughput without authentication overhead. Use SSHFS when you need encrypted file transfers over untrusted networks or the internet. Use Nextcloud or Syncthing when you want automatic synchronization and version history instead of a mounted drive. Stay on Samba if you only need a simple network drive that behaves like a local folder.