Windows Server SMB Port 445 Troubleshooting Guide

! Issue

Troubleshoot SMB file share connectivity by checking TCP 445, Windows Firewall, DNS, authentication and share permissions.

✓ Solution

Confirm TCP 445 is reachable first, then work through DNS, firewall, the SMB service and permissions in that order.

★ Recommendations

A cached bad credential in Windows Credential Manager will keep failing authentication even after the actual password or permission issue is fixed — check it before escalating.

From the client, use Test-NetConnection <server> -Port 445 to determine whether the SMB service is reachable.

Test TCP 445 directly

Isolate whether this is a network-layer problem before touching shares or permissions:

Test-NetConnection -ComputerName ServerName -Port 445

If this fails, don't move on to authentication or share checks yet — a blocked port produces the exact same "network path not found" error to the end user as a permissions problem, and troubleshooting authentication first is wasted effort until connectivity is confirmed.

Check DNS resolution

Confirm the server name resolves to the IP you expect:

Resolve-DnsName ServerName

A stale DNS record is a common cause after a server migration or IP change — clients connect successfully but to the wrong (old) host, and the share either doesn't exist there anymore or shows outdated content. Clear the client-side DNS cache (ipconfig /flushdns) before retesting if the record was recently corrected.

Check firewall rules on both sides

Confirm the built-in File and Printer Sharing (SMB-In) rule is enabled for the active network profile on the server:

Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" | Where-Object {$_.Enabled -eq 'True'}

Check any network firewall or NSG between client and server too — port 445 is frequently blocked outbound by default on corporate firewalls and almost always blocked across the public internet, since unrestricted SMB exposure is a well-known ransomware vector. If clients are remote, don't try to open 445 broadly; use a VPN so SMB traffic never crosses the open internet at all.

Confirm the SMB service and the share both exist

Check that the Server service (LanmanServer, which hosts SMB shares) is running, then confirm the specific share is actually published:

Get-Service LanmanServer
Get-SmbShare | Select-Object Name, Path, Description

A share removed during cleanup, or one that failed to recreate after a reboot due to a missing folder path, will show as simply "not found" to the client with no more specific error.

Check share and NTFS permissions separately

SMB access requires both the share-level permission and the underlying NTFS permission to allow access — the more restrictive of the two wins. Check both explicitly rather than assuming one implies the other:

Get-SmbShareAccess -Name "ShareName"
Get-Acl -Path "D:\Shares\ShareName" | Format-List

Also confirm which account the client is actually authenticating as — a client with a cached credential for a different account (visible in Windows Credential Manager under "Windows Credentials") will silently authenticate as the wrong user and fail permission checks that look correct for the intended account.

Validate the actual mapping

Test the raw UNC path before trusting a mapped drive letter, since a stale mapped drive can mask whether the underlying fix actually worked:

Test-Path \\ServerName\ShareName

If a mapped drive is still failing after the underlying issue is fixed, remove and remap it rather than assuming it will self-heal — cached authentication state on an existing mapped drive doesn't automatically refresh:

net use Z: /delete
net use Z: \\ServerName\ShareName /persistent:yes