Local account · lockout policy

Clearing a locked local account — for good

A share stops responding, Windows blames a locked-out account, and the fix takes two commands. Here's what the dialog actually means and how to make sure it doesn't come back.

Scope: local account, no domain Tools: Command Prompt (admin) Reversible: yes
Open Folder ✕
✕
\\Moon is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.
The referenced account is currently locked out and may not be logged on to.

This isn't a permissions problem, even though Windows phrases it that way. The account has been locked by the local security policy on the machine sharing the folder — usually after a handful of failed logon attempts, often from a saved credential or a mapped drive quietly retrying in the background. Two things fix it: unlock the account now, and turn off the policy that will lock it again later.

Why the account locked

Windows machines carry a local lockout policy even outside a domain. By default it allows a small number of bad password attempts before it disables the account for a set period — a leftover mapped drive, an old saved password in Credential Manager, or a service still pointed at the previous password are the usual causes. On a single trusted machine like this, that protection mostly gets in your own way.

1

Unlock the account immediately

Open Command Prompt as Administrator on the machine hosting the share — the box being reached as \\Moon — and run:

cmd.exe — Administrator 
C:\> net user <username> /active:yes

Replace <username> with the actual account name. This re-enables the account and clears the locked state. If you're not sure of the exact account name, list every local account first with net user.

2

Turn off the lockout policy

Unlocking the account only fixes today. To stop it from locking again, set the lockout threshold to zero — this tells Windows to never lock accounts, no matter how many bad attempts it sees:

cmd.exe — Administrator 
C:\> net accounts /lockoutthreshold:0

This is a machine-wide setting — it applies to every local account, not just the one that locked. There's nothing more to schedule or repeat; the policy stays off until someone changes it back.

3

Confirm both changes took effect

Run net accounts on its own to print the current policy, and check the account state directly:

cmd.exe — Administrator 
C:\> net accounts
Lockout threshold should now read Never

C:\> net user <username>
Account active should read Yes
Lockout threshold
Never — no failed-attempt count will lock the account
Account active
Yes — the account can log on and serve the share again
If the command line is blocked

The same two changes are reachable through the GUI: open secpol.msc → Account Policies → Account Lockout Policy to set the threshold, and Computer Management → Local Users and Groups → Users, then untick "Account is disabled" on the affected account.

Worth knowing before you leave it this way

A threshold of zero removes brute-force lockout protection entirely — anyone with network access to this machine can attempt passwords without limit. That trade is reasonable on an internal box on a trusted LAN, like a home or small-office server nothing outside the network can reach. It's not something to carry onto a machine exposed to the internet.

Field note

If this account locks again shortly after you clear it, something is retrying the old password automatically — check Credential Manager on any machine that connects to the share, and any mapped drives or scheduled tasks that store a saved login for this account.