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=10.5.142.10,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.
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?
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.
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
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
(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!
Created attachment 18127 [details] TCPDUMP
Attached is the TCPDUMP
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.
And check the network configuration for that storage account