From: Thomas Spear <speeddymon@gmail.com>
To: Shyam Prasad N <nspmangalore@gmail.com>
Cc: linux-cifs@vger.kernel.org
Subject: Re: mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options
Date: Fri, 24 Oct 2025 13:24:19 -0500 [thread overview]
Message-ID: <CAEAsNvQLEjJY0gCLacnKhar2z_w5Dp+xmGms=m38xp_cgq-+bw@mail.gmail.com> (raw)
In-Reply-To: <CAEAsNvSuhhJyqWkpwHBdmJZ6mx5tzD2x2hUmxCyjLf50BamsuA@mail.gmail.com>
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
prev parent reply other threads:[~2025-10-24 18:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-20 20:51 mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options Thomas Spear
2025-10-21 17:45 ` Steve French
2025-10-21 18:30 ` Enzo Matsumiya
2025-10-21 18:58 ` Thomas Spear
2025-10-21 19:15 ` Enzo Matsumiya
2025-10-21 19:47 ` Enzo Matsumiya
2025-10-22 7:02 ` Andreas Schneider
2025-10-24 8:18 ` Shyam Prasad N
[not found] ` <CAEAsNvSuhhJyqWkpwHBdmJZ6mx5tzD2x2hUmxCyjLf50BamsuA@mail.gmail.com>
2025-10-24 18:24 ` Thomas Spear [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEAsNvQLEjJY0gCLacnKhar2z_w5Dp+xmGms=m38xp_cgq-+bw@mail.gmail.com' \
--to=speeddymon@gmail.com \
--cc=linux-cifs@vger.kernel.org \
--cc=nspmangalore@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).