You installed Samba and the share still fails
You installed Samba, edited the configuration file, and restarted the service. Your Windows machine sees the Fedora host but returns Access denied when you try to connect. Or worse, the share doesn't appear in the network list at all. You checked the directory permissions with ls -l and they look correct. The problem is rarely the directory permissions.
Samba requires three independent layers to align. The configuration file must define the share and its rules. The Samba password database must contain an entry for the user, which is separate from the system password. SELinux must allow the smbd process to access the specific directory path. If any one of these layers fails, the connection drops. The error messages often point to the wrong layer. A Permission denied error usually indicates an SELinux denial or a missing Samba user, not a Linux file permission issue. Fix the alignment across all three layers and the share works.
What Samba is actually doing
Samba implements the SMB protocol, which Windows and macOS use for file sharing. It acts as a translation layer between the network and the Linux filesystem. When a client sends a request, Samba translates the SMB operation into a POSIX system call. This translation requires coordination between the daemon, the user database, and the security policy.
The Samba daemon reads /etc/samba/smb.conf to determine what directories are exposed and who can access them. It maintains its own password database in /var/lib/samba/private/. This database is distinct from /etc/shadow. A user can exist on the system but still be unable to authenticate to Samba until added to the Samba database.
Fedora enables SELinux by default. SELinux enforces mandatory access control based on security contexts. Even if a directory has chmod 777, SELinux blocks access if the file context does not match the policy for the Samba daemon. The daemon expects shares to be labeled samba_share_t. Standard directories often have different labels. You must explicitly relabel the share directory and ensure the firewall allows the Samba ports.
Configure the share definition
The configuration file defines shares and global settings. Edit the file in /etc/. Never edit files in /usr/lib/samba/. Those files ship with the package and get overwritten on update. Changes in /usr/lib/ are lost.
Here's how to define a secure share with explicit user access.
[global]
# Set the workgroup to match your Windows network. Default is WORKGROUP.
workgroup = WORKGROUP
# Allow the local subnet to access shares. Adjust for your network.
hosts allow = 127. 192.168.1.
# Require SMB2 or higher. Older protocols are insecure and disabled by default.
server min protocol = SMB2
[Documents]
# The absolute path on the filesystem. Relative paths cause silent failures.
path = /srv/samba/documents
# Allow the share to appear in network browsers.
browseable = yes
# Require authentication. Do not set to no unless this is a public drop box.
guest ok = no
# Map the Samba user to the Linux user for file ownership.
valid users = fedorauser
# Allow write access to the listed users.
read only = no
Run testparm before you restart. A syntax error in smb.conf kills the daemon silently.
Create the Samba user
Samba maintains a separate password database. A Linux user cannot authenticate to Samba until added to the Samba database. The Samba password can differ from the system login password. This separation allows you to change the Samba password without affecting SSH or desktop login.
Here's how to add a user to the Samba database.
# The user must exist in the system first. Create it if needed.
sudo useradd -m fedorauser
# Add the user to the Samba password database.
# You will be prompted for a new Samba password.
sudo smbpasswd -a fedorauser
# Enable the account. New accounts are disabled by default.
sudo smbpasswd -e fedorauser
Set the Samba password immediately. A system user without a Samba entry cannot authenticate.
Align SELinux contexts
SELinux labels files with security contexts. The Samba daemon requires the samba_share_t context to serve files. Standard home directories use user_home_t. You must relabel the share directory. If you skip this step, Samba logs Permission denied errors even when file permissions are open.
Here's how to set the correct context and apply it.
# Install policycoreutils-python-utils if semanage is missing.
sudo dnf install policycoreutils-python-utils
# Add a file context rule for the share directory.
# This ensures the label persists across relabeling or restorecon.
sudo semanage fcontext -a -t samba_share_t "/srv/samba/documents(/.*)?"
# Apply the context to existing files and directories recursively.
sudo restorecon -Rv /srv/samba/documents
# Verify the context matches the expected label.
ls -Zd /srv/samba/documents
Check the context with ls -Z. If the label is wrong, the share fails regardless of permissions.
Open the firewall
The firewall blocks incoming connections by default. Samba uses multiple ports for file sharing and name resolution. The samba service definition in firewalld covers the necessary ports.
Here's how to allow Samba through the firewall.
# 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.
sudo firewall-cmd --reload
Reload the firewall after every rule change. The runtime config and persistent config diverge otherwise.
Start and verify the service
Samba consists of two main services. smb handles file and print sharing. nmb handles NetBIOS name resolution, which Windows uses for network discovery. Both services must be running for the share to appear in the network list.
Here's how to start the services and check their status.
# Enable and start the SMB service.
sudo systemctl enable --now smb
# Enable and start the NMB service for network discovery.
sudo systemctl enable --now nmb
# Check the status of both services.
systemctl status smb nmb
Run journalctl -xeu smb if the service fails to start. The logs show configuration errors or permission denials.
Verify the configuration
Use testparm to parse the configuration file. It checks for syntax errors, undefined parameters, and potential issues. It also displays the effective configuration, which helps debug inheritance problems.
Here's how to validate the config and test connectivity.
# Parse the configuration and display warnings.
testparm
# List available shares from the local machine.
# The -U% flag attempts a guest connection to list shares.
smbclient -L localhost -U%
# Connect to the share as a specific user to test access.
smbclient //localhost/Documents -U fedorauser
Run testparm first. Read the warnings before guessing at the cause of failure.
Common pitfalls and error patterns
SELinux denials are the most frequent cause of failure. When SELinux blocks access, the client sees Access denied or Permission denied. The smbd logs show the denial, but the message is often buried. Check the SELinux troubleshoot logs for a clear summary.
# Search for SELinux denials related to Samba.
journalctl -t setroubleshoot | grep -i samba
The output includes a one-line summary and a suggested fix. Read the summary before disabling SELinux. Disabling SELinux exposes the system to privilege escalation attacks. Fix the context or boolean instead.
Another common issue is the Samba user mapping. If valid users lists a username that doesn't exist in the Samba password database, authentication fails. The error looks like a wrong password. Verify the user exists in both the system and Samba databases.
Network discovery failures often stem from the nmb service. If the share exists but doesn't appear in the Windows network list, check nmb. Windows relies on NetBIOS broadcasts for discovery. Ensure nmb is running and the firewall allows the service.
Home directory shares require a specific SELinux boolean. If you enable the [homes] section, you must allow Samba to access home directories.
# Allow Samba to serve home directories.
sudo setsebool -P samba_enable_home_dirs on
The -P flag makes the boolean persistent across reboots. Without it, the setting resets on restart.
When to use Samba versus alternatives
Use Samba when you need to share files with Windows machines or macOS clients that expect a network drive interface. Use NFS when all clients are Linux or BSD and you want POSIX-compliant performance without protocol translation overhead. Use SSHFS when you need encrypted transport over untrusted networks and only a few files at a time. Use a cloud sync tool like Nextcloud when you need web access, versioning, and collaboration features beyond simple file storage.