Bug 15480 - Mounting Azure Fles Share using cifs-utils fails
Summary: Mounting Azure Fles Share using cifs-utils fails
Status: NEW
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: user space tools (show other bugs)
Version: 5.x
Hardware: x64 Linux
: P5 major
Target Milestone: ---
Assignee: Jeff Layton
QA Contact: cifs QA contact
Depends on:
Reported: 2023-09-20 13:09 UTC by Yonz
Modified: 2023-09-27 14:55 UTC (History)
0 users

See Also:

TCPDUMP (2.49 KB, application/octet-stream)
2023-09-27 14:13 UTC, Yonz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yonz 2023-09-20 13:09:34 UTC
we are trying to use CIFS-UTILS (Version 6 included with Ubuntu 22.04 as well as Version 7 installed from  https://www.samba.org/ftp/linux-cifs/cifs-utils/cifs-utils-7.0.tar.bz2 ) to mount a share from Azure Files. 

edgedevice@edgedevice-8CG8360GN5:~/cifs/cifs-utils-7.0$ sudo mount -v -t cifs "//sa32310601.privatelink.file.core.windows.net/prodfileproxy" /mnt/azure_test -o "username=S1003368,domain=tk-materials.com,password=*********************,vers=3.11,sec=ntlmssp,serverino,nosharesock,actimeo=30,mfsymlinks"
mount.cifs kernel mount options: ip=,unc=\\sa32310601.privatelink.file.core.windows.net\prodfileproxy,vers=3.11,sec=ntlmssp,serverino,nosharesock,actimeo=30,mfsymlinks,user=S1003368,domain=tk-materials.com,pass=********
mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

DMESG Reports the following:
[83672.820955] CIFS: VFS: cifs_mount failed w/return code = -2
[84042.391251] CIFS: Status code returned 0xc0000016 STATUS_MORE_PROCESSING_REQUIRED
[84042.429097] CIFS: Status code returned 0xc0000034 STATUS_OBJECT_NAME_NOT_FOUND
[84042.429126] CIFS: VFS: \\sa32310601.privatelink.file.core.windows.net Send error in SessSetup = -2

Mounting the same share from a standalone Windows 10 machine Works. As well as using the Samba smbclient.
Comment 1 Paulo Alcantara 2023-09-21 01:46:41 UTC
cifs-utils version should be irrelevant as it seems a kernel bug.

What kernel version is it?

Can you reproduce it with latest stable kernel version (v6.5.4) from kernel.org?
Comment 2 Yonz 2023-09-21 07:31:05 UTC
Sure. I'll give it a go later.

Ontoher thing we observed, is that when using the Storage Account Access Key, we are able mount the Azure Share. However, when we use App Registration or a normal AADS User, it fails.
Comment 3 Yonz 2023-09-21 07:32:33 UTC
Kernel is 
5.15.0-83-generic #92-Ubuntu SMP Mon Aug 14 09:30:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Comment 4 Steve French 2023-09-22 00:13:57 UTC
Since this might involve looking at (Azure) server logs, it might be better to open this as a Microsoft Azure support case to explore what is happening
Comment 5 Ralph Böhme 2023-09-22 03:37:35 UTC
(In reply to Steve French from comment #4)
Maybe lets just start with a network trace? Yonz, can you please do a network capture port 445 and upload it to the bugreport? Thanks!
Comment 6 Yonz 2023-09-27 14:13:25 UTC
Created attachment 18127 [details]
Comment 7 Yonz 2023-09-27 14:14:13 UTC
Attached is the TCPDUMP
Comment 8 Steve French 2023-09-27 14:54:32 UTC
The trace you sent shows an access denied on SMB3.1.1 session setup (NTLMv2/NTLMSSP not Kerberos).   The username looks plausible (based on the netname context sent, it matches that), but the obvious question is the password (either the one stored in your credentials file or passed on mount depending on how you mount this).  You can also verify that the credentials are ok by using smbclient //server/share -U username%password

If that also fails then access to the network may be disabled from some subnets so best to contact Azure support since they can look at the storage account and networking configuration.
Comment 9 Steve French 2023-09-27 14:55:08 UTC
And check the network configuration for that storage account