How to Use PowerShell and Net Use to Map Network Drives and Troubleshoot Shared Folder Access

Use PowerShell first for repeatable drive mapping, then use net use when you need a quick test or a clean reset. Both tools can connect Windows users to shared folders such as \\FileServer\Accounting, but they behave a little differently. Microsoft still documents net use as a supported command for connecting to shared resources, including drive letters and printers [source: Microsoft].

TLDR: Map a drive with PowerShell when you want a clean, scripted setup, such as assigning Z: to 25 users in the finance team. Use net use when you need a fast command-line check, for example net use Z: \\FS01\Finance /persistent:yes. If access fails, test the path, remove old saved connections, confirm permissions, and check credentials. In many support cases, the problem is not the drive letter at all; it is a stale password or mismatched share and NTFS permissions.

Map a network drive with PowerShell

PowerShell is the better choice for admins who want clarity. The main command is New-PSDrive. It can map a drive letter to a shared folder and make that mapping visible in File Explorer.

New-PSDrive -Name "Z" -PSProvider FileSystem -Root "\\FS01\Finance" -Persist

This creates drive Z: and points it to \\FS01\Finance. The -Persist switch matters. Without it, the drive may exist only in that PowerShell session. That catches people all the time.

If the share needs different credentials, use this:

$cred = Get-Credential
New-PSDrive -Name "Z" -PSProvider FileSystem -Root "\\FS01\Finance" -Credential $cred -Persist

PowerShell will ask for a username and password. For domain accounts, use a format like DOMAIN\j.smith. For local accounts on the file server, use FS01\localuser.

Map a network drive with Net Use

net use is old, plain, and still useful. Honestly, it feels like one of those tools that refuses to retire because it still solves real problems.

To map a drive:

net use Z: \\FS01\Finance /persistent:yes

To map with another account:

net use Z: \\FS01\Finance /user:DOMAIN\j.smith *

The asterisk asks for the password without showing it on screen. That is safer than typing the password directly into the command.

To list active connections:

net use

To remove a mapped drive:

net use Z: /delete

To remove every mapped connection:

net use * /delete

Be careful with that last command. It can disconnect working shares. Warn users first if they have files open.

PowerShell vs Net Use: which should you choose?

• Use PowerShell for scripts, logon tasks, admin automation, and clean error handling.
• Use net use for quick tests, old batch files, and fast cleanup.
• Use Group Policy when many domain users need the same mapped drives.
• Avoid hard-coded passwords in scripts. They spread fast and age badly.

A simple rule works well. If you are fixing one machine, net use is fine. If you are touching ten machines or more, script it with PowerShell.

Fast checks when a user cannot access a shared folder

Start with the path. Typos waste time. Test the UNC path directly in File Explorer:

\\FS01\Finance

If that fails, test it in PowerShell:

Test-Path "\\FS01\Finance"

If it returns False, the share may be offline, blocked, misspelled, or restricted. If it returns True but the user still cannot open files, look at permissions.

Check these items in order:

1. Network reachability: Can the user ping the server name or IP?
2. Name resolution: Does FS01 resolve to the right server?
3. Share permissions: Does the user or group have access to the share?
4. NTFS permissions: Does the folder itself allow the same access?
5. Saved credentials: Is Windows using an old password?
6. Drive letter conflict: Is Z: already in use?

Fix stale credentials

It drives me crazy that a bad saved credential can make a normal share look broken for 30 seconds longer than it should. Windows may keep trying the wrong account silently.

First, remove the mapped drive:

net use Z: /delete

Then remove stored credentials. Open Credential Manager, go to Windows Credentials, and delete entries for the file server. Look for names like FS01, \\FS01, or the server’s full domain name.

You can also check current connections:

net use

If you see a connection to the same server under the wrong user, delete it. Windows does not like connecting to the same server with two different usernames at the same time.

Check permissions the right way

Shared folders usually have two permission layers. This is where many fixes fail.

• Share permissions control access over the network.
• NTFS permissions control access to the folder on disk.

The most restrictive result wins. If the share allows Change but NTFS allows only Read, the user gets read-only access. If one layer denies access, the user is blocked.

For a sane setup, many teams set share permissions to a broad group and control real access with NTFS groups. Keep it simple. Use groups such as GG Finance Read and GG Finance Modify. Avoid assigning permissions to single users unless there is a clear reason.

Useful commands for support tickets

These commands give fast facts without guessing:

whoami
whoami /groups
hostname
ipconfig /all
net use
Test-Path "\\FS01\Finance"

Ask the user for the exact error text. “Access is denied” points toward permissions or credentials. “Network path was not found” points toward DNS, server availability, firewall rules, or a bad path. “The local device name is already in use” often means the drive letter is stuck or already assigned.

A safer repeatable mapping script

For a small team, this PowerShell pattern works well:

$Drive = "Z"
$Path = "\\FS01\Finance"

if (Get-PSDrive -Name $Drive -ErrorAction SilentlyContinue) {
    Remove-PSDrive -Name $Drive -Force
}

New-PSDrive -Name $Drive -PSProvider FileSystem -Root $Path -Persist

This removes the old mapping first, then creates a fresh one. It is simple, readable, and easy to adjust. Keep logs if you deploy it widely. That makes repeat failures much easier to spot.

Final advice: do not treat mapped drives as magic. They are just shortcuts to UNC paths. When they fail, test the path, clear old sessions, confirm identity, and check both permission layers. That process fixes most shared folder access issues without guesswork.