SMB port guide: file sharing on port 445

SMB lets clients browse shares, read and write files, lock files, use printers, and access named pipes over the network. A client connects to the SMB server, negotiates the SMB dialect, authenticates with local, domain, or directory-backed credentials, and then requests access to a specific share.

Modern deployments should use SMB 2 or SMB 3. SMB 1 is obsolete and should be disabled unless a tightly isolated legacy dependency truly requires it. SMB 3 can support signing, encryption, multichannel performance, and better resilience, but those features still depend on correct server and client policy.

SMB is the protocol. Samba is an open-source implementation that lets Linux and Unix-like systems provide SMB file shares and integrate with Windows networks. On Windows, SMB is built into the operating system and exposed through File and Printer Sharing features.

Port 445 is direct-hosted SMB and is the main port to check for modern file sharing. Older NetBIOS-based SMB can involve UDP 137, UDP 138, and TCP 139. Those legacy ports are different from direct SMB on 445, and they should normally remain closed unless you have a specific older network requirement.

In most cases, no. SMB should stay on private networks, VPNs, site-to-site tunnels, zero-trust access paths, or tightly scoped source-IP allowlists. Public SMB exposure invites password spraying, share enumeration, ransomware staging, and exploitation of outdated systems.

If a remote user needs file access, prefer a VPN, managed file-transfer service, cloud file gateway, private endpoint, or web-based document platform. If an external partner must reach SMB, restrict the source network, require strong identity controls, monitor every connection, and avoid broad write permissions.

Before you allow TCP 445, confirm that a real SMB service is listening and that the shares, users, groups, and permissions match the intended workflow. Decide whether guest access is disabled, whether SMB signing or encryption is required, and whether older dialects such as SMB 1 are blocked.

A port checker can tell you whether TCP 445 is reachable from outside the network, but it cannot prove that a user can access a share safely. Use SMB client tests and server logs to validate authentication, share-level permissions, NTFS or filesystem ACLs, and audit policy.

On Windows Server or Windows Pro, enable File and Printer Sharing or the File Server role, create the share, set share permissions and filesystem ACLs, and allow inbound TCP 445 in Windows Defender Firewall. Domain environments should use groups instead of assigning permissions to individual users.

On Linux, install and configure Samba, define shares in smb.conf, create or map users, and allow TCP 445 through ufw, firewalld, nftables, or your cloud security group. For mixed environments, confirm name resolution and authentication integration before exposing the share to users.

On NAS appliances, enable SMB only for the networks that need it, disable guest shares unless they are intentional, and keep firmware current. Many NAS security incidents come from internet-exposed management interfaces and file-sharing services that were never meant to be public.

Start with an external port check against the hostname or IP address and port 445. If the result is open, a remote client can reach the SMB listener. Then test the actual share with a Windows UNC path such as \\server\share, smbclient on Linux, or a file manager that supports SMB.

On the server, confirm the listener with PowerShell, netstat, ss, or your NAS status page. If the port is open but share access fails, inspect credentials, domain trust, share permissions, filesystem ACLs, SMB dialect policy, signing requirements, and server event logs.

If port 445 is closed, the SMB service may be disabled, blocked by the host firewall, bound only to a private interface, or hidden behind a VPN path. If the connection times out, a router, cloud firewall, ISP, corporate egress policy, or source-IP allowlist may be dropping the traffic.

If port 445 is open but users cannot access a share, check the exact share name, username format, domain membership, clock sync, password state, NTFS or POSIX permissions, guest restrictions, and SMB signing or encryption policy. Many SMB failures are permission or identity issues rather than port issues.

Keep SMB off the public internet whenever possible. Disable SMB 1, require strong authentication, remove guest access, apply least-privilege permissions, and patch Windows, Samba, and NAS firmware quickly. For sensitive shares, require SMB signing or encryption where performance and client support allow it.

Back up shared data, test restores, log access to sensitive folders, and alert on unusual write volume, failed logins, or access from unexpected networks. If SMB must cross sites, carry it over a VPN, private circuit, or zero-trust access layer instead of raw internet exposure.