Windows SMB share access investigation cheat sheet
Separate TCP reachability, client SMB connections, share permissions, filesystem ACLs and server-side sessions.
Windows SMB client and Windows file server with PowerShell SmbShare. Commands are explicitly split between client and server contexts.
Updated · Windows · 6 min read
| Command | What it does |
|---|---|
Test-NetConnection fs01.corp.example -Port 445 | Client: test the SMB TCP endpoint |
Get-SmbConnection | Select-Object ServerName,ShareName,UserName,Dialect | Client: inspect existing SMB connection identity |
Get-SmbShare -Name Projects | Select-Object Name,Path,Description | Server: identify the share and backing path |
Get-SmbShareAccess -Name Projects | Server: inspect share-level permissions |
Get-Acl -LiteralPath 'D:\Shares\Projects' | Format-List Owner,AccessToString | Server: inspect the backing directory ACL |
Get-SmbSession | Select-Object ClientComputerName,ClientUserName,NumOpens | Server: inspect current client sessions |
Walkthrough
Replace fs01.corp.example, Projects and D:\Shares\Projects. Run network/client checks on the affected client and share/ACL/session checks on the actual server with authorized read privileges.
Step 1: Client: test the SMB TCP endpoint
Test-NetConnection fs01.corp.example -Port 445
Check TcpTestSucceeded and the selected source address from the affected client. TCP success does not establish SMB authentication or file permissions. Name resolution failure, TCP refusal and TCP timeout require different follow-up checks.
Step 2: Client: inspect existing SMB connection identity
Get-SmbConnection | Select-Object ServerName,ShareName,UserName,Dialect
Compare server, share and user with the identity expected for the failing operation. Existing connections are context-dependent; run in the relevant user session. An empty list can mean no active SMB connection, not proof that the share is unavailable.
Step 3: Server: identify the share and backing path
Get-SmbShare -Name Projects | Select-Object Name,Path,Description
Run on the file server and verify the actual filesystem path. A DFS namespace or alias can lead to a different server than expected, so confirm the serving host before interpreting the share. Do not create a replacement share to make the lookup succeed.
Step 4: Server: inspect share-level permissions
Get-SmbShareAccess -Name Projects
Compare allow and deny entries with the affected account group membership. Share permissions are only one layer: filesystem ACLs, deny entries and the actual authenticated token also affect the result. Broad share access does not establish write access to files.
Step 5: Server: inspect the backing directory ACL
Get-Acl -LiteralPath 'D:\Shares\Projects' | Format-List Owner,AccessToString
Compare inherited and explicit entries on the actual failing path, not only the share root. This is an ACL listing rather than an effective-access calculation; nested group membership, deny entries and child permissions need separate evaluation.
Step 6: Server: inspect current client sessions
Get-SmbSession | Select-Object ClientComputerName,ClientUserName,NumOpens
Match the affected client and user at the incident time. A session can exist while a particular file operation is denied. Missing sessions can reflect a failure before session establishment, idle disconnects or a different serving node.
WORKED INCIDENT
Practical case: A user can browse a share but cannot save files
Fictional teaching scenario; observations are examples, not captured production output.
Situation
One user opens the Projects share but receives Access Denied when saving a document.
Investigation sequence
1. Client: inspect existing SMB connection identity
Get-SmbConnection | Select-Object ServerName,ShareName,UserName,DialectVerify which user identity the client SMB connection actually uses.
2. Server: identify the share and backing path
Get-SmbShare -Name Projects | Select-Object Name,Path,DescriptionConfirm the serving host and the filesystem path behind Projects.
3. Server: inspect share-level permissions
Get-SmbShareAccess -Name ProjectsInspect the share permissions. The fictional example grants the relevant group Change access.
4. Server: inspect the backing directory ACL
Get-Acl -LiteralPath 'D:\Shares\Projects' | Format-List Owner,AccessToStringInspect the actual failing directory. In this example its filesystem ACL grants that user group only read access.
Example findings
Illustrative findings: SMB connects as the intended user; share permissions allow changes; the target directory filesystem ACL allows read access only.
Interpret the findings
The filesystem permission layer is a supported blocker in this example. Do not replace it with broad Full Control; determine the intended business access and evaluate the complete effective token and ACL.
Verify the outcome
After the access owner approves a scoped permission correction, have the affected user create, edit and delete an approved test file in that directory. Recheck access without changing unrelated shares.
Escalation handoff
Provide client user context, serving node, exact directory and relevant ACL entries to the file-service/access owner. Avoid sharing file contents or full user inventories.