Effective SMB connection troubleshooting starts by identifying the failing stage: locating the server, reaching TCP 445, negotiating SMB, authenticating a session, connecting to the named share, or opening a file with the required permissions. Test one known server, share, account, and client at a time instead of changing credentials, firewall rules, and protocol settings together. To test an SMB connection quickly, check TCP 445 from the affected client first: a failed check points to the network path, while a passing check moves the search to sign-in, the share, or permissions.

Key Takeaways

First determine whether one client, one account, one share, or every client is affected.

Test the server name and IP separately, but do not treat an IP workaround as a permanent DNS fix.

“Access denied” can occur during authentication, share connection, or file authorization.

Do not enable SMB1, expose TCP 445 to the internet, or disable signing and encryption as generic fixes.

Preserve the exact error, timestamp, server, share path, account form, and comparison result.

For protocol background, read what SMB is. For broader checks that are not specific to file sharing, use the device and app troubleshooting guide. This guide assumes the client is on an authorized local network or a properly protected remote path.

Start SMB connection troubleshooting by measuring how wide the failure is

Do not begin by resetting the NAS or deleting every saved credential. Build a small comparison matrix first.

Comparison	Likely layer to investigate
One client fails; another works with the same account and share	Client name resolution, firewall, credentials, policy, or SMB capability
One account fails on several clients; another account works	Account status, password, group membership, or authorization
One share fails; another share on the server works	Share name, share permission, file permission, encryption requirement, or volume state
Every client fails to reach every share	Server service, network path, TCP 445, maintenance, or storage state
Files open but copying is slow	Performance path, not connection establishment

Record the exact path, such as \\server\share, the client and server operating systems, the time, and the visible error. Confirm that you are authorized to use the account and share. If the device is managed by an employer or school, stop before changing firewall, credential, signing, encryption, or local security policy.

Check the server dashboard locally if you own it. Confirm that the volume and share are online, the file service is enabled, and the server is not updating, restarting, degraded, or out of space. A storage problem can surface as a connection or file error even when the network is healthy.

Can the client find and reach the SMB server?

Separate discovery, name resolution, and transport.

Confirm that client and server are on the intended network. A guest Wi-Fi network may intentionally block local devices from each other.
Verify the server name and the exact share name from a trusted source. Do not guess paths from an old shortcut.
Compare the server name with its current local IP address. An IP test can isolate name resolution, but it is not a durable replacement for correct DNS or local discovery.
Confirm that the SMB server service is running and listening according to its official administration interface.
Test whether the client's network and firewall permit TCP 445 to that authorized server.
Compare another known-good client on the same network.

Microsoft's advanced SMB guidance says to examine TCP/IP before concluding that SMB itself is broken. A failed TCP handshake can indicate a firewall block or stopped server service, while retransmissions and a shrinking receive window can point to network or storage delay.［1］

Do not open TCP 445 on the router to make a local test pass. If you are away from home, use the protected path described in the safer remote NAS access guide. Public exposure changes the security boundary and is not a connection repair.

If the IP works but the name fails, preserve that result. Check the correct DNS suffix, local DNS record, device name, and cached old address through supported tools. Avoid editing a hosts file as the first permanent solution; it can hide address changes and create a second source of truth.

How do you test an SMB connection and TCP 445?

On Windows, run Test-NetConnection -ComputerName <server> -CommonTCPPort SMB in PowerShell on the affected client; -Port 445 runs the same TCP test. TcpTestSucceeded : True means a TCP connection to port 445 was established, not that negotiation, sign-in, or the share will succeed.［2］ Run it once with the server name and once with the IP address to compare name resolution and transport in one step.

After a share connects, run Get-SmbConnection to list each connection's server, share, user name, and negotiated SMB dialect.［3］ If the cmdlet itself reports access denied, reopen PowerShell as administrator; that error concerns the local query, not the share.

Result	What it tells you
`TcpTestSucceeded` is False	Stay with the network checks: address, firewall, routing, or a stopped service
`TcpTestSucceeded` is True, but the share fails	Transport works; map the error to a later stage
`Get-SmbConnection` shows an unexpected user	The session uses another identity; go to the credential checks
`Get-SmbConnection` shows an old dialect	Check negotiation and current SMB versions on both sides

Which SMB connection stage is failing?

An SMB connection is not one action. Microsoft describes negotiation, session setup, and tree connect as distinct stages.［4］ Mapping the error to the stage prevents unrelated changes.

Stage	What it establishes	Typical evidence
TCP connection	Network path to port 445	Timeout, refusal, firewall or routing result
Negotiate	Compatible SMB dialect and capabilities	Protocol or security-capability error
Session setup	User identity and session security	Credential prompt, logon failure, disabled account
Tree connect	Access to a named share	Share not found, access denied, encryption requirement
File operation	Permission for a folder or file action	Can list but cannot open, create, rename, or delete

If negotiation fails, confirm current client and server versions and supported SMB capabilities. Do not enable SMB1. An old server that cannot meet current security requirements should be upgraded, isolated, or replaced rather than weakening every client.

If session setup fails, move to the identity checks; if you connect through a DNS alias, also confirm that the server has a service principal name (SPN) for that alias, because Kerberos requests a ticket for it during session setup. If tree connect fails, verify the exact share name and share-level rules. If only a file action fails, keep the successful SMB session and inspect file authorization instead of restarting network diagnosis.

How do you resolve authentication and credential loops?

Use the account form expected by the server. A local NAS account, a Windows local account, a domain account, and a cloud sign-in are not interchangeable merely because their display names match.

Confirm the account exists on the intended SMB server or identity directory.
Check whether it is disabled, locked, expired, or required to change its password.
Enter the documented account form once. Do not cycle through random prefixes and domains.
Check the client for an existing session to the same server under a different identity.
Close open files and disconnect only the relevant server session through supported controls.
Remove a saved credential only when you know its owner and can restore it.
Retry with a non-sensitive test share.

A client may resist using two identities against the same server at the same time. That does not justify deleting the entire credential store. Preserve credentials for unrelated servers, business apps, and scheduled jobs.

Repeated prompts can also appear when authentication succeeds but the requested share denies the account. Check the server log at the same timestamp to determine whether the failure was logon, tree connect, or a later file action. Do not infer the stage from the wording of a single client dialog.

Why does SMB say access denied when the password is correct?

A correct password proves identity, not authorization. Access can be restricted by both share permission and the underlying file or folder permission. The effective result is the more restrictive combination, plus any server policy or encryption requirement.

Check in this order:

Confirm the exact share, not an administrative or similarly named share.
Review direct user and group membership on the server.
Review share permissions for the required read or write action.
Review file-system permissions and inheritance on the target folder.
Test a newly created harmless folder inside the approved share.
Confirm that the volume is writable and not full, read-only, degraded, or locked.
Check whether the share requires SMB encryption or a capability the client lacks.

Do not grant Everyone full control as a diagnostic shortcut. A temporary test account should receive only the narrow permission needed for one test folder, then be removed. If an inherited deny or organization policy is involved, have the owner correct it rather than layering broad allow rules over an unclear design.

If listing works but creating fails, compare the requested action. If creating works but renaming or deleting fails, inspect ownership, inheritance, application locks, retention, snapshots, and security software. These are file-operation questions after the connection has succeeded.

Should you change SMB signing or encryption?

Not as a generic connection fix. Windows 11 version 24H2 Pro, Enterprise, and Education require outbound and inbound SMB signing, Windows Server 2025 requires outbound signing, and Microsoft does not recommend disabling signing as a workaround for third-party servers because it protects against tampering, spoofing, and relay attacks.［5］

A third-party SMB server that does not allow signing may fail during negotiation or session setup, for example with STATUS_INVALID_SIGNATURE. Confirm the server firmware, configuration, and documented capability. Update or replace an unsupported server instead of lowering the security policy across all clients.

Encryption requirements can also produce access-denied behavior when a client does not support the required SMB version. Treat that as a capability mismatch. Do not turn off encryption on a sensitive share without a documented risk decision and an alternative protected path.

Keep these settings distinct:

SMB signing provides message integrity and authentication protection.
SMB encryption adds confidentiality for SMB data in transit.
Transport reachability only proves that TCP 445 can be reached.
Share and file permissions decide what an authenticated identity may do.

Changing one layer cannot repair a wrong share name or disabled account.

What evidence should you collect before escalation?

If the basic matrix does not isolate the problem, collect evidence without exposing credentials or file contents.

Client and server model and operating-system version.
Exact server and share names, with sensitive path components redacted if necessary.
Client local IP, server local IP, and network type.
Exact error and timestamp.
Whether name and IP tests differ.
Whether TCP 445 is reachable on the authorized network.
Whether negotiate, session setup, tree connect, or file operation failed.
Known-good client, account, and share comparison results.
Relevant client and server event-log entries.

Microsoft recommends collecting SMB client and server logs and, for advanced cases, a packet capture close to the failing operation. Packet captures can contain names, paths, addresses, and authentication metadata; collect and share them only through an approved support process.

If one file server is merely slow after it connects, switch to the NAS transfer performance guide. Repeating authentication changes will not diagnose throughput.

FAQ

Why can I reach the NAS by IP but not by name?

The transport path is probably working while name resolution or discovery is wrong or stale. Fix the authoritative local DNS or supported discovery path instead of keeping a hard-coded IP workaround that may break when the address changes.

Does SMB access denied mean my password is wrong?

Not always. It can mean logon failure, no permission to connect to the share, insufficient file permission, or an unmet encryption requirement. Match the server log and error to the connection stage.

Should I enable SMB1 for an old NAS?

No. SMB1 lacks protections expected by current systems. Update the server, use a supported current SMB implementation, isolate and migrate the data, or replace unsupported hardware.

Should I clear all saved credentials?

No. Remove only the credential for the identified server when you understand its owner and recovery path. Clearing everything can disrupt unrelated shares, applications, and scheduled tasks.

Can two accounts connect to the same SMB server at once?

Some clients restrict simultaneous sessions to the same server under different identities. Close only the relevant open files and server session, then reconnect with the intended account rather than clearing every network credential.

Is port 445 blocked if the connection times out?

It is one possibility, along with routing, server downtime, an incorrect address, or a stopped service. Compare an authorized known-good client and inspect both network and server evidence before changing a firewall.

Should I disable SMB signing to connect to a NAS?

No as a routine fix. Update and configure the NAS to support current security requirements. Disabling signing reduces protection against relay, spoofing, and tampering and can violate managed policy.

Why can I list files but not edit them?

The SMB session and share connection succeeded, but the requested file operation is not authorized or the volume is not writable. Check file permissions, ownership, locks, retention, free space, and volume health. AethoVPN can affect a remote SMB network route, but it cannot grant write permission, remove a file lock, or repair a read-only volume.

Related guides

Sources

Microsoft, “Advanced Troubleshooting Server Message Block” — https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/troubleshooting-smb
Microsoft, “Test-NetConnection” — https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection
Microsoft, “Get-SmbConnection” — https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbconnection
Microsoft, “Negotiate, Session Setup, and Tree Connect Failures” — https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/negotiate-session-setup-tree-connect-fails
Microsoft, “Control SMB Signing Behavior” — https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-signing

Sources checked 4 October 2026.

SMB Connection Troubleshooting Guide