When a user cannot access a Windows SMB share, the first instinct is often to change permissions. But the same symptom can come from DNS, network access, TCP 445, the SMB services, authentication or Share/NTFS permissions. That is why I troubleshoot SMB access in layers, from the network up to the permissions.
1. Verify the UNC path and DNS
Resolve-DnsName fileserver.contoso.com
ping fileserver.contoso.comfileserver.contoso.com is only an example; use your own server name. A failed ping alone does not prove the server is unreachable, because ICMP may be blocked. Check the DNS result separately and make sure the name resolves to the expected server.
2. Test TCP 445
Test-NetConnection fileserver.contoso.com -Port 445If TCP 445 fails, fix the firewall, network ACLs, routing or SMB access on the server side before you look at permissions. No permission change will help while the port is closed.
3. Confirm the share actually exists
Get-SmbShareOn the server, verify the expected share name and its path. A typo in the share name or a share that was removed returns system error 67 (“The network name cannot be found”), while error 53 (“The network path was not found”) points to name resolution or network reachability.
4. Check the SMB session
Get-SmbConnectionIf a connection is established, you can review the ServerName, ShareName and Dialect values. The dialect also tells you which SMB version was negotiated.
5. The credential and Kerberos layer
klist
whoami /groupsWrong or stale credentials, a different user context, or a Kerberos/SPN problem can all block access. Using an IP address in the UNC path changes how Kerberos behaves, so in normal use prefer the server name.
6. Share and NTFS permissions
For network access, evaluate the Share and NTFS layers together; the more restrictive one wins. Check the user’s group memberships, inheritance and the Effective Access result. For permission design, see my NTFS permissions and AGDLP guide (Turkish).
7. Server service and event logs
Get-Service LanmanServer
Get-SmbServerConfigurationMatch the System log and the SMBClient and SMBServer operational logs (Applications and Services Logs → Microsoft → Windows → SMBClient / SMBServer) against the time the error occurred.
8. If you get an SMB1 warning
If a legacy device is reported to require SMB1, do not enable the protocol permanently on modern clients. Follow my SMB1 legacy dependency troubleshooting steps (Turkish) instead.
Quick diagnostic order
- UNC path and DNS
- TCP 445
- Does the share exist?
- SMB session and dialect
- Credentials and Kerberos
- Share and NTFS permissions
- Server service and event logs
Conclusion
With SMB access problems, do not jump straight to changing ACLs because of an “Access Denied” or “Network path not found” message. First find out which layer the problem is in. Working in the order DNS → port → SMB → authentication → permissions avoids unnecessary changes.
