Samba: Share Files with Windows

By Khimananda Oli | Last reviewed: August 2026

Cross-platform file sharing remains a fundamental requirement in mixed-OS environments, yet misconfigured shares are a frequent source of security incidents and audit failures. When you need to implement Samba: Share Files with Windows clients from an Ubuntu server, the difference between a fragile hack and a production-grade solution lies in explicit user mapping, strict filesystem permissions, and disciplined firewall rules. This guide walks through the exact configuration I use in enterprise environments to ensure reliable access without exposing your infrastructure to unnecessary risk.

How do you install and configure Samba to share files with Windows on Ubuntu?

Before editing any configuration, ensure your base system is hardened. I always start with a fresh Ubuntu security hardening baseline because Samba exposes network services that attackers actively probe. Install the required packages and create a dedicated directory for sharing:

sudo apt update && sudo apt install -y samba samba-common-bin
sudo mkdir -p /srv/samba/shared
sudo chown nobody:nogroup /srv/samba/shared
sudo chmod 2770 /srv/samba/shared

The setgid bit (2770) ensures new files inherit the group ownership, which prevents permission drift when multiple users write to the same share. This is a common oversight that causes "access denied" errors weeks after deployment.

Defining the share in smb.conf

Edit /etc/samba/smb.conf and add your share definition at the bottom. Avoid modifying the global section unless necessary; defaults in Ubuntu 24.04+ are sensible for most cases:

[SharedDocs]
   path = /srv/samba/shared
   browseable = yes
   read only = no
   valid users = @sambashare
   write list = @sambashare
   force group = sambashare
   create mask = 0660
   directory mask = 2770
   guest ok = no

Key points: never set guest ok = yes in production. Always use valid users or valid groups to explicitly authorize access. The force group directive combined with the setgid directory ensures consistent ownership regardless of which authenticated user creates a file.

Creating Samba users and testing configuration

Samba maintains its own password database separate from Linux PAM. Add users to the system first, then enable them for Samba:

1. Create a system group: sudo groupadd sambashare
2. Add existing users: sudo usermod -aG sambashare username
3. Set Samba passwords: sudo smbpasswd -a username
4. Validate syntax: testparm -s (this catches 90% of config errors before restart)
5. Restart services: sudo systemctl restart smbd nmbd

Always run testparm before restarting. A typo in smb.conf will prevent smbd from starting, and debugging without validated config wastes time. On Windows, connect via \\SERVER_IP\SharedDocs and authenticate with the Samba credentials you just set.

What are the critical security settings for Samba file sharing?

Security in Samba isn't optional—it's where most deployments fail audits. In my experience helping teams achieve SOC 2 compliance, these three controls are non-negotiable:

• Disable SMBv1 globally: Add server min protocol = SMB2_10 to the [global] section. SMBv1 has known remote code execution vulnerabilities and should be treated as deprecated since 2017.
• Restrict network access at the firewall: Never expose port 445 to the internet. Use UFW to limit access to specific subnets: sudo ufw allow from 192.168.1.0/24 to any port 445 proto tcp. If you're managing UFW rules, make this rule explicit rather than relying on default policies.
• Enforce encryption in transit: For sensitive data, add server smb encrypt = required to force encrypted sessions. Modern Windows clients support this natively, but test with legacy systems first.

A common mistake is assuming Samba respects Linux file permissions alone. It doesn't. Samba evaluates its own valid users directive before checking filesystem permissions. Both must align: if a user is in valid users but lacks write permission on the directory, they'll get confusing access errors. Always verify both layers independently during setup.

How does Samba compare to NFS and native Windows sharing for cross-platform access?

Choosing the right protocol depends on your environment's constraints. Here's how they stack up in practice for mixed Linux-Windows deployments:

For teams operating in Nepal or similar regions with mixed infrastructure, Samba strikes the best balance. NFS performs better for pure Linux clusters, but the moment a Windows workstation needs access, the UID/GID mapping complexity outweighs the performance gain. If you're already running Active Directory, consider joining the Samba server to the domain using realm join for unified identity management—this eliminates duplicate user accounts and simplifies offboarding.

Why aren't my Samba shares accessible from Windows clients?

Troubleshooting Samba requires systematic elimination. Work through this checklist in order; skipping steps leads to chasing ghosts:

1. Verify service status: systemctl status smbd nmbd. Both must be active. If smbd fails to start, check journalctl -u smbd for config parse errors.
2. Test local connectivity: Run smbclient -L localhost -U% on the server itself. If this fails, the problem is configuration—not networking.
3. Check firewall rules: sudo ufw status verbose. Port 445/tcp must be allowed from the client's subnet. Don't forget that cloud VPC security groups add another layer—verify those too if hosting on AWS or Azure.
4. Validate user mapping: Confirm the user exists in Samba's database: pdbedit -L | grep username. System users without corresponding smbpasswd entries cannot authenticate.
5. Inspect filesystem permissions: ls -la /srv/samba/shared. The directory must be writable by the group specified in force group. Test with sudo -u username touch /srv/samba/shared/testfile to isolate POSIX issues from Samba issues.
6. Review logs with context: Set log level = 2 temporarily in [global], reproduce the issue, then check /var/log/samba/log.smbd. Reset to log level = 0 afterward to avoid disk fill.

If you're also managing databases on the same server, ensure Samba's file locks don't conflict with your database storage paths. I've seen teams accidentally place MySQL data directories inside Samba shares, causing corruption. Keep application data and shared files strictly separated—see MySQL performance tuning guidance for proper storage layout.

Implementing Samba: Share Files with Windows Securely in Production

Getting Samba functional takes an hour; making it audit-ready takes discipline. Treat your smb.conf as infrastructure code—version it in Git, review changes in pull requests, and deploy via Ansible or Terraform rather than manual edits. Document every share's purpose, authorized users, and retention policy. If you're preparing for compliance assessments, enable the full_audit VFS module to log all file operations to syslog, then forward those logs to your structured logging pipeline for centralized analysis.

Start with the minimal viable share, validate each security layer independently, and expand only after confirming the foundation holds. If you need help designing a compliant file-sharing architecture or auditing an existing Samba deployment, reach out directly—I regularly assist teams in Nepal and globally with securing cross-platform infrastructure.