You shared a folder but nothing connects
You created a directory on your Fedora machine and want your Windows laptop or Android phone to access it. You installed Samba, restarted the service, and clicked "Connect" on the client. Nothing happens. Or worse, the client asks for a password, you type it, and it rejects you. The share is invisible, or the permissions are locked down tight. This is the classic Samba setup trap.
The issue is rarely the Samba package itself. Fedora ships a working Samba server. The problem is the layers of security and configuration that sit around it. Fedora runs SELinux to control file access. Fedora runs Firewalld to block network ports. Samba uses a separate password database from your Linux user account. If you miss one piece, the share fails. You need the package, the config, the firewall rule, the SELinux context, and the Samba password.
What is actually happening
Samba implements the SMB/CIFS protocol. This is the standard protocol Windows uses for file sharing. When you map a network drive in Windows, it speaks SMB. Samba on Fedora speaks SMB back.
The connection flow has three gates. The firewall checks if the port is open. SELinux checks if the smbd process is allowed to read the specific directory. The Samba daemon checks if the user has a valid Samba password and if the config file grants access to that share. If any gate closes, the client gets an error.
SELinux denials often look like permission errors to the client. The client sees Access Denied and assumes the Linux file permissions are wrong. The logs show the truth. Run journalctl -t setroubleshoot to see SELinux alerts. The one-line summary tells you exactly which process was blocked from which file type. Read those before disabling SELinux.
Install the packages
Start by installing the server and the client tools. The client tools let you test the share locally without needing a second machine.
# Install the Samba server daemon and client utilities
sudo dnf install samba samba-client
# samba provides smbd for file sharing and nmbd for NetBIOS name resolution
# samba-client provides smbclient for local verification and testing
Verify the installation succeeded. The packages pull in dependencies for encryption and authentication.
# Check that the packages are installed and active
rpm -q samba samba-client
# Output should list the version numbers, confirming installation
Create the directory and set permissions
Samba shares map to filesystem directories. You need a directory that exists and has the right ownership. Samba checks Linux permissions first. If the Linux user running the Samba process cannot read the file, Samba cannot share it.
Create a dedicated group for the share. This keeps access controlled. Add your user to the group. Create the directory under /srv/samba. This is the standard location for network service data on Fedora.
# Create a group for share access
sudo groupadd sharegroup
# Add your current user to the group so you can access the share
sudo usermod -aG sharegroup $USER
# Create the shared directory structure
sudo mkdir -p /srv/samba/share
# Set ownership to root and the share group
sudo chown root:sharegroup /srv/samba/share
# Set permissions: 2770 gives rwx to owner and group, setgid ensures new files inherit the group
sudo chmod 2770 /srv/samba/share
The 2770 permission is important. The 2 sets the setgid bit. When a user creates a file in this directory, the file inherits the sharegroup group instead of the user's primary group. This keeps all files in the share accessible to everyone in the group.
Set the SELinux context before you copy data. Moving files after the fact requires running restorecon anyway. Labeling the directory now ensures new files get the correct context automatically.
# Define the SELinux policy for the directory and all contents
sudo semanage fcontext -a -t samba_share_t "/srv/samba/share(/.*)?"
# Apply the context to the filesystem
sudo restorecon -Rv /srv/samba/share
# semanage updates the policy database so the rule persists across relabels
# restorecon applies the label immediately and verifies the change
SELinux is not a firewall. It controls what processes can access what files. The smbd process is only allowed to read files labeled samba_share_t. If your directory is in /home or /var, it has a different label. Samba will silently deny access. The client sees a permission error. You must label the directory correctly.
Open the firewall
Fedora blocks incoming connections by default. Samba uses ports 139 and 445. Firewalld manages these ports. You need to allow the samba service.
# Add the samba service to the permanent firewall configuration
sudo firewall-cmd --permanent --add-service=samba
# Reload the firewall to apply the change to the runtime configuration
sudo firewall-cmd --reload
# --permanent saves the rule for the next boot
# --reload syncs the runtime config with the persistent config
Reload the firewall immediately. The runtime and persistent configs diverge if you skip this. firewall-cmd --reload is the standard step after every rule change.
Configure the share
Edit the Samba configuration file. The file lives in /etc/samba/smb.conf. Files in /etc are user-modified. Files in /usr/lib ship with the package. Never edit files in /usr/lib.
Add a section for your share. The section name in brackets becomes the share name visible to clients.
# Add this block to the end of /etc/samba/smb.conf
[share]
# Path to the directory on the filesystem
path = /srv/samba/share
# Allow access only to members of the sharegroup
valid users = @sharegroup
# Enable write access for valid users
read only = no
# Set permissions for new files: rw for owner and group, nothing for others
create mask = 0660
# Set permissions for new directories: rwx for owner and group, nothing for others
directory mask = 0770
The valid users parameter restricts access. Without it, any authenticated Samba user can access the share. The @ symbol refers to a group. The create mask controls permissions on new files. Windows clients often create files with 0666. If you do not set a mask, your shared files become world-readable. Set create mask = 0660 to keep files private to the group.
Run testparm before you restart. A syntax error in smb.conf kills the service silently.
# Validate the configuration file for syntax errors
sudo testparm
# testparm parses smb.conf and reports any errors or deprecated options
# If output ends with "Loaded services file OK", the config is valid
Set the Samba password
Samba does not use your Linux password. It maintains a separate password database in /var/lib/samba/private/passwd.tdb. This allows Samba to authenticate users who might not have shell access. It also supports SMB encryption for passwords.
You must set a Samba password for every user who needs access. The user must exist in Linux first.
# Add the current user to the Samba password database
sudo smbpasswd -a $USER
# You will be prompted to enter and confirm a new password
# This password is used for SMB authentication, not for logging into Fedora
The Samba password can be different from your Linux password. It is often easier to keep them the same for memory, but they are independent. Changing your Linux password does not change your Samba password. You must run smbpasswd again if you want to update the Samba credential.
Start the services
Restart the Samba services to apply the configuration. Samba runs two daemons. smbd handles file and print services. nmbd handles NetBIOS name resolution.
# Restart the Samba file server and NetBIOS name server
sudo systemctl restart smb nmb
# Enable the services to start automatically on boot
sudo systemctl enable smb nmb
# systemctl restart applies the new config immediately
# systemctl enable ensures the services survive a reboot
Check the status to confirm they are running.
# Verify the services are active and running
systemctl status smb nmb
# Look for "active (running)" in the output
# Recent log lines appear below the status, showing startup messages
Check systemctl status before restart. The status output shows recent log lines and the current state in one view. It tells you if the service is already running or if it failed to start.
Verify the share
Test the share from the Fedora machine. This confirms Samba is serving the share and accepting authentication.
# List available shares on the local machine
smbclient -L localhost -U%
# -L lists shares without connecting
# -U% specifies an empty password for anonymous enumeration
# Output should show "share" in the list of Disk shares
Connect to the share and check permissions.
# Connect to the share using your Samba credentials
smbclient //localhost/share -U $USER
# You will be prompted for the Samba password
# After login, you get an smb: prompt
# Type "ls" to list files and "exit" to quit
If the connection succeeds, the share is working. You can now access it from a Windows client using \\<fedora-ip>\share or from a Linux client using smbclient //<fedora-ip>/share.
Run journalctl -xeu smb if the share is invisible. The logs tell you exactly which layer blocked the connection. Look for NT_STATUS errors or SELinux denials.
Common pitfalls
The smbclient command will refuse to connect and print tree connect failed: NT_STATUS_ACCESS_DENIED. This usually means SELinux is blocking access. Check the context of the directory with ls -Z /srv/samba/share. The output should show samba_share_t. If it shows user_home_t or default_t, run restorecon again.
If you see Connection timed out from a remote client, the firewall is blocking the connection. Run sudo firewall-cmd --list-services on Fedora. Ensure samba is in the list. If the client is on a different subnet, check your router's firewall as well.
If the client accepts the password but you cannot write files, check the create mask and directory mask in smb.conf. Also check the Linux permissions. chmod 777 is not a solution. It breaks security and often triggers SELinux alerts. Fix the ownership and masks instead.
If the share disappears after a reboot, check that smb and nmb are enabled. Run systemctl is-enabled smb nmb. If they are not enabled, run systemctl enable smb nmb.
When to use Samba versus alternatives
Use Samba when you need to share files with Windows clients or mobile devices that support SMB. Use NFS when all clients are Linux or macOS and you want raw POSIX performance without authentication overhead. Use SSHFS when you only need to mount a remote directory on demand and want encryption over the network. Use a cloud sync tool when you need offline access and conflict resolution across devices.