mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

[Thomas Spear]

First time emailing here, I hope I'm writing to the correct place.

I have an Azure Storage account that has been configured with an Azure
Files share to allow only AES-256-GCM channel encryption with NTLMv2
authentication via SMB, and I have a linux client which is running
Ubuntu 24.04 and has the Ubuntu version of cifs-utils 7.0 installed,
however after looking at the release notes for the later upstream
releases I don't think this is specific to this version and rather it
is an issue in the upstream.

When I try to mount an Azure Files share over SMB, I get a mount error
13. However, if I do either of the following, I'm able to successfully
mount.

1. Enable AES-128-GCM on the storage account
2. Keep AES-128-GCM disabled on the storage account, but enforce
AES-256-GCM on the client side by running 'echo 1 >
/sys/module/cifs/parameters/require_gcm_256' after loading the cifs
module with modprobe.

I can see after running modprobe that the parameter "enable_gcm_256"
is set to Y (the default value) and the parameter "require_gcm_256" is
set to N (also the default value)  so I believe the mount command
should theoretically negotiate with the server, but it seems that no
matter what I try, unless I require 256 bits on the client side by
overwriting the "require_gcm_256" parameter, it will never mount
successfully when the server only allows 256 bits.

It seems like mount.cifs should look at the "enable_gcm_256" parameter
and if it's "Y" try to use 256 bits at first, falling back to 128 bits
if the server doesn't support it or throwing an error if the
"require_gcm_256" parameter is set to the default "N" value, but I
must admit I don't know if there's some reason that can't be done.

Is this something that could be looked at and possibly improved? I'm
unfortunately not a developer, but just a user interested in making
better documentation so if this cannot be improved, I'll go ahead and
get something written up and share it with downstream teams like Azure
Files CSI driver -- on that note, I'll appreciate any clarification on
why setting this specific parameter is required if this can't be
improved.

Thank you,

Thomas Spear

Re: mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

[Steve French]

Good catch - this looks very important.

Do you remember if Samba support gcm256 signing?

On Mon, Oct 20, 2025 at 3:52 PM Thomas Spear <speeddymon@gmail.com> wrote:
>
> First time emailing here, I hope I'm writing to the correct place.
>
> I have an Azure Storage account that has been configured with an Azure
> Files share to allow only AES-256-GCM channel encryption with NTLMv2
> authentication via SMB, and I have a linux client which is running
> Ubuntu 24.04 and has the Ubuntu version of cifs-utils 7.0 installed,
> however after looking at the release notes for the later upstream
> releases I don't think this is specific to this version and rather it
> is an issue in the upstream.
>
> When I try to mount an Azure Files share over SMB, I get a mount error
> 13. However, if I do either of the following, I'm able to successfully
> mount.
>
> 1. Enable AES-128-GCM on the storage account
> 2. Keep AES-128-GCM disabled on the storage account, but enforce
> AES-256-GCM on the client side by running 'echo 1 >
> /sys/module/cifs/parameters/require_gcm_256' after loading the cifs
> module with modprobe.
>
> I can see after running modprobe that the parameter "enable_gcm_256"
> is set to Y (the default value) and the parameter "require_gcm_256" is
> set to N (also the default value)  so I believe the mount command
> should theoretically negotiate with the server, but it seems that no
> matter what I try, unless I require 256 bits on the client side by
> overwriting the "require_gcm_256" parameter, it will never mount
> successfully when the server only allows 256 bits.
>
> It seems like mount.cifs should look at the "enable_gcm_256" parameter
> and if it's "Y" try to use 256 bits at first, falling back to 128 bits
> if the server doesn't support it or throwing an error if the
> "require_gcm_256" parameter is set to the default "N" value, but I
> must admit I don't know if there's some reason that can't be done.
>
> Is this something that could be looked at and possibly improved? I'm
> unfortunately not a developer, but just a user interested in making
> better documentation so if this cannot be improved, I'll go ahead and
> get something written up and share it with downstream teams like Azure
> Files CSI driver -- on that note, I'll appreciate any clarification on
> why setting this specific parameter is required if this can't be
> improved.
>
> Thank you,
>
> Thomas Spear
>


-- 
Thanks,

Steve

Re: mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

[Enzo Matsumiya]

On 10/21, Steve French wrote:
>Good catch - this looks very important.
>
>Do you remember if Samba support gcm256 signing?

This is for encryption on Azure.

>On Mon, Oct 20, 2025 at 3:52 PM Thomas Spear <speeddymon@gmail.com> wrote:
>>
>> First time emailing here, I hope I'm writing to the correct place.
>>
>> I have an Azure Storage account that has been configured with an Azure
>> Files share to allow only AES-256-GCM channel encryption with NTLMv2
>> authentication via SMB, and I have a linux client which is running
>> Ubuntu 24.04 and has the Ubuntu version of cifs-utils 7.0 installed,
>> however after looking at the release notes for the later upstream
>> releases I don't think this is specific to this version and rather it
>> is an issue in the upstream.
>>
>> When I try to mount an Azure Files share over SMB, I get a mount error
>> 13. However, if I do either of the following, I'm able to successfully
>> mount.
>>
>> 1. Enable AES-128-GCM on the storage account
>> 2. Keep AES-128-GCM disabled on the storage account, but enforce
>> AES-256-GCM on the client side by running 'echo 1 >
>> /sys/module/cifs/parameters/require_gcm_256' after loading the cifs
>> module with modprobe.

@Thomas:
Yes, that happens because cifs sends AES-128-GCM as the preferred
algorithm:

(you said you're not a developer, but this illustrates what happens)

   static void
   build_encrypt_ctxt(struct smb2_encryption_neg_context *pneg_ctxt)
   {
           pneg_ctxt->ContextType = SMB2_ENCRYPTION_CAPABILITIES;
           if (require_gcm_256) {
                   pneg_ctxt->DataLength = cpu_to_le16(4); /* Cipher Count + 1 cipher */
                   pneg_ctxt->CipherCount = cpu_to_le16(1);
                   pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES256_GCM;
           } else if (enable_gcm_256) {
                   pneg_ctxt->DataLength = cpu_to_le16(8); /* Cipher Count + 3 ciphers */
                   pneg_ctxt->CipherCount = cpu_to_le16(3);
                   pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_GCM;
                   pneg_ctxt->Ciphers[1] = SMB2_ENCRYPTION_AES256_GCM;
                   pneg_ctxt->Ciphers[2] = SMB2_ENCRYPTION_AES128_CCM;
           } else {
                   pneg_ctxt->DataLength = cpu_to_le16(6); /* Cipher Count + 2 ciphers */
                   pneg_ctxt->CipherCount = cpu_to_le16(2);
                   pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_GCM;
                   pneg_ctxt->Ciphers[1] = SMB2_ENCRYPTION_AES128_CCM;
           }
   }

so if the server supports AES-256-GCM, the only way to make cifs use it
is with 'require_gcm_256', unless you disable AES-128-GCM on the server
(as you have observed).

I don't really know/understand the reasoning for this, but it's probably
because Windows follows that order.  AFAIK the performance difference
between AES-GCM 128 and 256 should be negligible (to the user) nowadays.

IMO we should reorder this to prefer AES-256-GCM by default, hence drop
the {require,enable}_gcm_256 parameters, and make it an opt-out thing
instead (Steve?).


* Also @Steve, I just noticed we handle AES-256-CCM everywhere else, but
   never actually negotiate it.  Apparently nobody ever complained about
   it not existing/working, so maybe just drop it?


Cheers,

Enzo

Re: mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

[Thomas Spear]

This sort-of makes sense as to why it's happening. I can understand
some code so what I see here is:

>  else if (enable_gcm_256) {
>                   pneg_ctxt->DataLength = cpu_to_le16(8); /* Cipher Count + 3 ciphers */
>                   pneg_ctxt->CipherCount = cpu_to_le16(3);
>                   pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_GCM;
>                   pneg_ctxt->Ciphers[1] = SMB2_ENCRYPTION_AES256_GCM;
>                   pneg_ctxt->Ciphers[2] = SMB2_ENCRYPTION_AES128_CCM;

Here, AES-256-GCM is second to AES-128-GCM when enable_gcm_256 is
true, but if AES-256-GCM is still present as one of the ciphers as per
this snipped, and the server doesn't support AES-128-GCM, shouldn't it
fall-forward to AES-256-GCM instead of causing an error? IOW, I'm
wondering if there's an issue elsewhere that's preventing the
AES-256-GCM cipher from being used and reordering would simply
band-aid the issue.

> so if the server supports AES-256-GCM, the only way to make cifs use it
> is with 'require_gcm_256', unless you disable AES-128-GCM on the server
> (as you have observed).

Actually, the issue I'm observing is that _when_ we disable
AES-128-GCM on the server (Azure Files), mount.cifs on the client is
failing to mount the share completely _until_ I set require_gcm_256.
I'm happy to do some debugging and provide outputs if needed. We're
testing this setup in a lab environment for a wider rollout to
non-prod and production for an app team who needs to mount Azure Files
in Kubernetes, so we're using the Azure Files CSI driver for
Kubernetes and I have full access to the underlying nodes since it's a
lab cluster.

Side note, I also found this unix stackexchange question that seems to
be related but is for a non-Kubernetes Linux client and a FreeNAS
device as the Samba server:
https://unix.stackexchange.com/questions/766995/linux-smb-client-failed-to-connect-to-smb-server-forcing-aes-256/800613#800613

Thank you,

Thomas

On Tue, Oct 21, 2025, 1:31 PM Enzo Matsumiya <ematsumiya@suse.de> wrote:
>
> @Thomas:
> Yes, that happens because cifs sends AES-128-GCM as the preferred
> algorithm:
>
> (you said you're not a developer, but this illustrates what happens)
>
>    static void
>    build_encrypt_ctxt(struct smb2_encryption_neg_context *pneg_ctxt)
>    {
>            pneg_ctxt->ContextType = SMB2_ENCRYPTION_CAPABILITIES;
>            if (require_gcm_256) {
>                    pneg_ctxt->DataLength = cpu_to_le16(4); /* Cipher Count + 1 cipher */
>                    pneg_ctxt->CipherCount = cpu_to_le16(1);
>                    pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES256_GCM;
>            } else if (enable_gcm_256) {
>                    pneg_ctxt->DataLength = cpu_to_le16(8); /* Cipher Count + 3 ciphers */
>                    pneg_ctxt->CipherCount = cpu_to_le16(3);
>                    pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_GCM;
>                    pneg_ctxt->Ciphers[1] = SMB2_ENCRYPTION_AES256_GCM;
>                    pneg_ctxt->Ciphers[2] = SMB2_ENCRYPTION_AES128_CCM;
>            } else {
>                    pneg_ctxt->DataLength = cpu_to_le16(6); /* Cipher Count + 2 ciphers */
>                    pneg_ctxt->CipherCount = cpu_to_le16(2);
>                    pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_GCM;
>                    pneg_ctxt->Ciphers[1] = SMB2_ENCRYPTION_AES128_CCM;
>            }
>    }
>
> so if the server supports AES-256-GCM, the only way to make cifs use it
> is with 'require_gcm_256', unless you disable AES-128-GCM on the server
> (as you have observed).
>
> I don't really know/understand the reasoning for this, but it's probably
> because Windows follows that order.  AFAIK the performance difference
> between AES-GCM 128 and 256 should be negligible (to the user) nowadays.
>
> IMO we should reorder this to prefer AES-256-GCM by default, hence drop
> the {require,enable}_gcm_256 parameters, and make it an opt-out thing
> instead (Steve?).
>
>
> * Also @Steve, I just noticed we handle AES-256-CCM everywhere else, but
>    never actually negotiate it.  Apparently nobody ever complained about
>    it not existing/working, so maybe just drop it?
>
>
> Cheers,
>
> Enzo

Re: mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

[Enzo Matsumiya]

On 10/21, Thomas Spear wrote:
>This sort-of makes sense as to why it's happening. I can understand
>some code so what I see here is:
>
>>  else if (enable_gcm_256) {
>>                   pneg_ctxt->DataLength = cpu_to_le16(8); /* Cipher Count + 3 ciphers */
>>                   pneg_ctxt->CipherCount = cpu_to_le16(3);
>>                   pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_GCM;
>>                   pneg_ctxt->Ciphers[1] = SMB2_ENCRYPTION_AES256_GCM;
>>                   pneg_ctxt->Ciphers[2] = SMB2_ENCRYPTION_AES128_CCM;
>
>Here, AES-256-GCM is second to AES-128-GCM when enable_gcm_256 is
>true, but if AES-256-GCM is still present as one of the ciphers as per
>this snipped, and the server doesn't support AES-128-GCM, shouldn't it
>fall-forward to AES-256-GCM instead of causing an error?

That's correct.

But I also see it working fine against Windows Server 2022.

On server:
   > Set-SmbServerConfiguration -EncryptionCiphers "AES_256_GCM"

On client:
   # mount.cifs -o ...,seal //srv/test /mnt/test
   # cat /sys/module/cifs/parameters/require_gcm_256
   N
   # cat /sys/module/cifs/parameters/enable_gcm_256
   Y
   # grep Encryption /proc/fs/cifs/DebugData
   Encryption: Negotiated cipher (AES256-GCM)

> IOW, I'm
>wondering if there's an issue elsewhere that's preventing the
>AES-256-GCM cipher from being used and reordering would simply
>band-aid the issue.
>
>> so if the server supports AES-256-GCM, the only way to make cifs use it
>> is with 'require_gcm_256', unless you disable AES-128-GCM on the server
>> (as you have observed).
>
>Actually, the issue I'm observing is that _when_ we disable
>AES-128-GCM on the server (Azure Files), mount.cifs on the client is
>failing to mount the share completely _until_ I set require_gcm_256.

Azure sometimes responds with unexpected (sometimes even out of spec)
settings.

I'll setup an Azure Files instance to test this.


Cheers,

Enzo

Re: mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

[Enzo Matsumiya]

On 10/21, Enzo Matsumiya via samba-technical wrote:
>On 10/21, Thomas Spear wrote:
>>This sort-of makes sense as to why it's happening. I can understand
>>some code so what I see here is:
>>
>>> else if (enable_gcm_256) {
>>>                  pneg_ctxt->DataLength = cpu_to_le16(8); /* Cipher Count + 3 ciphers */
>>>                  pneg_ctxt->CipherCount = cpu_to_le16(3);
>>>                  pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_GCM;
>>>                  pneg_ctxt->Ciphers[1] = SMB2_ENCRYPTION_AES256_GCM;
>>>                  pneg_ctxt->Ciphers[2] = SMB2_ENCRYPTION_AES128_CCM;
>>
>>Here, AES-256-GCM is second to AES-128-GCM when enable_gcm_256 is
>>true, but if AES-256-GCM is still present as one of the ciphers as per
>>this snipped, and the server doesn't support AES-128-GCM, shouldn't it
>>fall-forward to AES-256-GCM instead of causing an error?
>
>That's correct.
>
>But I also see it working fine against Windows Server 2022.
>
>On server:
>  > Set-SmbServerConfiguration -EncryptionCiphers "AES_256_GCM"
>
>On client:
>  # mount.cifs -o ...,seal //srv/test /mnt/test
>  # cat /sys/module/cifs/parameters/require_gcm_256
>  N
>  # cat /sys/module/cifs/parameters/enable_gcm_256
>  Y
>  # grep Encryption /proc/fs/cifs/DebugData
>  Encryption: Negotiated cipher (AES256-GCM)
>
>>IOW, I'm
>>wondering if there's an issue elsewhere that's preventing the
>>AES-256-GCM cipher from being used and reordering would simply
>>band-aid the issue.
>>
>>>so if the server supports AES-256-GCM, the only way to make cifs use it
>>>is with 'require_gcm_256', unless you disable AES-128-GCM on the server
>>>(as you have observed).
>>
>>Actually, the issue I'm observing is that _when_ we disable
>>AES-128-GCM on the server (Azure Files), mount.cifs on the client is
>>failing to mount the share completely _until_ I set require_gcm_256.
>
>Azure sometimes responds with unexpected (sometimes even out of spec)
>settings.
>
>I'll setup an Azure Files instance to test this.

So I just tested this and it turns out that Azure is indeed responding
wrong values.

It responds with AES-128-GCM even when only AES-256-GCM is enabled.

Then, since cifs sends AES-128-GCM preferred by default, and Azure
replies with AES-128-GCM, all cifs can do is trust it and start
generating keys + trying to encrypt stuff.

This fails with STATUS_ACCESS_DENIED right on Session Setup
NTLMSSP_AUTH.  I didn't dig deeper so far, but it looks like Azure is
internally prepared to do AES-256-GCM, so it expects AES-256 values.

I don't think there's much to be done from cifs side TBH, so you should
try reaching out to Azure support.


HTH

Enzo

Re: mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

[Andreas Schneider]

On Tuesday, 21 October 2025 19:45:17 Central European Summer Time Steve French 
via samba-technical wrote:
> Good catch - this looks very important.
> 
> Do you remember if Samba support gcm256 signing?

We support AES-128-GMAC signing.

AES256-GCM is for encryption not signing.

-- 
Andreas Schneider                      asn@samba.org
Samba Team                             www.samba.org
GPG-ID:     8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D

Re: mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

[Shyam Prasad N]

On Tue, Oct 21, 2025 at 2:22 AM Thomas Spear <speeddymon@gmail.com> wrote:
>
> First time emailing here, I hope I'm writing to the correct place.
>
> I have an Azure Storage account that has been configured with an Azure
> Files share to allow only AES-256-GCM channel encryption with NTLMv2
> authentication via SMB, and I have a linux client which is running
> Ubuntu 24.04 and has the Ubuntu version of cifs-utils 7.0 installed,
> however after looking at the release notes for the later upstream
> releases I don't think this is specific to this version and rather it
> is an issue in the upstream.
>
> When I try to mount an Azure Files share over SMB, I get a mount error
> 13. However, if I do either of the following, I'm able to successfully
> mount.
>
> 1. Enable AES-128-GCM on the storage account
> 2. Keep AES-128-GCM disabled on the storage account, but enforce
> AES-256-GCM on the client side by running 'echo 1 >
> /sys/module/cifs/parameters/require_gcm_256' after loading the cifs
> module with modprobe.
>
> I can see after running modprobe that the parameter "enable_gcm_256"
> is set to Y (the default value) and the parameter "require_gcm_256" is
> set to N (also the default value)  so I believe the mount command
> should theoretically negotiate with the server, but it seems that no
> matter what I try, unless I require 256 bits on the client side by
> overwriting the "require_gcm_256" parameter, it will never mount
> successfully when the server only allows 256 bits.
>
> It seems like mount.cifs should look at the "enable_gcm_256" parameter
> and if it's "Y" try to use 256 bits at first, falling back to 128 bits
> if the server doesn't support it or throwing an error if the
> "require_gcm_256" parameter is set to the default "N" value, but I
> must admit I don't know if there's some reason that can't be done.
>
> Is this something that could be looked at and possibly improved? I'm
> unfortunately not a developer, but just a user interested in making
> better documentation so if this cannot be improved, I'll go ahead and
> get something written up and share it with downstream teams like Azure
> Files CSI driver -- on that note, I'll appreciate any clarification on
> why setting this specific parameter is required if this can't be
> improved.
>
> Thank you,
>
> Thomas Spear
>

Hi Thomas,

This is documented by Azure Files here:
https://learn.microsoft.com/en-us/troubleshoot/azure/azure-kubernetes/storage/fail-to-mount-azure-file-share#minimumencryption

I suggest you open a support case with Microsoft about this if this is
limiting your use case.

-- 
Regards,
Shyam

Re: mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

[Thomas Spear]

Re-sending as plain-text -- apologies, as my phone seems to only want
to send emails as HTML, so it never made it to the list.

Hi Shyam, thank you for bringing this up. I've seen this link and this
is for Kubernetes, so I've raised a case with Microsoft to improve the
documentation elsewhere to make it more clear, and also mentioned the
testing Enzo did indicated that with AES-128-GCM disabled, the share
is still providing it in the cipher list, which isn't documented
behavior.

I also found this Stack exchange post where someone with a TrueNAS
device encountered the same issue:
https://unix.stackexchange.com/questions/766995/linux-smb-client-failed-to-connect-to-smb-server-forcing-aes-256/800613#800613

When I first found that, before I posted here, I suggested that user
should try enforcing it on the client as this document suggests.

That being said, this seems to only be a requirement for mounting the
share in a Linux VM but based on Enzo's comments, mounting the exact
same share in a Windows VM has no such requirement to enforce
AES-256-GCM on the client side.

N.B. configure 2 storage accounts: one with AES-128 only, and one with
AES-256 only. Attempt to mount both at the same time to different
paths in a Linux VM. One will always be rejected depending on the
client's settings. Then attempt to mount both at the same time to
different drive letters in a Windows VM, and they both mount
successfully.


Thank you,

Thomas

On Fri, Oct 24, 2025 at 7:34 AM Thomas Spear <speeddymon@gmail.com> wrote:
>
> Hi Shyam, thank you for bringing this up. I've seen this link and this is for Kubernetes, so I've raised a case with Microsoft to improve the documentation elsewhere to make it more clear, and also mentioned the testing Enzo did indicated that with AES-128-GCM disabled, the share is still providing it in the cipher list, which isn't documented behavior.
>
> I also found this Stack exchange post where someone with a TrueNAS device encountered the same issue: https://unix.stackexchange.com/questions/766995/linux-smb-client-failed-to-connect-to-smb-server-forcing-aes-256/800613#800613
>
> When I first found that, before I posted here, I suggested that user should try enforcing it on the client as this document suggests.
>
> That being said, this seems to only be a requirement for mounting the share in a Linux VM but based on Enzo's comments, mounting the exact same share in a Windows VM has no such requirement to enforce AES-256-GCM on the client side.
>
> N.B. configure 2 storage accounts: one with AES-128 only, and one with AES-256 only. Attempt to mount both at the same time to different paths in a Linux VM. One will always be rejected depending on the client's settings. Then attempt to mount both at the same time to different drive letters in a Windows VM, and they both mount successfully.
>
>
> Thank you,
>
> Thomas
>
> On Fri, Oct 24, 2025, 3:18 AM Shyam Prasad N <nspmangalore@gmail.com> wrote:
>>
>> On Tue, Oct 21, 2025 at 2:22 AM Thomas Spear <speeddymon@gmail.com> wrote:
>> >
>> > First time emailing here, I hope I'm writing to the correct place.
>> >
>> > I have an Azure Storage account that has been configured with an Azure
>> > Files share to allow only AES-256-GCM channel encryption with NTLMv2
>> > authentication via SMB, and I have a linux client which is running
>> > Ubuntu 24.04 and has the Ubuntu version of cifs-utils 7.0 installed,
>> > however after looking at the release notes for the later upstream
>> > releases I don't think this is specific to this version and rather it
>> > is an issue in the upstream.
>> >
>> > When I try to mount an Azure Files share over SMB, I get a mount error
>> > 13. However, if I do either of the following, I'm able to successfully
>> > mount.
>> >
>> > 1. Enable AES-128-GCM on the storage account
>> > 2. Keep AES-128-GCM disabled on the storage account, but enforce
>> > AES-256-GCM on the client side by running 'echo 1 >
>> > /sys/module/cifs/parameters/require_gcm_256' after loading the cifs
>> > module with modprobe.
>> >
>> > I can see after running modprobe that the parameter "enable_gcm_256"
>> > is set to Y (the default value) and the parameter "require_gcm_256" is
>> > set to N (also the default value)  so I believe the mount command
>> > should theoretically negotiate with the server, but it seems that no
>> > matter what I try, unless I require 256 bits on the client side by
>> > overwriting the "require_gcm_256" parameter, it will never mount
>> > successfully when the server only allows 256 bits.
>> >
>> > It seems like mount.cifs should look at the "enable_gcm_256" parameter
>> > and if it's "Y" try to use 256 bits at first, falling back to 128 bits
>> > if the server doesn't support it or throwing an error if the
>> > "require_gcm_256" parameter is set to the default "N" value, but I
>> > must admit I don't know if there's some reason that can't be done.
>> >
>> > Is this something that could be looked at and possibly improved? I'm
>> > unfortunately not a developer, but just a user interested in making
>> > better documentation so if this cannot be improved, I'll go ahead and
>> > get something written up and share it with downstream teams like Azure
>> > Files CSI driver -- on that note, I'll appreciate any clarification on
>> > why setting this specific parameter is required if this can't be
>> > improved.
>> >
>> > Thank you,
>> >
>> > Thomas Spear
>> >
>>
>> Hi Thomas,
>>
>> This is documented by Azure Files here:
>> https://learn.microsoft.com/en-us/troubleshoot/azure/azure-kubernetes/storage/fail-to-mount-azure-file-share#minimumencryption
>>
>> I suggest you open a support case with Microsoft about this if this is
>> limiting your use case.
>>
>> --
>> Regards,
>> Shyam