Network Share Troubleshooting Checklist for IT ...

A user says, “the shared drive is down.” That can mean a dozen different things: the drive letter vanished, the server name will not resolve, the VPN is not connected, their password changed, the share exists but permissions changed, or the file they need is locked by someone else.

The fastest way to troubleshoot a network share is to separate three things early: path, identity, and permission. Can the machine reach the file server? Is the user authenticating with the right account? Does that account have access to the share and the NTFS folder behind it?

Use this checklist when a mapped drive, SMB share, or shared folder stops working and you need to gather useful evidence before blaming “the network.”

Quick triage: ask these first

Start with scope. Do not remap drives or reset permissions until you know how big the problem is.

Question	Why it matters
Is it one user, one team, or everyone?	One user points to credentials, profile, group membership, or device state. Everyone points to server, DNS, network, or storage.
Is it one share or all shares?	One share points to permissions, share path, or server-side changes. All shares points to network, VPN, DNS, or account auth.
Does the UNC path work?	`\\server\share` is more useful than “my Z drive disappeared.”
Is the user on VPN, office Wi-Fi, wired LAN, or remote desktop?	Network path changes the likely cause.
What changed today?	Password change, new laptop, office move, VPN update, group change, or file server maintenance are common clues.

If you only get one sentence from the user, ask for the exact error message. “Access denied” and “network path not found” are completely different problems.

Step 1: confirm the exact path

Mapped drive letters are convenient for users and terrible for troubleshooting. Before you chase the drive letter, get the real path.

On Windows, check:

net use

Look for the drive letter and UNC path, such as:

Z:  \\fileserver01\Accounting

Then test the UNC path directly in File Explorer or Run:

\\fileserver01\Accounting

If the UNC path works but the drive letter does not, you probably have a mapping issue, stale credential, or logon script/GPO problem. If the UNC path fails too, keep going.

For related support flow, the VPN troubleshooting checklist is useful when the share only fails for remote users.

Step 2: read the error before fixing anything

Do not paraphrase. Copy the actual error into the ticket.

Common patterns:

“The network path was not found”: DNS, network route, server offline, VPN, firewall, or wrong path.
“Access is denied”: permissions, group membership, wrong account, or explicit deny.
“The local device name is already in use”: stale mapped drive, disconnected session, or drive-letter conflict.
Credential prompt keeps returning: bad saved credentials, password change, account lockout, or auth policy.
Share opens but a folder is missing: NTFS permissions, access-based enumeration, or the user is in the wrong group.

This is where a lot of tickets go sideways. “Shared drive broken” is not an error. It is a symptom.

Step 3: check basic network reachability

Test the server name and network path from the affected machine.

ping fileserver01
nslookup fileserver01
Test-NetConnection fileserver01 -Port 445

What you are looking for:

Does the server name resolve to an IP address?
Is the IP address expected for that site or data center?
Can the machine reach TCP port 445 for SMB?
Does the same test work from a known-good machine?

If name resolution fails but the server is online, check DNS suffix/search order, VPN DNS settings, or whether the user is on the wrong network. If port 445 fails only over VPN, do not waste time rebuilding the mapped drive. Follow the network path.

For fundamentals that show up in real tickets, the Network+ subnetting practice questions connect the exam version of networking to the support version of networking.

Step 4: compare with a known-good user and machine

A clean comparison saves time.

Test these four combinations if possible:

Affected user on affected machine.
Affected user on known-good machine.
Known-good user on affected machine.
Known-good user on known-good machine.

You do not always need all four, but the pattern tells you where to look.

Result	Likely area
Affected user fails everywhere	Account, group membership, permissions, password, or lockout.
Anyone fails on affected machine	Device, network config, cached credentials, local policy, or VPN client.
Everyone fails everywhere	Server, share, DNS, firewall, storage, or outage.
Only one share fails	Share/NTFS permissions, path, or server-side change.

If the user recently changed their password and the account keeps locking, use the account lockout troubleshooting checklist before resetting the password again and calling it fixed.

Step 5: clear stale mappings carefully

If the UNC path works but the mapped drive is broken, remove the stale mapping and recreate it.

net use Z: /delete
net use Z: \\fileserver01\Accounting /persistent:yes

If Windows says the device name is already in use but File Explorer does not show it, list all mappings:

net use

Also check whether the drive is created by Group Policy, a login script, or an endpoint management tool. If IT keeps remapping a drive manually while GPO keeps applying the old path, the ticket will come back tomorrow. Ask how the mapping is supposed to be delivered.

Step 6: check credentials and saved passwords

Network shares can fail because Windows is sending credentials the user forgot existed.

Check Credential Manager for saved entries tied to the file server, old domain names, or old passwords. Be careful here: do not delete every saved credential on the machine just because one share failed. Remove only entries related to the file server or old path.

Also confirm the user is signed in with the expected domain account. This matters on shared machines, Azure AD joined devices, remote desktop hosts, and laptops that have been passed between employees.

If the issue smells like Active Directory group membership, make sure you know which group should grant access. The Active Directory tutorial for beginners is a good primer if you are still learning how users, groups, and permissions fit together.

Windows file access usually has two permission layers:

Share permissions on the network share.
NTFS permissions on the folder and files.

The effective access is the more restrictive result of the two. A user can have access at the share level and still be blocked by NTFS permissions underneath.

When escalating, include:

The exact user account.
The exact UNC path.
The group that should grant access.
Whether peers in the same role can open the same folder.
Screenshot or text of the exact error.

Do not request “give them access to the shared drive” if the share contains multiple departments. Ask for the specific folder and business owner approval if required.

Step 8: document before escalating

A good escalation note should make the next tech faster, not force them to restart the ticket.

Use this format:

Issue: User cannot access \\fileserver01\Accounting. Error: "Access is denied."
Scope: One user affected. Two teammates can access the same path from their laptops.
Network: User can resolve fileserver01 and Test-NetConnection to port 445 succeeds.
Mapping: Z: points to the correct UNC path. UNC path fails the same way.
Identity: User signed into domain account j.smith. Password changed yesterday. No current lockout seen.
Comparison: Known-good user can access share on affected laptop.
Likely area: User permission/group membership or NTFS access to Accounting folder.
Request: Please verify Accounting share/NTFS permissions and required AD group membership for j.smith.

That is much better than “drive broken, please advise.”

Common mistakes to avoid

Remapping the drive before testing the UNC path.
Ignoring the exact error message.
Assuming every share problem is permissions.
Testing only on VPN and never comparing on a known-good network.
Resetting the password repeatedly without checking saved credentials or account lockout sources.
Asking server admins for broad access instead of a specific path and business justification.
Closing the ticket after a one-time reconnect without explaining the likely cause.

FAQ

The drive letter is just a convenience mapping. The underlying UNC path can work even when the mapping is stale, disconnected, blocked by policy, or using old credentials.

Should I use the server name or IP address to test?

Use the server name first because that is what users and mappings normally use. Testing the IP can help prove a DNS problem, but do not leave users mapped to raw IP addresses unless your environment specifically supports that.

What should I do if only remote users have the issue?

Treat it like a network path problem until proven otherwise. Check VPN connection state, DNS servers, split tunnel rules, firewall access to SMB, and whether other internal resources work.

When should I escalate to the server or identity team?

Escalate when you have proved the machine can reach the server, the path is correct, the error is permission-related, and comparison testing points to account/group/folder access rather than the endpoint.

Bottom line

Network share tickets get easier when you stop treating the drive letter as the problem. Test the UNC path, capture the real error, compare against known-good users and machines, then escalate with evidence.

If you are building your help desk troubleshooting muscles, practice explaining your process out loud. The same thinking shows up in tickets and interviews. Start with the troubleshooting interview questions guide, then keep a few real ticket notes you can talk through without exposing company data.

Need more practical IT support walkthroughs? Join the IT Support Group newsletter and job board from the site header. We keep it focused on the stuff that actually shows up at work, not textbook theater.