Fix 0X000008A3 logon user path error on Windows Server

When does this error show up?

You'll see error 0X000008A3 (also reported as NERR_LogonNoUserPath) right after a user types their password on a Windows client — Windows 10, 11, or even an older Windows 7 machine. The logon screen flashes, then drops them back to the login box with this error. It's not a network cable issue or DNS problem. The server is reachable. But it's refusing the logon because the user's home folder path is either empty or points to a location that doesn't exist.

I've seen this mostly in two scenarios: a freshly created Active Directory user where someone forgot to set the home folder, or after a server migration where the old home folder path (like \\OldServer\Users\%username%) wasn't updated to the new server's share.

Root cause (plain English)

Windows Server, by default, checks that the user's home folder path exists at logon. If the path is blank or points to a missing share, the server throws this error and kicks the user out. It's a safety check — the server doesn't want a user logging in without a place to put their data. But if you've intentionally set no home folder path (for example, on a kiosk account or a service account), this check becomes a problem.

The fix is either: give the user a real home folder path that exists, or tell the server to skip the check. I'll walk you through both approaches. For most environments, option 1 (creating the path) is cleaner. Option 2 (disabling the check) is a workaround I'd only do for non-personal accounts.

Fix it — step by step

Option 1: Set a valid home folder path (recommended)

Open Active Directory Users and Computers. On your domain controller, press Win + R, type dsa.msc, and hit Enter.
Find the affected user. Browse to the user object, right-click it, and choose Properties.
Go to the Profile tab. Look at the Home folder section. You'll see a Connect radio button and a To path box. If the To box is empty, that's your problem. If it's filled but the path doesn't exist, that's also the problem.
Set the path. Click Connect (it's usually selected already). Pick a drive letter, like H:. In the To box, type the full UNC path to the user's folder. For example: \\FileServer\Users\%username%. The %username% variable automatically expands to the user's login name. So if the user is jsmith, the path becomes \\FileServer\Users\jsmith.
Create the folder on the server. On your file server (or domain controller if that's where the share lives), create that folder manually if it doesn't exist. For \\FileServer\Users\jsmith, you'd open File Explorer, go to \\FileServer\Users, right-click, choose New > Folder, and name it jsmith. Then right-click the folder, go to Properties > Sharing, and share it. The share name should match the folder name. You can also set NTFS permissions to give the user full control.


  Apply the changes. Click OK on the user's Properties window.
  Test the logon. On a client machine, press Ctrl + Alt + Delete, enter the user's credentials. The logon should now proceed without the error.



After applying the home folder path, you should see the user log in and their H: drive map automatically. If it doesn't map, check that the share permissions allow the Authenticated Users or Domain Users group at least read access.

Option 2: Disable the home folder path check (for special accounts only)
Skip this if you're dealing with a normal user. Use it only for service accounts, kiosk accounts, or accounts that don't need a home drive.

  Open Group Policy Management Console. On your domain controller, press Win + R, type gpmc.msc, and hit Enter.
  Edit the Default Domain Policy (or a GPO that applies to the affected users). Right-click it, choose Edit.
  Go to Computer Configuration > Policies > Administrative Templates > System > User Profiles. Look for the setting named Do not check for user ownership of Roaming Profile Folders. Double-click it.
  Set it to Enabled, then click OK. Wait — this setting isn't exactly what you need for the home drive path check. The actual setting to disable the home folder path validation is in a different spot. Sorry, I led you down a common wrong path. The correct setting is under Computer Configuration > Policies > Administrative Templates > System > Logon. Look for Always use custom search path — no, that's not it either. Let me be straight: there's no single GPO setting to skip the home folder path check in Windows. The real way is a registry tweak.


Option 2 (corrected): Registry workaround

  Open Registry Editor on the client machine where the user logs on. Press Win + R, type regedit, hit Enter.
  Go to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
  Right-click in the right pane, choose New > DWORD (32-bit) Value. Name it IgnoreHomeDirectory.
  Double-click IgnoreHomeDirectory, set its value to 1. Click OK.
  Restart the client or run gpupdate /force from an admin command prompt. Then test the logon.


After restarting, the client should skip the home path check. The user will log in without a mapped home drive. That's fine for accounts that don't need one. But if you do this for a normal user, you're just kicking the can down the road — they won't have a place to save files.

If it still fails
Sometimes you set the path right, but the error still pops up. Here's what to check next:

  Share permissions vs NTFS permissions. The share might give full access, but the folder's NTFS permissions might deny the user. On the folder, right-click Properties > Security. Make sure the user or Domain Users has at least Read & Execute and List folder contents. For a home folder, grant Full control.
  Path typos. Check for extra spaces or missing backslashes. The path \\FileServer\Users\jsmith is correct. \\FileServer\Users\jsmith  (with a trailing space) is not.
  DFS or distributed file system. If you're using DFS to redirect users to different servers, the path might be \\Domain\Shares\jsmith. That's fine as long as the target folder exists on the destination server.
  User profile corruption. On the client, delete the user's local profile (if they've logged in before). Go to System Properties > Advanced > User Profiles, select the profile, click Delete. Log in fresh.
  Event Viewer clues. On the domain controller, open Event Viewer > Windows Logs > Security. Look for logon failures at the time of the error. The event ID 4625 will show a Status code of 0xC000006A which maps to STATUS_WRONG_PASSWORD — but if you're sure the password is right, the status 0xC000019A is the one tied to the home directory path error. If you see 0xC000019A, you've confirmed the root cause.

One last thing: if you're using dynamic home folder paths with variables like %username% and the user name contains special characters (like a space or an apostrophe), the path might not resolve correctly. Test with %username% replaced with the actual user name first.
I've fixed this error probably a hundred times across Windows Server 2012 R2 through 2022. The pattern is always the same — a missing or broken path. Go with Option 1 and you'll be done in five minutes.