Diagnosing and Fixing Windows Firewall/Network Profile Issues Blocking SMB

A device on the network (scanner, printer, external system) can’t reach a Windows machine’s shared folder over SMB (port 445). The credentials are correct, the share exists, but the inbound connection silently fails. Most often, the Windows machine’s network profile is set to Public instead of Private, which disables the SMB-In firewall rule by default.

This guide walks through rapid diagnosis via PowerShell and shows how to repair it efficiently.

One-Pass Diagnostic (run this first)

Copy and paste this entire script to get a complete picture:

Write-Host "=== SMB Connectivity Diagnosis ===" -ForegroundColor Cyan
Write-Host "`n1. Network Profile" -ForegroundColor Yellow
Get-NetConnectionProfile | Select InterfaceAlias, NetworkCategory

Write-Host "`n2. SMB Shares on this machine" -ForegroundColor Yellow
Get-SmbShare | Select Name, Path, Description

Write-Host "`n3. SMB-In Firewall Rule State" -ForegroundColor Yellow
Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" |
    Where-Object { $_.DisplayName -eq "File and Printer Sharing (SMB-In)" } |
    Select DisplayName, Enabled, Profile

Write-Host "`n4. Wi-Fi Signal and Driver (if applicable)" -ForegroundColor Yellow
netsh wlan show interfaces | Select-String "Signal|RSSI|Channel|DriverVersion" -ErrorAction SilentlyContinue
Get-NetAdapter -Name "Wi-Fi" -ErrorAction SilentlyContinue | Select Name, DriverVersion, DriverDate

Write-Host "`n5. Known Network Profiles (check for duplicates)" -ForegroundColor Yellow
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles" -ErrorAction SilentlyContinue |
    ForEach-Object {
        $p = Get-ItemProperty $_.PSPath
        [PSCustomObject]@{
            Name     = $p.ProfileName
            Category = switch ($p.Category) {0{'Public'}1{'Private'}2{'Domain'}}
        }
    } | Sort-Object Name | Format-Table -AutoSize

This single command will tell you your network profile, active shares, firewall rule state, Wi-Fi quality, driver version, and any duplicate network profiles. Run it and look at the output — most issues are visible immediately.

Quick Reference: Common Repairs

Profile is Public, needs to be Private:

Set-NetConnectionProfile -InterfaceAlias "Wi-Fi" -NetworkCategory Private

SMB-In is disabled for Public, need to enable it (scoped to LocalSubnet):

Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" | Where-Object { $_.DisplayName -eq "File and Printer Sharing (SMB-In)" -and $_.Profile -match "Public" } | Set-NetFirewallRule -Enabled True -RemoteAddress LocalSubnet

Test auth from a remote machine (the real test):

net use \\192.168.1.188\SCANS /user:Scanning Scanning12
net use
net use \\192.168.1.188\SCANS /delete

Disable Wi-Fi power management (if the adapter is powering down):

Disable-NetAdapterPowerManagement -Name "Wi-Fi"

Verify the fix worked:

Get-NetConnectionProfile | Select InterfaceAlias, NetworkCategory
Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" | Where-Object { $_.DisplayName -eq "File and Printer Sharing (SMB-In)" } | Select DisplayName, Enabled, Profile

Quick Triage (60 seconds)

Start here to determine if this is a firewall/profile problem or something else.

1. Confirm the share exists and the basic path works

List all SMB shares on this machine:

Get-SmbShare | Select Name, Path, Description

What to look for:

Is your target share listed? (e.g., SCANS, C$, FileShare)
What local path does it point to? (e.g., C:\SCANS)

If not found: The share doesn’t exist. Create it first before proceeding. This diagnostic won’t help a missing share.

2. Test credentials against the share from a remote machine

If possible, run this from another machine on the same network (not from the target itself). Replace 192.168.1.188 with the target IP and “SCANS” with your share name:

net use \\192.168.1.188\SCANS /user:Scanning Scanning12
net use
net use \\192.168.1.188\SCANS /delete

What to look for:

“The command completed successfully” → Auth works. The problem is firewall/inbound rules on the target.
Error 1326 → Bad username or password. Fix credentials and re-test.
Error 53 / 64 → Network unreachable or path not found. Check IP, routing, and share name spelling.
Error 5 → Auth worked, but permission denied. Check share NTFS permissions.

Key point: If net use succeeds from another machine but the remote device (scanner) still can’t connect, the issue is inbound firewall rules on your target machine — proceed to step 3 below.

Diagnosis: Network Profile and Firewall Rules

If you’ve confirmed credentials and share existence, the culprit is almost always the network profile category (Public vs Private) and the SMB-In inbound firewall rule.

3. Check the NIC’s network profile

Get-NetConnectionProfile | Select InterfaceAlias, NetworkCategory

What to look for:

NetworkCategory: Public → This is the problem. SMB-In is disabled for Public by default.
NetworkCategory: Private → Correct for a trusted LAN. Firewall should allow SMB. Proceed to step 4.
NetworkCategory: Domain → Domain-joined machine. Profile rules apply per-domain policy.

If Public: Note the InterfaceAlias (usually Wi-Fi or Ethernet). You’ll need it for the fix.

4. Check the SMB-In firewall rule state

Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" |
    Where-Object { $_.Direction -eq "Inbound" } |
    Select DisplayName, Enabled, Profile, Action

What to look for:

Find the row File and Printer Sharing (SMB-In)
Check the Enabled and Profile columns for your NIC’s profile (Public, Private, or Domain)
If Enabled: False for the Public/Private profile your NIC is on, SMB-In is blocked — that’s your answer

Example of disabled SMB-In on Public:

DisplayName                        Enabled  Profile  Action
-----------                        -------  -------  ------
File and Printer Sharing (SMB-In)   False    Public   Allow
File and Printer Sharing (SMB-In)    True    Private  Allow

If your NIC is on Public and SMB-In shows False for Public, you’ve found the root cause.

5. Verify the target machine can be reached on port 445

Run this from the remote machine trying to connect (scanner, printer, another computer):

Test-NetConnection -ComputerName 192.168.1.188 -Port 445

What to look for:

TcpTestSucceeded: True → Port is reachable. Confirms network connectivity and the SMB port is listening.
TcpTestSucceeded: False → Port blocked. Either the firewall rule is denying (step 4), the machine is offline, or network routing is broken.

Additional Context: Check for duplicate profiles and reconnect churn

If you’re seeing intermittent issues or the profile keeps changing, check for accumulated duplicate network profiles:

Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles" |
    ForEach-Object {
        $p = Get-ItemProperty $_.PSPath
        [PSCustomObject]@{
            Name                = $p.ProfileName
            Category            = switch ($p.Category) {0{'Public'}1{'Private'}2{'Domain'}}
            DateCreated         = [DateTime]::FromFileTime([UInt64]$p.DateCreated[0])
            DateLastConnected   = [DateTime]::FromFileTime([UInt64]$p.DateLastConnected[0])
        }
    } | Format-Table -AutoSize

What to look for:

Multiple entries for the same network name (e.g., “Office WiFi”, “Office WiFi 2”, “Office WiFi 3”)
Duplicate profiles = Windows re-identified the network multiple times, creating a new profile each time (usually due to Wi-Fi reconnects)
The most recent DateLastConnected is the one currently in use
If duplicates are classified Public, each one is a potential liability

Why this matters: Frequent Wi-Fi disconnects can cause Windows to create new profiles that default to Public. Even if you fix the current one to Private, a re-identification creates a new Public profile next time.

Repair: Setting the Profile and Enabling SMB-In

Once you’ve identified the issue (usually Public profile + SMB-In disabled), fix it in order of least to most invasive.

Fix 1: Change the profile to Private (recommended)

Get the exact interface alias first:

Get-NetConnectionProfile | Select InterfaceAlias, NetworkCategory

Set it to Private (replace “Wi-Fi” with your InterfaceAlias if different):

Set-NetConnectionProfile -InterfaceAlias "Wi-Fi" -NetworkCategory Private

Verify the change:

Get-NetConnectionProfile | Select InterfaceAlias, NetworkCategory

Expected result:

InterfaceAlias  NetworkCategory
-----------     ---------------
Wi-Fi           Private

This immediately activates all the inbound rules that are already enabled for Private, including SMB-In. For a machine on a trusted internal LAN, Private is the semantically correct setting.

Test: From the remote machine, try the connection again:

net use \\192.168.1.188\SCANS /user:Scanning Scanning12

Fix 2: Enable SMB-In for the Public profile (if the profile must stay Public)

If for some reason the profile must remain Public, explicitly enable the SMB-In rule for Public and scope it to your local subnet:

Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" |
    Where-Object { $_.DisplayName -eq "File and Printer Sharing (SMB-In)" -and $_.Profile -match "Public" } |
    Set-NetFirewallRule -Enabled True -RemoteAddress LocalSubnet

Verify:

Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" |
    Where-Object { $_.DisplayName -eq "File and Printer Sharing (SMB-In)" } |
    Select DisplayName, Enabled, Profile, @{N='RemoteAddress';E={($_ | Get-NetFirewallAddressFilter).RemoteAddress}}

Expected result:

DisplayName                       Enabled  Profile  RemoteAddress
-----------                       -------  -------  ---------
File and Printer Sharing (SMB-In)   True    Public   LocalSubnet
File and Printer Sharing (SMB-In)   True    Private  LocalSubnet

The LocalSubnet scope limits SMB to local-segment IPs only, preventing exposure if the device lands on an untrusted network.

Preventive Diagnosis: Identify root causes of profile instability

If this issue recurs, the problem is usually network profile churn — Windows re-identifying the network and creating new profiles. Investigate these:

Check Wi-Fi signal and AP quality

netsh wlan show interfaces

Look for:

Signal: 70% or higher → Good. Low signal is a common cause of reconnects.
Channel → Check if it’s congested (2.4 GHz channels 1/6/11 are standard; 5 GHz has more space).
RSSI: -60 dBm or better → Solid. Anything worse is weak.

If signal is poor: The problem is RF. Move the access point or relocate the device closer.

Check for driver issues

Get-NetAdapter -Name "Wi-Fi" | Select Name, DriverVersion, DriverDate

Look for:

DriverDate more than a year old? Update the driver from the NIC vendor (Intel, Qualcomm, Realtek, etc.) directly — don’t rely on Windows Update.

Check power management (on laptops especially)

Get-NetAdapterPowerManagement -Name "Wi-Fi"

Look for:

SelectiveSuspend: Enabled or DeviceSleepOnDisconnect: Enabled → These can cause disconnects to save power. Disable them on a desktop or stationary device.

If these are enabled, disable them:

Disable-NetAdapterPowerManagement -Name "Wi-Fi"

Check for duplicate network profiles (indicates reconnect churn)

See the registry query in the “Additional Context” section above. Multiple profiles for the same network name is a red flag for instability.

If duplicates exist: Back up the registry key, then remove stale duplicates (keep only the most recently connected one). Each reconnect event creates a new candidate for being classified Public, so cleaning them up reduces surface area.

Complete diagnostic script (one-liner)

Here’s a single script that runs all the key diagnostics and formats them for quick review:

Write-Host "=== SMB Connectivity Diagnosis ===" -ForegroundColor Cyan
Write-Host "`n1. Network Profile" -ForegroundColor Yellow
Get-NetConnectionProfile | Select InterfaceAlias, NetworkCategory

Write-Host "`n2. SMB Shares on this machine" -ForegroundColor Yellow
Get-SmbShare | Select Name, Path, Description

Write-Host "`n3. SMB-In Firewall Rule State" -ForegroundColor Yellow
Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" |
    Where-Object { $_.DisplayName -eq "File and Printer Sharing (SMB-In)" } |
    Select DisplayName, Enabled, Profile

Write-Host "`n4. Wi-Fi Signal and Driver (if applicable)" -ForegroundColor Yellow
netsh wlan show interfaces | Select-String "Signal|RSSI|Channel|DriverVersion" -ErrorAction SilentlyContinue
Get-NetAdapter -Name "Wi-Fi" -ErrorAction SilentlyContinue | Select Name, DriverVersion, DriverDate

Write-Host "`n5. Known Network Profiles (check for duplicates)" -ForegroundColor Yellow
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles" -ErrorAction SilentlyContinue |
    ForEach-Object {
        $p = Get-ItemProperty $_.PSPath
        [PSCustomObject]@{
            Name     = $p.ProfileName
            Category = switch ($p.Category) {0{'Public'}1{'Private'}2{'Domain'}}
        }
    } | Sort-Object Name | Format-Table -AutoSize

Run this when a connectivity issue comes in, and it gives you a full picture in one pass.

Troubleshooting matrix

Symptom	Diagnosis Command	Likely Cause	Fix
Remote device can’t connect, no error code	`Get-NetConnectionProfile`	Network profile is Public	Set to Private
Remote device gets generic “connection error”	Check SMB-In rule with `Get-NetFirewallRule`	SMB-In disabled on active profile	Enable SMB-In or switch to Private
Port 445 shows closed from remote	`Test-NetConnection -Port 445`	Firewall blocking or service not listening	Enable rule, or `Test-NetConnection localhost 445` to confirm SMB is up
Auth succeeds locally but fails remotely	`net use` from remote machine	Likely a firewall rule keying off profile, not share/auth	Confirm profile and SMB-In rule state
Problem happens intermittently	`Get-ChildItem .../NetworkList/Profiles`	Duplicate profiles from Wi-Fi reconnects; newer profile is Public	Clean duplicates; investigate RF stability
Problem returns weeks later	`netsh wlan show interfaces` + driver check	Unstable Wi-Fi or driver issue causing reconnects	Update driver, optimize Wi-Fi channel/placement, or move to wired

Quick reference: Common PowerShell repairs

Profile is Public, needs to be Private:

Set-NetConnectionProfile -InterfaceAlias "Wi-Fi" -NetworkCategory Private

SMB-In is disabled for Public, need to enable it:

Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" |
    Where-Object { $_.DisplayName -eq "File and Printer Sharing (SMB-In)" -and $_.Profile -match "Public" } |
    Set-NetFirewallRule -Enabled True -RemoteAddress LocalSubnet

Test auth from remote (safest test):

net use \\<target-ip>\<share-name> /user:<username> <password>
net use \\<target-ip>\<share-name> /delete

Disable Wi-Fi power management (if adapter is powering down):

Disable-NetAdapterPowerManagement -Name "Wi-Fi"

When to escalate

If after these steps the issue persists, check:

Third-party firewall/endpoint protection (Sophos, SentinelOne, ZeroTrust) — these can override Windows Firewall. Check their console for 445 rules.
Network/VLAN isolation — confirm both machines are on the same network segment (DHCP scope, VLAN, or subnet).
SMB protocol version mismatch — older devices may only speak SMBv1, which is disabled on modern Windows for security. Check device firmware.
DNS/hostname resolution — if the remote device is resolving a hostname instead of an IP, confirm it’s reaching the right target.

Diagnosing Scanning Issues

Diagnosing and Fixing Windows Firewall/Network Profile Issues Blocking SMB

One-Pass Diagnostic (run this first)

Quick Reference: Common Repairs

Quick Triage (60 seconds)

1. Confirm the share exists and the basic path works

2. Test credentials against the share from a remote machine

Diagnosis: Network Profile and Firewall Rules

3. Check the NIC’s network profile

4. Check the SMB-In firewall rule state

5. Verify the target machine can be reached on port 445

Additional Context: Check for duplicate profiles and reconnect churn

Repair: Setting the Profile and Enabling SMB-In

Fix 1: Change the profile to Private (recommended)

Fix 2: Enable SMB-In for the Public profile (if the profile must stay Public)

Preventive Diagnosis: Identify root causes of profile instability

Check Wi-Fi signal and AP quality

Check for driver issues

Check power management (on laptops especially)

Check for duplicate network profiles (indicates reconnect churn)

Complete diagnostic script (one-liner)

Troubleshooting matrix

Quick reference: Common PowerShell repairs

When to escalate