Fix ERROR_LOGON_NOT_GRANTED (0x564) – Logon Type Denied

Quick answer

Add the affected user or group to the matching "Log on as a ..." right in Local Security Policy (`secpol.msc`) → Local Policies → User Rights Assignment. Then run `gpupdate /force` and try again.

What's actually happening here

Windows doesn't just check your password when you authenticate. It also checks how you're trying to log on — interactive (at the keyboard), network (SMB share), batch (scheduled task), or service. Each of those is a separate privilege. When you see ERROR_LOGON_NOT_GRANTED (0X00000564), the username and password are fine. What's missing is the right to log on that way.

This error shows up most often when you're connecting to a file share or using net use and get "Access is denied" even though the share permissions look correct. It also happens when a scheduled task runs under a service account that lacks the "Log on as a batch job" right. The system is explicit: you haven't been granted the requested logon type.

On a domain-joined machine, these rights usually come from Group Policy. On a standalone box, they live in the local security database. Either way, the fix is the same — you just need to grant the right.

The fix (numbered steps)

Identify the logon type from the error. Check the source. If it's a network share (\server\share), you need "Access this computer from the network". If it's a scheduled task, you need "Log on as a batch job". If it's a service, you need "Log on as a service". The error message itself doesn't tell you which one, so look at what you were doing.
Open Local Security Policy. Press Win+R, type secpol.msc, and hit Enter. If this is a domain machine and you're not a local admin, you'll need to run it as an admin or contact your domain admin.
Go to Local Policies → User Rights Assignment. Find the right that matches your logon type. For the network case, that's "Access this computer from the network". For batch, it's "Log on as a batch job". For service, "Log on as a service".
Add the user or group. Double-click the right, click "Add User or Group", type the account name (e.g., DOMAIN\username or NT AUTHORITY\NETWORK SERVICE), and click OK. If the account is a domain account, you might need to use the full UPN like user@domain.com — that's fine.
Apply and refresh. Click OK, then run gpupdate /force in an elevated command prompt. On a local machine, the policy applies immediately, but it doesn't hurt to refresh.
Test the login again. Reconnect to the share, rerun the task, or restart the service. If it still fails, the user might be in a group that's explicitly denied. Check the same policy for the "Deny access to this computer from the network" entry — that overrides the allow.

When the main fix doesn't work

Sometimes the policy looks right but the error persists. Here's what to check next:

Local vs. domain policy conflict. If the machine is domain-joined, the effective policy is the intersection of local and domain policies. Use rsop.msc (Resultant Set of Policy) to see what's actually applied. A domain GPO might be removing the right you just added locally.
Restart the Server service. On the target machine, open Services (services.msc), find "Server", and restart it. This clears cached security tokens that might be stale. It's a quick thing to try before digging deeper.
Check UAC remote restrictions. If you're using an administrator account over the network, Windows applies FilterAdministratorToken. For local accounts in the Administrators group, this can effectively strip the "Access this computer from the network" right unless you add the account to the "Network Access: Do not allow anonymous enumeration of SAM accounts" policy — though that's a workaround, not a fix.
Use `secedit` if GUI is blocked. Run this in an elevated prompt to grant the right from the command line for the network logon type:

secedit /export /cfg C:\secpol.cfg
// Edit C:\secpol.cfg — add the user to SeNetworkLogonRight
secedit /configure /db secedit.sdb /cfg C:\secpol.cfg /areas USER_RIGHTS
gpupdate /force

The reason this works is that secedit writes directly to the local security policy, bypassing any UI weirdness. Just make sure you back up the original config first.

Prevention tip

Stop granting rights to individual users. Instead, create a group (e.g., Share_Users), add that group to the policy, and add users to the group. This way you're not touching security policy every time someone joins or leaves. On domain environments, do this in Group Policy Management, not on each machine.

Also, remember that "Deny" entries always win over "Allow". If you're troubleshooting a similar error later, check the deny lists first — they're the common cause when a user is already in the allowed group.

The real lesson here: the error code is precise. It's not a permissions problem on the folder — it's a logon method problem. Once you know which logon type you're dealing with, the fix is mechanical.