From: Thomas Spear <speeddymon@gmail.com>
To: linux-cifs@vger.kernel.org
Subject: mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options
Date: Mon, 20 Oct 2025 15:51:20 -0500 [thread overview]
Message-ID: <CAEAsNvQmV=xFsU-4jn9zC2DYoAUjXTS3qcsGNe7XUZEEXg1cLg@mail.gmail.com> (raw)
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
next reply other threads:[~2025-10-20 20:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-20 20:51 Thomas Spear [this message]
2025-10-21 17:45 ` mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options 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
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='CAEAsNvQmV=xFsU-4jn9zC2DYoAUjXTS3qcsGNe7XUZEEXg1cLg@mail.gmail.com' \
--to=speeddymon@gmail.com \
--cc=linux-cifs@vger.kernel.org \
/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).