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 at 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