Azure Files - System error 53
Asked Answered
S

3

10

I am trying to use Azure Files and I am getting the following System error 53. Any ideas?enter image description here

Shrive answered 29/9, 2015 at 17:54 Comment(0)
T
12

There are two possible reasons for getting this error if you are trying to mount your Azure file shares from outside of Azure Datacenter via SMB 3.0.

  1. Your client OS needs support SMB 3.0, for example use Windows 8, Windows 10, Windows Server 2012.

  2. The port 445 (TCP Outbound) needs to be opened by your ISP or firewall. The SMB protocol is dependent on this port if you mount from outside of Azure Datacenter, and I do notice some ISP blocked this port (e.g. Comcast).

You can refer to the links below to do a self-check on the port by yourself.

http://poshcode.org/2514

http://powershell.com/cs/media/p/4063.aspx

Trevino answered 29/9, 2015 at 18:40 Comment(7)
I want to confirm that there is no requirement for 445 inbound to be open. And ask if any suggestion on how to get U-Version with dynamic IP to support this. ThxJamijamie
I can confirm no 445 inbound needed for client when mount a SMB file share, this is defined in SMB spec.Trevino
Thx Jason. I certainly did not think so but the forums are full of such misinformation. Can you provide any suggestions on dealing with AT&T? I have a biz account with them but this article dslreports.com/faq/13747 says they block 445 outbound and I have had zero luck with AT&T support even understanding what I'm talking about but for $100/hour they would open a support ticket.Jamijamie
If your router has a NetBIOS filter active, deactivate it. It might block TCP 445 outgoing.Libido
Using a network trace, it seems that when I issue the NET USE command, there are requests issued to TCP port 445, 139, and then 80 on the azure server. The connections on ports 455 and 139 time out (perhaps due to my router or Comcast), but then the TCP port 80 connect succeeds. However the HTTP request issued OPTIONS <sharename> HTTP1.1 repeatedly fails with 400 - The requested URI does not represent any resource on the server..Legman
I note that while the port 80 request is WebDAV and not technically SMB, it's a bit sad that Azure File Storage doesn't support the fallback protocol that Win10 uses for the NET USE command.Legman
Both of the links in this answer appear to now be dead.Accepter
E
0

There is another explanation for this error.

If you try to connect to that network share from your machine as opposed to connecting from an Azure VM (or role).

The network share is only visible to Azure VMs. There may even be one more restriction - the share and the VM must live in the same Azure region.

Sources:

My experience, hitting this problem on my laptop (and seeing it work, using the same cmd, in an Azure VM).

Also, this: https://blogs.msdn.microsoft.com/windowsazurestorage/2014/05/12/introducing-microsoft-azure-file-service/ :

Once your share is created, it can be accessed via the SMB or REST protocol from any Azure node (VM/Worker/Web role) hosted in the same region as the storage account hosting the share.

Ev answered 21/1, 2017 at 0:35 Comment(1)
Pretty sure you're incorrect on that being a restriction. I ran across this question because I was having trouble connecting, but I think the real answer is the already accepted one...many/most ISPs block outgoing port 445 traffic. I wasn't able to connect from my home machine (comcast), but was able to connect just fine from my work machine.Luing
M
0

This is the only thing that worked for me:

Change this registry key to a value of 3

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

For more information, see the LmCompatibilityLevel topic on TechNet.

Got this solution from this MS docs

Medley answered 1/2, 2019 at 4:18 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.