Fix SMB error 0XC0000445: encrypted file conflict

What is 0XC0000445?

You're trying to open a file on a network share. Then boom — STATUS_CS_ENCRYPTION_FILE_NOT_CSE. The exact code: 0XC0000445. It means the SMB client on your machine asked the server to handle encryption, but the server says "This file isn't marked for client-side encryption, buddy."

I've seen this most often on Windows 10 Pro builds 2004–21H2, and on Windows Server 2019 acting as a file server. The trigger? You copied a file to an SMB share, or the server's folder has encryption attributes set via EFS or a third-party tool. The client assumes the file is CSE (Client Side Encryption) material. The server disagrees. Conflict. Error.

Here's the thing — 90% of the time, the fix is disabling Client Side Encryption on your client machine. It's a registry change that takes 30 seconds. Let's start there.

Simplest fix (30 seconds): Disable Client Side Encryption via registry

This disables the CSE negotiation entirely on your client. The share will still use standard SMB encryption, but the client won't demand CSE-specific handling. It won't break other shares — they'll just fall back to normal encryption.

1. Open Registry Editor (press Win + R, type regedit, hit Enter).
2. Navigate to

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

3. Create a new DWORD (32-bit) value named EnableClientSideEncryption. If it already exists, just modify it.
4. Set the value to 0 (zero).
5. Close regedit. No reboot needed — the change takes effect immediately on new connections.

Try accessing the file again. If it works, you're done. If not, move to the next step.

Moderate fix (5 minutes): Clear SMB cache and reset encryption settings

Sometimes the client caches encryption info from a previous connection. Clearing that cache forces a fresh negotiation. I've fixed several stubborn 0XC0000445 cases this way.

1. Open Command Prompt as Administrator (right-click Start, choose Windows Terminal (Admin) or Command Prompt (Admin)).
2. Run these commands in order:

   net stop workstation
   net stop netlogon
   net start netlogon
   net start workstation

3. Now clear the SMB client cache:

   net use * /delete /y

   This disconnects all mapped drives. They'll reconnect when you access them again.
4. Open File Explorer and manually type the UNC path to the share (like \\server\share). When prompted, enter your credentials.

If the registry fix worked for a while but the error came back, this cache clear usually nails it. The restart of the workstation service purges stale encryption state.

Advanced fix (15+ minutes): Remove EFS encryption attributes from the file

If the error persists, the file itself is the problem. The server sees an encryption attribute that isn't standard CSE. This often happens when someone used Encrypting File System (EFS) on the file, then copied it to a share. The attribute tag travels with the file, but the SMB server doesn't recognize it as CSE.

1. On the server (or the machine that hosts the share), open File Explorer.
2. Locate the problematic file or folder.
3. Right-click it, choose Properties → Advanced button (under Attributes).
4. Uncheck Encrypt contents to secure data. Click OK → Apply → OK.
5. If the file is encrypted and you can't uncheck it (EFS certificate missing), you need to decrypt it via command line:

   cipher /d "\\server\share\filename.ext"

   If that fails, you might need to take ownership first:

   takeown /f "\\server\share\filename.ext"
   icacls "\\server\share\filename.ext" /grant "%USERNAME%":F

   Then run the cipher /d command again.

I've seen this happen with PDFs and Office documents that were encrypted on a Windows 10 client via EFS, then copied to a Windows Server 2016 share. The encryption attribute is invisible in File Explorer until you check Advanced Properties. The cipher /d command strips it cleanly.

What if none of this works?

If you're still getting 0XC0000445 after all three steps, check for third-party encryption software (BitLocker To Go, VeraCrypt, or corporate DLP tools). These sometimes mark files with non-standard attributes. Disable the integration with SMB shares in that software's settings.

Also verify the SMB protocol version. Force SMB 3.x on both client and server. On the client, run:

Set-SmbClientConfiguration -EnableSMB3Protocol $true

One last thing: check the event logs. Look in Event Viewer under Applications and Services Logs → Microsoft → Windows → SMBClient → Operational. Filter for Event ID 31011 — it'll tell you exactly which file caused the error. That can save you a lot of guesswork.

You'll beat this error. Start with the registry fix. That's the one that works nine times out of ten.