4

I'm trying to connect to SMB share on my TrueNAS from my Fedora. It works well until I decided to enable encryption of SMB data. I put following in the service config on TrueNAS (global settings)

unix extensions = yes server signing = required client smb encrypt = required server smb3 encryption algorithms = -AES-128-GCM -AES-128-CCM

and following in the particular SMB share (per-share settings)

server smb encrypt = required

Then, I tried to mount the SMB share by

sudo mount -t smb3 -o cred=<my_cred_file>,uid=1000,gid=1000,mfsymlinks //<TrueNAS IP>/NAS /mnt/NAS

and, boom, mount error(13): Permission denied.

In dmesg, it says

[112496.066462] CIFS: Attempting to mount //<TrueNAS IP>/NAS [112496.085283] CIFS: VFS: sign fail cmd 0x3 message id 0x3 [112496.085287] CIFS: VFS: \\<TrueNAS IP> SMB signature verification returned error = -13 [112496.085290] CIFS: VFS: \\<TrueNAS IP> failed to connect to IPC (rc=-13) [112496.085294] CIFS: VFS: session 00000000639775cf has no tcon available for a dfs referral request [112496.085480] CIFS: VFS: sign fail cmd 0x3 message id 0x4 [112496.085481] CIFS: VFS: \\<TrueNAS IP> SMB signature verification returned error = -13 [112496.085684] CIFS: VFS: sign fail cmd 0x2 message id 0x5 [112496.085687] CIFS: VFS: \\<TrueNAS IP> SMB signature verification returned error = -13 [112496.085690] CIFS: VFS: \\<TrueNAS IP> __cifs_put_smb_ses: Session Logoff failure rc=-13 [112496.085700] CIFS: VFS: cifs_mount failed w/return code = -13

If I remove the line forcing AES-256 (disallowing AES-128):

server smb3 encryption algorithms = -AES-128-GCM -AES-128-CCM

the mount command will work fine.

However, even if I keep the forcing AES-256 config, I can still connect to my SMB share from Finder on macOS and iOS, and from Dolphin on KDE (I use fedora with KDE).

So, does smbclient in cli not support AES-256 encryption at all? Or can I turn something on and make the mount work totally fine?

Btw, smbclient --version gives Version 4.19.4.

Update: Following is the verbose output of mount as suggested by comment.

$ sudo mount -t smb3 --verbose -o cred=<my_cred_file>,uid=1000,gid=1000,mfsymlinks //<TrueNAS IP>/NAS /mnt/NAS mount.smb3 kernel mount options: ip=<TrueNAS IP>,unc=\\<TrueNAS IP>\NAS,mfsymlinks,uid=1000,gid=1000,user=<My Username>,pass=******** mount error(13): Permission denied Refer to the mount.smb3(8) manual page (e.g. man mount.smb3) and kernel log messages (dmesg)

Update: Tried different sec options:

  • krb5/krb5i:
    • mount verbose outputs: 
      $ sudo mount -t smb3 --verbose -o cred=<my_cred_file>,uid=1000,gid=1000,mfsymlinks,sec=<krb5/krb5i> //<TrueNAS IP>/NAS /mnt/NAS mount.smb3 kernel mount options: ip=<TrueNAS IP>,unc=\\<TrueNAS IP>\NAS,mfsymlinks,sec=<krb5/krb5i>,uid=1000,gid=1000,user=<My Username>,pass=******** mount.smb3 kernel mount options: ip=<TrueNAS IP>,unc=\\<TrueNAS IP>\NAS,mfsymlinks,sec=<krb5/krb5i>,uid=1000,cruid=1000,gid=1000,user=<My Username>,pass=******** mount error(126): Required key not available Refer to the mount.smb3(8) manual page (e.g. man mount.smb3) and kernel log messages (dmesg)
    • dmesg outputs: 
      [190212.841620] CIFS: Attempting to mount //<TrueNAS IP>/NAS [190212.851741] CIFS: VFS: unknown or missing server auth type, use krb5 [190212.861466] CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed [190212.861472] CIFS: VFS: \\<TrueNAS IP> Send error in SessSetup = -126 [190212.861487] CIFS: VFS: cifs_mount failed w/return code = -126
  • ntlm/ntlmi:
    • mount verbose outputs: 
      $ sudo mount -t smb3 --verbose -o cred=<my_cred_file>,uid=1000,gid=1000,mfsymlinks,sec=<ntlm/ntlmi> //<TrueNAS IP>/NAS /mnt/NAS mount.smb3 kernel mount options: ip=<TrueNAS IP>,unc=\\<TrueNAS IP>\NAS,mfsymlinks,sec=ntlm,uid=1000,gid=1000,user=<My Username>,pass=******** mount error(22): Invalid argument Refer to the mount.smb3(8) manual page (e.g. man mount.smb3) and kernel log messages (dmesg)
    • dmesg outputs: 
      [190683.752148] bad security option: <ntlm/ntlmi> [190683.752170] CIFS: VFS: bad security option: <ntlm/ntlmi>
  • ntlmv2/ntlmv2i/ntlmssp/ntlmsspi: These four options makes no difference in mount verbose output or dmesg compared with not specifying any sec option.

Update: Tried cifs with specifying vers option:

  • vers=2.0:
    • mount output: 
      mount.cifs kernel mount options: ip=<TrueNAS IP>,unc=\\<TrueNAS IP>\NAS,mfsymlinks,vers=2.0,uid=1000,gid=1000,user=<My Username>,pass=******** mount error(13): Permission denied Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
    • dmesg: 
      [281141.068174] CIFS: Attempting to mount //<TrueNAS IP>/NAS [281141.085261] CIFS: VFS: \\<TrueNAS IP> smb2_calc_signature: Could not find session [281141.085286] CIFS: VFS: \\<TrueNAS IP> __cifs_put_smb_ses: Session Logoff failure rc=-2 [281141.085298] CIFS: VFS: cifs_mount failed w/return code = -13
  • vers=1.0:

    • mount output:

      mount.cifs kernel mount options: ip=<TrueNAS IP>,unc=\\<TrueNAS IP>\NAS,mfsymlinks,vers=1.0,uid=1000,gid=1000,user=<My Username>,pass=******** mount error(95): Operation not supported Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

      I removed mfsymlinks (which is not supported in SMB1.0?) but the output is the same.

    • demsg:

      [281295.220579] Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [281295.220601] CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [281295.220609] CIFS: Attempting to mount //<TrueNAS IP>/NAS [281295.231815] CIFS: VFS: cifs_mount failed w/return code = -95
Improve this question
8
  • 1
    Add the -vvv switch to the mount command and add the output to the question. Do not post it in the comments. Commented Jan 16, 2024 at 0:28
  • @NasirRiley I think -vvv is the same as --verbose? Whatever, I updated my question. Commented Jan 16, 2024 at 12:03
  • If you add sec=ntlmv2, sec=ntlmv2i, sec=ntlmssp, or sec=ntlmsspi as in cred=<my_cred_file>,sec=ntlm#,uid=1000,gid=1000,mfsymlinks what result do you get? Commented Jan 16, 2024 at 12:53
  • @NasirRiley As updated in my question, these four options makes no difference in mount verbose output or dmesg compared with not specifying any sec option. Commented Jan 16, 2024 at 18:27
  • You tried ntlm and ntlmi which are different. I knew that they would give that output which is why I didn't include them. Use the options that I specified and add the output to the question. Commented Jan 16, 2024 at 22:30

3 Answers 3

Reset to default
3

I believe I know the cause and solution here. There seems to potentially be a bug in the CIFS client as of the time I am writing this, wherein if you do not require AES-256-GCM on the client side, then the client fails to connect to the server even though the server may only have AES-256-GCM enabled.

Troubleshooting steps:

  1. On the client side, after running modprobe cifs if you then run cat /sys/module/cifs/parameters/enable_gcm_256, you can see that it is set to Y but if you run cat /sys/module/cifs/parameters/require_gcm_256, you can see that it is set to N.
  2. If you then run (again on the client side) echo 1 > /sys/module/cifs/parameters/require_gcm_256 and echo "options cifs require_gcm_256=1" > /etc/modprobe.d/cifs.conf you should then be able to mount the SMB share properly with your global setting server smb3 encryption algorithms = -AES-128-GCM -AES-128-CCM

Assuming that this works, it confirms my suspicions that this is a bug in the CIFS client.

I came across this issue while digging into the exact same error mounting an Azure Files share which had only AES-256-GCM enabled while using the Azure Files CSI driver for Kubernetes, and Microsoft's documentation states this is necessary in the case that AES-128-GCM is disallowed on the server side, so I suspect that since this is affecting even users who are not using Azure Files, this is a bug in the CIFS client itself.

Edit: After talking with CIFS developers on the linux-cifs mailing list, this is a two-part issue.

  1. Azure Files: With a file share configured for AES-256-GCM only, the share still responds with AES-128-GCM in the ciphers, but then rejects the connection. I've opened a case with Azure on this and they are investigating. It's potentially possible, given the year this question was opened, that this is also the case on the TrueNAS device that OP is using.

  2. On the client side, the CIFS client has a cipher order that prefers AES-128-GCM by default. In other words, if a server presents AES-128-GCM as an option, the client will by default try to negotiate AES-128-GCM even if AES-256-GCM is offered. This was done originally to maintain better performance in low powered environments (embedded systems like Raspberry Pi and whatnot) where AES-256-GCM would have, at the time, been responsible for performance impacts.

Requiring GCM 256 as I mentioned above should resolve this issue until a future change on clients will amend the cipher order to prefer AES-256-GCM, and a future change on servers will ensure AES-128-GCM is not presented when it has been disabled.

Improve this answer
2

I have seen this exact scenario happen when the system is missing the required cifs-utils packages. It can come with base packages to see cifs\smb but still be missing the ones you need to connect read\write with encryption.

If you are missing the libraries\packages you need then it doesn't matter what options you add to the command, it will never work.

Fedora

sudo dnf install cifs-utils

Debian

sudo apt install cifs-utils
Improve this answer
1

Asked 1 year, 8 months ago

my experience with this with RHEL-7, and RHEL-8 even, is the encryption algorithms AES-256-GCM and/or AES-256-GCM were not supported in those earlier versions of samba.

in RHEL-9.6 {like within the last few months when i first jumped to rhel-9.6 on some systems} I found a lot of the following items in smb.conf began to work that didn't previously.

here's what I have working in RHEL-9.6 with no complaints from a service smb status -l fwiw

[global] server role = standalone security = user passdb backend = tdbsam printing = bsd printcap name = /dev/null load printers = no cups options = raw # default deadtime is 10080 minutes, make 5 min deadtime = 5 client min protocol = SMB3_11 server smb encrypt = required server signing = mandatory client signing = required client ipc signing = required client smb encrypt = required server min protocol = SMB3_11 server smb3 encryption algorithms = AES-128-GCM, AES-128-CCM, AES-256-GCM, AES-256-CCM server smb3 signing algorithms = AES-128-GMAC, AES-128-CMAC, HMAC-SHA256 client smb3 encryption algorithms = AES-128-GCM, AES-128-CCM, AES-256-GCM, AES-256-CCM # client use kerberos = < off | desired | required > client use kerberos = required # kerberos encryption types = < all | strong | legacy > kerberos encryption types = strong log file = /var/log/samba/log [homes] comment = Home Directories valid users = %S, %D%w%S browseable = No read only = No inherit acls = Yes create mask = 600 directory mask = 700 [data] comment = data path = /data read only = No inherit acls = Yes create mask = 660 directory mask = 770

I believe the above is the best you can do regarding security choices in smb.conf versus default, this is when I was interested in finding out around late 2024; dunno if new things have become available in samba since.

securing SAMBA smb.conf best parameters

these items I have commented out in RHEL-8.10 with samba 4.19.4-9.el8_10.x86_64 because they didn't work:

# server min protocol = SMB3_11 unknown parameter upon service start in rhel-8.10 # server smb3 encryption algorithms = AES-128-GCM, AES-128-CCM, AES-256-GCM, AES-256-CCM # server smb3 signing algorithms = AES-128-GMAC, AES-128-CMAC, HMAC-SHA256 # client smb3 encryption algorithms = AES-128-GCM, AES-128-CCM, AES-256-GCM, AES-256-CCM # client use kerberos = < off | desired | required > # kerberos encryption types = < all | strong | legacy >

in doing service smb status -l the long listing is where/how you will see specifically what is wrong and not working/supported in your smb.conf

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.