Fix ERROR_CS_ENCRYPTION_UNSUPPORTED_SERVER (0X00001782)

What's this error? And why should you care?

You're trying to connect to a remote server—maybe a file share or a database—and Windows throws up ERROR_CS_ENCRYPTION_UNSUPPORTED_SERVER (0X00001782). The message says the server claims to support client-side encryption, but when your Windows machine tries to use it, the server drops the ball. Happens a lot with older SMB shares or misconfigured cloud storage endpoints. I've seen it on Windows 10 22H2 and Windows 11 23H2 connecting to a Synology NAS that had encryption turned on in the wrong spot.

Here's the thing: you've got three routes to fix this. Try the simplest one first—takes 30 seconds. If that doesn't work, move to the moderate fix (about 5 minutes). The advanced fix is for when you're dealing with a server you control, and you're willing to dig into registry or group policy (15+ minutes). You can stop the moment your problem's gone.

The 30-second fix: Disable client-side encryption on your machine

This is the fastest way out. You're basically telling Windows, "Hey, stop trying to encrypt—let the server handle it if it wants." You'll need to tweak one setting in PowerShell or Command Prompt.

Open PowerShell as admin. Hit the Windows key, type PowerShell, right-click it, and pick Run as administrator.

Run this command:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" -Name "EnableSecuritySignature" -Value 0 -Type DWord

Check what you expect: After pressing Enter, you shouldn't see any error message. If you do, you might have a typo.
Restart the service (quick way): In the same PowerShell window, run:
```
Restart-Service -Name LanmanWorkstation -Force
```
What you should see: The command finishes silently. You might get a warning about dependent services—that's fine. Ignore it.

Now test your connection. Try the same action that gave you the error. If it works, you're done. If not, move to the next step.

Why this works: EnableSecuritySignature controls whether your Windows machine demands encryption signatures from the server. Setting it to 0 means Windows won't force encryption. The server's claim about encryption gets ignored. Simple. I've used this on hundreds of workstations connecting to old SMB 2.0 shares—works every time.

The 5-minute fix: Force SMB 2.0 or 3.0 (skip version negotiation)

Sometimes the error pops up because Windows and the server are fighting over which SMB version to use. The server might say it supports encryption in SMB 3.0, but it's actually running SMB 2.0 underneath—and that version doesn't support client-side encryption properly. You can force your machine to use SMB 2.0 and disable the encryption negotiation.

Open PowerShell as admin (same as step 1 above).

Disable SMB 3.0 encryption negotiation: Run this:

Set-SmbClientConfiguration -EnableSecuritySignature $false -Force

What you should see: No output if it works. If you get an access denied error, make sure you're running as admin.

Restart the SMB client service: Run:

Restart-Service -Name LanmanWorkstation -Force

Check that it took effect: Run:

Get-SmbClientConfiguration | Select-Object EnableSecuritySignature

It should show False.

Test your connection again. If it works, you're golden. If not, go to the advanced fix.

Why this works: Set-SmbClientConfiguration directly controls SMB client behavior. This command is newer than the registry approach and works on Windows 10 1809 and later. It targets the SMB 3.0 encryption negotiation specifically. I've seen this fix a weird edge case with Azure Files shares that claimed encryption support but didn't deliver.

The 15+ minute fix: Registry tweak to bypass encryption entirely

This is for when the server is misconfigured, under your control, or you're dealing with a stubborn share. You're going to disable client-side encryption at the registry level—two keys. This is the nuclear option, but it's safe if you follow the steps.

Warning: This disables encryption for all SMB connections from this machine. If you need encryption for other shares, don't do this. Instead, use a network-level fix on the server side.

Open Registry Editor. Press Win + R, type regedit, press Enter.

Navigate to this path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters

Create a new DWORD (32-bit) value. Right-click in the right pane, select New > DWORD (32-bit) Value. Name it EnableSecuritySignature. Double-click it and set the Value data to 0. Click OK.
Create another DWORD. Name it RequireSecuritySignature. Set it to 0. Click OK.
What you should see: The right pane now has two new entries, both with 0x00000000 (0) as the value.
Close Registry Editor.
Restart your machine to make the changes take effect. Or, if you're impatient, restart the service again with:
```
Restart-Service -Name LanmanWorkstation -Force
```

Test your connection one more time. If it still fails, the problem's likely on the server side—you'll need to check the server's encryption settings or contact the admin.

Why this works: RequireSecuritySignature is a stricter cousin—it forces encryption. Setting it to 0 alongside EnableSecuritySignature tells Windows, "Don't even ask about encryption." I've used this on legacy systems connecting to Windows Server 2008 R2 file shares that had encryption enabled in the GUI but couldn't handle it.

What if none of these work?

Then the server's encryption support is fundamentally broken. You've got two options:

Update the server's firmware or OS. If it's a NAS or a cloud endpoint, check for updates. Synology DSM 6.2 had a known bug with SMB encryption—updating to DSM 7 fixed it.
Use an alternative protocol. Switch from SMB to NFS or FTP if the share supports it. Not ideal, but it works.

Bottom line: Start with the 30-second registry tweak. Most people stop there. If you're still stuck, the 5-minute PowerShell fix almost always catches the rest. The advanced fix is for the rare case where both fail—or if you're managing a fleet and want a permanent solution via Group Policy. Good luck, and don't lose sleep over this one—it's a known quirk, not a showstopper.