Samba shares across Linux and Windows networks

Samba file sharing lets a Linux server publish folders over the Server Message Block protocol (SMB/CIFS), so Windows File Explorer and Linux clients can open the same network drive. On RHEL, CentOS and Fedora, it bridges Windows desktops with Linux-hosted storage, backups and application data.

A dependable Samba service depends on matching Unix accounts, filesystem permissions, SELinux policy, firewall rules and client authentication. The goal is controlled access for named users or groups, not an open anonymous share.

Choosing an access model

Begin by identifying who needs the shared folder and whether it contains personal, financial or commercially sensitive information. Match the access model to the organisation’s size and its ability to manage user identities.

Access model	Good fit	Samba method	Main control
Guest access	Public downloads	guest ok = yes	Network restriction and read-only access
Local accounts	Small team shares	security = user	Passwords and POSIX ACLs
Active Directory	Larger mixed estates	winbind or realm join	Domain account lifecycle

In the Australian small-business market, lean IT teams often support Windows laptops used for Teams or Outlook alongside specialist Linux servers in Sydney, Melbourne and Brisbane. A Samba share can connect those everyday workflows, but teams should choose the simplest model they can maintain and audit.

Preparing the Linux host

Install and activate Samba on RHEL-family hosts:

sudo dnf install samba samba-client
sudo systemctl enable --now smb

Restrict TCP 445 to the trusted office network with a firewalld rich rule, adapting the subnet and default zone to the site:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.20.0/24" port protocol="tcp" port="445" accept'
sudo firewall-cmd --reload

Service startup should be checked through systemd runlevels and targets, rather than legacy init assumptions.

Creating accounts and storage

Create a Unix identity and its matching Samba credential, then add authorised users to a dedicated group:

sudo useradd -m -s /sbin/nologin alice
sudo groupadd -f sambausers
sudo usermod -aG sambausers alice
sudo smbpasswd -a alice

Create the storage with restrictive ownership and mode. On SELinux-enabled systems, label the path for Samba file serving:

sudo install -d -m 0770 -o alice -g sambausers /srv/samba/team
sudo semanage fcontext -a -t samba_share_t '/srv/samba/team(/.*)?'
sudo restorecon -Rv /srv/samba/team

Install policycoreutils-python-utils if semanage is unavailable. Avoid the broad samba_export_all_rw setting unless a documented exception makes narrower labelling impractical.

Building the share configuration

Keep global security settings separate from individual shared-folder permissions:

[global]
workgroup = WORKGROUP
server role = standalone server
server min protocol = SMB2_02
map to guest = never
guest ok = no
hosts allow = 127.0.0. 192.168.20.0/24

[team]
path = /srv/samba/team
valid users = @sambausers
browseable = yes
read only = no
create mask = 0660
directory mask = 0770
force group = sambausers

Validate the syntax and test authentication before reloading the service:

sudo testparm -s
sudo smbclient //localhost/team -U alice
sudo systemctl reload smb

Adjust hosts allow to match the actual network. A successful smbclient login confirms the Samba password database, share permissions and filesystem access are working together.

Connecting Windows and Linux clients

On Windows, open Run, enter \\server01\team and select Map network drive. Use the server’s DNS name rather than a changing IP address, and enter the Samba username when prompted. Clear any obsolete entry in Windows Credential Manager if a previous password remains cached.

Linux clients can mount the same export with mount.cifs; install cifs-utils if necessary:

sudo mount -t cifs //server01/team /mnt/team \
  -o credentials=/etc/samba/team-creds,vers=3.1.1,uid=1000,gid=1000

Store the credentials file with mode 0600, and adjust uid and gid to match the local account. SMB 3.1.1 provides encryption and modern negotiation, while older SMB1 clients should not be enabled.

Securing and operating the service

Keep anonymous access disabled, restrict network reachability and review active sessions with smbstatus. Service events appear in journalctl -u smb, so repeated authentication failures, abnormal transfer volumes and unexpected stoppages deserve attention. For broader host-capacity checks, server performance monitoring can reveal CPU, disk or memory pressure before shares become unreliable. Snapshot shared data and test restores because Samba does not replace backups.

Shared HR, client or health records can turn an access mistake into a reportable privacy incident. Organisations covered by Australia’s Privacy Act 1988 must follow the Australian Privacy Principles, assess eligible breaches under the Notifiable Data Breaches scheme and check applicable state or territory notification laws. Apply least privilege, promptly remove departing staff with smbpasswd -x username and retain audit records according to organisational obligations.

Validating a dependable rollout

Test the complete path with a real Windows account, including create, read, rename and delete permissions, then repeat it from Linux. Confirm that the service starts after a reboot and that monitoring reaches the responsible administrator. Repeated checks can be shortened with awk text processing in a shell script that summarises relevant journal entries.

Keep a versioned copy of smb.conf, record the service and firewall settings, and document the recovery path for each share. The practical takeaway is to prove one least-privilege share with a real Windows account, document its storage and recovery process, then repeat that controlled pattern for each new team folder.