Fix 0XC00000D0 Printer/Share Error on Windows 10/11

This Windows network error means a printer or file share request got denied. Usually happens after a Windows update breaks SMB signing or print spooler permissions.

Quick answer for advanced users

Enable SMB2 signing on the target machine or disable SMB1 entirely on both sides, then restart the print spooler and the Server service.

What this error actually means

You're trying to connect to a shared printer or a file share on another Windows machine, and it kicks back STATUS_REQUEST_NOT_ACCEPTED (0XC00000D0). This is not a driver issue or a cable problem. The server flat-out refused your request because it didn't trust the way you asked. I've seen this three times in the past month: once on a Windows 11 machine trying to print to a Windows 10 shared printer, once on a Server 2019 box sharing a folder to a Windows 11 laptop, and once on a cheapo network printer that only talks SMB1. Every single time it came down to a security mismatch in how Windows handles network requests after a patch Tuesday update.

The root cause is almost always SMB (Server Message Block) signing. Windows updates from late 2023 and early 2024 started enforcing SMB signing by default. If the client machine asks for a connection without signing, or with an older signing version, the server says "nope, my security policy won't allow that" and returns 0XC00000D0. Another common trigger: the print spooler on the server has its permissions locked down too tight, or the user account on the client doesn't match the server's expectations. But 9 out of 10 times, it's SMB signing.

Fix steps (start here)

Check SMB1 status on both machines. Open PowerShell as admin and run Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol. If it shows Enabled, disable it with Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol. Reboot both machines. SMB1 is ancient, insecure, and often causes this exact error when mixed with modern SMB2/3.
Enable SMB2 signing on the server. On the machine hosting the printer or file share, open PowerShell as admin and run Set-SmbServerConfiguration -RequireMessageSigning $true -Force. Then run Set-SmbClientConfiguration -RequireMessageSigning $true -Force. This forces both sides to use signed connections. Reboot the server.
Restart print spooler and server services. In an admin command prompt, run: net stop spooler && net start spooler. Then net stop server && net start server. This clears any stale SMB sessions.
Flush SMB connections on the client. On the machine that gets the error, run net use * /delete to clear all network drive mappings and printer connections. Then run nbtstat -R to refresh the NetBIOS name cache. Reboot the client.
Test the connection. Try adding the printer or accessing the file share again. If it works, you're done. If not, move to the alternative fixes below.

Alternative fixes if the main one fails

Check credential manager

Sometimes Windows stores old credentials that conflict. Go to Control Panel > Credential Manager > Windows Credentials. Look for any entries related to the server's IP or hostname. Remove them. Then try again. Had a client last month whose entire print queue died because of a stale credential from a previous IT guy's login.

Adjust local security policy

If you're on Windows 10/11 Pro or Enterprise, run secpol.msc. Go to Security Settings > Local Policies > Security Options. Find "Network security: LAN Manager authentication level". Set it to "Send NTLMv2 response only. Refuse LM & NTLM". Also find "Microsoft network server: Digitally sign communications (always)" and enable it. Reboot.

Registry hack for unsigned SMB (last resort)

If you absolutely cannot get signing to work (maybe the remote device is old or embedded), you can allow unsigned connections. On the server, open regedit, go to HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters. Create a DWORD value named RequireSecuritySignature and set it to 0. On the client, go to HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters, create a DWORD RequireSecuritySignature and set it to 0. Reboot both. Warning: This weakens security. Only do this if you trust every device on your network.

Prevention tip

Keep SMB1 disabled forever. It's a security risk and causes headaches like this. Also, after every major Windows update, run Get-SmbServerConfiguration | fl RequireMessageSigning to check if Microsoft flipped the signing setting back to default. They've done that before. If you see RequireMessageSigning : False, set it back to True using the PowerShell command from step 2. That single setting has stopped this error cold for three different clients this year.