SMB encryption configuration issue

Question

SMB encryption configuration issue

Sahil Soni 100

Hi guys

I’m trying to set up EncryptData on my SoFS file shares, but after enabling it, end users lost access because their client systems don’t support SMB 3.0 encryption.

Here’s what I’m seeing:

error: access_denied

error subcode:

Description: failed%20to%20negotiate%20SMB%20encryption

Previously, everything worked fine before enabling encryption. Could someone kindly explain how to configure SMB encryption requirements selectively per share or through a global policy so that older clients can still connect ?

0 comments

Answer accepted by question author

HLBui 11,095 Independent Advisor

Hi Sahil Soni

I think the issue you’re seeing comes down to SMB 3.0 encryption support. Once you enable EncryptData on your SoFS shares, the server enforces encryption, and any client that doesn’t support SMB 3.0 encryption will fail to negotiate that’s why you’re hitting access_denied. The fix is to make encryption selective: you can configure it per share using PowerShell (Set-SmbShare -EncryptData $true/$false) so only sensitive shares require encryption, while others stay accessible to older clients. Alternatively, you can adjust the global server policy with Set-SmbServerConfiguration -EncryptData to make encryption optional instead of mandatory, which lets legacy clients connect while newer ones still encrypt. Long term, the best practice is to phase out those older clients, but this selective approach gives you breathing room.

If this guidance proves helpful, feel free to click “Accept Answer” so we know we’re heading in the right direction and let me know if you need any assistance. Thank you!

Sahil Soni 100 Reputation points

2026-09-04T03:05:32.1333333+00:00

Thanks for your answer, I’ll give it a try and let you know how it goes.

1 additional answer

Your answer

Sahil Soni 100 Reputation points

2026-09-04T03:05:32.1333333+00:00

Thanks for your answer, I’ll give it a try and let you know how it goes.

Answer 1

EncryptData can be applied either per share or for the entire SMB server.

For selective use, enable encryption only on the shares that need it:

Set-SmbShare –Name <sharename> -EncryptData $true

To require encryption for every share on the file server, use:

Set-SmbServerConfiguration –EncryptData $true

To create a new encrypted share:

New-SmbShare –Name <sharename> -Path <pathname> –EncryptData $true

Why older clients lost access:

When SMB Encryption is enabled for a share or server, only SMB 3.0, 3.02, and 3.1.1 clients can access those encrypted shares by default.
Clients that do not support SMB 3.x are rejected and can receive Access denied.
If unencrypted access remains blocked at the default setting, non-encryption-capable clients cannot connect.

If older clients must still connect during a transition period, unencrypted access can be allowed on the server with:

Set-SmbServerConfiguration –RejectUnencryptedAccess $false

Important:

This reduces security and is not recommended except as a temporary transition measure.
The recommended approach is to update clients so they support SMB encryption.
To guarantee SMB 3.1.1 clients always use encryption for encrypted shares, SMB 1.0 server should be disabled.

For client-side enforcement, there are also global options:

Per mapped drive:

New-SMBMapping -LocalPath <drive letter> -RemotePath <UNC path> -RequirePrivacy $TRUE

or

NET USE <drive letter> <UNC path> /REQUIREPRIVACY

Per machine, for all outbound SMB connections on supported clients:

Set-SmbClientConfiguration -RequireEncryption $true

By Group Policy on supported clients:
1. Open Group Policy Management Console.
2. Edit or create a GPO.
3. Go to Computer Configuration > Administrative Templates > Network > Lanman Workstation.
4. Edit Require encryption.
5. Set it to Enable.

Prerequisites and compatibility notes:

Global SMB client encryption requirement is supported beginning with Windows 11, version 24H2, and Windows Server 2025.
If client-side encryption is required globally, the client will refuse to connect to servers that do not support SMB 3.0 or later and SMB encryption.
SMB encryption has performance and compatibility overhead, so broad deployment should be tested carefully, especially with legacy servers or third-party SMB servers.

For the described scenario, the practical approach is:

Keep EncryptData enabled only on the specific shares that require protection.
Leave non-sensitive shares unencrypted for legacy clients.
If legacy access is temporarily unavoidable on encrypted shares, set –RejectUnencryptedAccess $false with the understanding that this weakens protection.
Plan a client upgrade path to SMB 3.x-capable systems.