Fixing ERROR_NET_OPEN_FAILED (0x0000023A) on Windows

1. Stale or Corrupted Network Drive Mapping

This is the culprit about 70% of the time. Windows caches credentials for mapped drives. If the server password changed or the share permissions were updated, Windows keeps using the old credentials. The NtCreateFile API tries to open the file with stale creds and gets denied — boom, 0x0000023A.

Here's the fix. Open a command prompt as Administrator and run:

net use * /delete

This kills all mapped drives. Then remap the drive fresh:

net use Z: \\fileserver\share /persistent:yes

Enter the current credentials when prompted. If you don't want to type them each time, use /user:DOMAIN\username and append * to be prompted once. Don't save the password in the command — that's sloppy.

If that doesn't work, clear the Stored Credentials entirely. Go to Control Panel > Credential Manager > Windows Credentials. Look for any entry under “Windows Credentials” that references the file server or IP. Remove them. Then remap the drive.

One more thing — check if the drive letter you're using is already in use by something else (like a phone sync or a local folder). Run mountvol to see all mount points. If it's conflicting, pick a different drive letter.

2. Insufficient Permissions on the Share or NTFS

If the mapping is fresh and still fails, it's permissions. The error code 0x0000023A maps to STATUS_ACCESS_DENIED under the hood. You're being blocked at the share level, the NTFS level, or both.

First, test with a different user account that you know has full access to the same file. If that works, the problem is your account's permissions. Go back to the share owner and ask them to check both share permissions (right-click share > Properties > Sharing tab > Permissions) and NTFS permissions (Security tab).

A common gotcha: share permissions default to Everyone with Read access, but NTFS permissions are more restrictive. The effective permission is the intersection of both. So even if share says Full Control, if NTFS says Read Only, you get Read Only. And if NTFS denies something, you get 0x0000023A.

For a quick test, give your user Full Control at the share level temporarily and also on the NTFS Security tab. If it works, the permission chain was broken. Then lock it down properly.

Another thing — if the file is on a DFS namespace, the permissions might apply at the folder target, not the DFS root. Check the actual UNC path under the hood with dfsutil /pthinfo.

3. SMB Protocol Version Mismatch or Driver Problem

Less common but real. You'll see this when connecting from an older Windows version to a newer server, or vice versa. Windows 10 and 11 default to SMB 3.1.1. But if the server only speaks SMB 1.0 (which is a security risk, by the way), the NtCreateFile call can fail with this error.

Check what SMB versions the server supports. On the client, run PowerShell as admin:

Get-SmbConnection | Select-Object ServerName, Dialect

If the dialect shows something lower than 2.0, you might need to enable SMB 1.0 on the client — but don't. That's insecure. Instead, update the server to support SMB 2.0 or higher. If you can't, use a different protocol like FTP or a web share.

Also check the SMB driver itself. Sometimes a Windows update breaks the SMB stack. Run:

dism /online /cleanup-image /restorehealth
sfc /scannow

If that finds corruption, reboot and test. If the error persists, remove the SMB 1.0 feature entirely (if it's enabled) and re-enable it. Go to Control Panel > Programs > Turn Windows features on or off. Uncheck “SMB 1.0/CIFS File Sharing Support”, reboot, then re-check it and reboot again. I've seen this fix weird NtCreateFile failures after cumulative updates.

One more edge case: antivirus software that intercepts SMB traffic. Some AV suites (looking at you, McAfee and Symantec) have network scanning that can block file opens. Temporarily disable the AV's network protection or add the file server IP to its exclusion list. If the error goes away, you found the problem.

Quick-Reference Summary Table