Access denied to azure SMB file share over public network

Question

Access denied to azure SMB file share over public network

Admin D. Horton 0

I have an azure file share that I cannot map to as I am getting access denied.

I have the public IP of our firewall in the network settings to allow access.
I am using AD/Entra user access control
I am using the maximum SMB security setting
All our computers are windows 11 and are using SMB 3.1.1 to all our local shares
I have the share domain joined
I have role-based access setup
I have storage blob data owner and storage file data smb admin roles.
I have users with storage file data smb share reader role
The connect script shows a successful test connection, but authentication keeps failing with access denied regardless of the role assigned, and I am the owner.
I can browse the file share via the portal, but that is all.

What am I missing

Jerald Felix 10,890 Reputation points

2026-03-03T16:59:39.9133333+00:00
Hello Admin D. Horton,

Thanks for raising this question in Azure Q&A forum.

Azure Files SMB shares are never accessible over public internet they require either private endpoints or VPN/ExpressRoute connectivity. The "access denied" error you're seeing when trying to connect to \\<storageaccount>.file.core.windows.net\<sharename> from public internet is expected and by design.

Why SMB over public internet doesn't work

Azure Files SMB shares use port 445 which is blocked by nearly all ISPs worldwide (legacy NetBIOS/SMB1 security concerns). Even if port 445 were open, Azure Storage enforces identity-based authentication for SMB access, which requires:

Azure AD DS authentication (domain-joined credentials)

Storage Account Key (not recommended for production)

SAS token (limited scope)

None of these authentication methods work reliably over public internet due to security policies.learn.microsoft+1

The correct production solution — Private Endpoint

Step 1: Create a Private Endpoint for your File Share

bash # Create private endpoint

Step 2: Configure DNS Create a Private DNS Zone privatelink.file.core.windows.net and link the A record.

Step 3: Connect from your VNet

text \\fileSharePE.privatelink.file.core.windows.net\myShare

Alternative Solutions (if Private Endpoint not feasible)

1. Azure Bastion + Jump Host

Deploy a Windows VM in the same VNet as your storage account

Use Azure Bastion to RDP to the jump host

Mount the SMB share from the jump host

2. Azure VPN Gateway

Connect your on-premises network to Azure via Site-to-Site VPN

Mount shares from on-premises machines

3. REST API over HTTPS (port 443) For programmatic access, use Azure Files REST API instead of SMB — works over public internet:

python from

4. Azure Files Sync (for hybrid scenarios) Sync Azure Files to Windows Server on-premises, then access SMB locally.

Quick Test to Verify

Test connectivity from an Azure VM in the same region:

powershell # From Azure VM (same region as storage)

If it succeeds from Azure VM but fails from your local machine, confirms ISP port 445 blocking.

If it helps kindly accept the answer.

Best Regards,

Jerald Felix
Admin D. Horton 0 Reputation points

2026-03-04T17:46:04.8566667+00:00

When I use the command, "net use Z: \crblobs.file.core.windows.net\marketing-archive /user:Azure\crblobs 7qHZodpWJ2....." using the storage key from the storage account crblobs, I get the error "System error 86 has occurred.

The specified network password is not correct." If I attempt to change the ACLs via the azure portal (https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-configure-file-level-permissions) by going to the file share, the "Manage Access" option is completely missing. I am the owner of the share and have the Storage File Data SMB Admin role.
Ravi Varma Mudduluru 7,575 Reputation points Microsoft External Staff Moderator

2026-03-05T00:42:03.73+00:00

Hello @ Admin D. Horton.

Thanks for the confirmation

we will check internally and get back to you.
Ravi Varma Mudduluru 7,575 Reputation points Microsoft External Staff Moderator

2026-03-05T03:49:40.4433333+00:00
Hello @ Admin D. Horton

I noticed that the command entered in CMD is slightly incorrect. After net use Z: you are using a single backslash (\), but the correct command should have two backslashes (\\), as shown in the command shared earlier by Venkatesan.

Please also verify the following:

The storage account key is copied correctly.

The username format is correct

The file share path is correct.

If the issue still persists after verifying the above, please share a screenshot of the CMD error via private message along with the requested details in the private message. so, we can investigate further.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Admin D. Horton 0 Reputation points

2026-03-05T15:05:08.2333333+00:00

Not sure why it didn't paste correctly, the command I was using is "net use Z: \crblobs.file.core.windows.net\marketing-archive /user:Azure\crblobs 7qHZo..."

Venkatesan S 4,315 Microsoft External Staff Moderator

Hi Admin D. Horton,

Could you please try the below PowerShell command?

$connectTestResult = Test-NetConnection -ComputerName venkattest326.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
    # Save the password so the drive will persist on reboot
    cmd.exe /C "cmdkey /add:`"<Your storage account name>.file.core.windows.net`" /user:`"localhost\venkattest326`" /pass:`"<Your storage account key>`""
    # Mount the drive
    New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<Storage account name>.file.core.windows.net\<Files hare name>" -Persist
} else {
    Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."
}

Let me know if you get any errors.

Admin D. Horton 0 Reputation points

2026-03-05T19:15:51.6166667+00:00

I am currently working on building out my VNet, Gateway, IPSec connections so that I am not going over the internet. Since I do not have any VMs on the VNet, do I need to create a private endpoint for the file share or storage resource?
Venkatesan S 4,315 Reputation points Microsoft External Staff Moderator

2026-03-05T19:59:41.1633333+00:00

Hi Admin D. Horton,

Could you please copy directly from portal like below and run in your environment?

Your storage account -> Fileshare -> connect ->copy the script and run in your environment.

I am currently working on building out my VNet, Gateway, IPSec connections so that I am not going over the internet. Since I do not have any VMs on the VNet, do I need to create a private endpoint for the file share or storage resource? **

No, you don't need private endpoints right now. Private endpoints are only required when:

VMs inside your VNet need to access the file share via private IP (10.x.x.x)

You want to completely eliminate public endpoint traffic.

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Admin D. Horton 0 Reputation points

2026-03-05T20:07:12.9633333+00:00

When I copy the script from the connect window, I still get access denied. That script assumes account vs role based access and does not use a share key. A previous comment was that I must set up the NTFS access, however, I cannot get any connection to the file share that allows me to setup the NTFS access. Another post stated that I cannot use public access to a file share, however, MS contradicts that statement if you are using SMB 3.1. I now have a vnet, vpn gateway, and vpn tunnels that are up. I also have created a private end point. I am now figuring out how to connect/map to that private endpoint.
Venkatesan S 4,315 Reputation points Microsoft External Staff Moderator

2026-03-05T22:10:09.3733333+00:00
Admin D. Horton
The "Connect" script from the portal generates role-based auth commands (Entra ID identities) that fail because NTFS permissions aren't set yet, but you can't set NTFS permissions because you can't mount the share to access the ACL interface. With your VPN tunnel up and private endpoint created, let's break this cycle.

The Core Issue Azure Files requires BOTH share-level RBAC permissions + NTFS ACLs, but the portal's "Connect" script assumes RBAC is fully configured. Your Storage File Data SMB Admin role exists, but NTFS is missing at the share root.

Private Endpoint Mapping (Your Current Path) Since you have VNet + VPN + private endpoint:

# 1. Confirm private DNS resolution (critical)

If Private DNS Still Points Public Your private endpoint needs a Private DNS Zone linked to your VNet:

privatelink.file.core.windows.net (linked to your VNet) A record: crblobs → 10.x.x.x (private endpoint IP)

Break the NTFS Catch-22 - Storage Account Key Method Temporarily bypass role-based auth to set NTFS:

# 1. Get COMPLETE fresh key (Storage Account > Access keys > Regenerate key1)

Why Storage Key Works:

Bypasses Entra auth entirely

Grants full root access to set ACLs for your Entra users

Works over VPN tunnel (public endpoint) or private endpoint

Unlocks portal "Manage Access" UI

Public Access + SMB 3.1.1 is Valid :

Microsoft docs confirm SMB 3.1.1 encryption makes public endpoint secure over VPN. Private endpoint is bonus security, not requirement.

Sequence to Success

Key mount > Set NTFS ACLs (5 minutes)

Unmount key session (net use Z: /delete)

Role-based mount (net use Z: "\\crblobs.file.core.windows.net\marketing-archive")

Verify Entra auth works with NTFS now present

Once key mount succeeds > Portal fix File share > Browse > Switch to "Storage account key" → "Manage Access" appears.

The private endpoint is great long-term, but storage account key mount first breaks your permission deadlock immediately.

Reference:

Mount SMB Azure File Share on Windows | Microsoft Learn

Configure Directory and File Level Permissions for Azure Files | Microsoft Learn

Also, could you please share the requested details Via private message?

Answer accepted by question author

0 additional answers

Your answer

Admin D. Horton 0 Reputation points

2026-03-04T17:46:04.8566667+00:00

When I use the command, "net use Z: \crblobs.file.core.windows.net\marketing-archive /user:Azure\crblobs 7qHZodpWJ2....." using the storage key from the storage account crblobs, I get the error "System error 86 has occurred.

The specified network password is not correct." If I attempt to change the ACLs via the azure portal (https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-configure-file-level-permissions) by going to the file share, the "Manage Access" option is completely missing. I am the owner of the share and have the Storage File Data SMB Admin role.
Ravi Varma Mudduluru 7,575 Reputation points Microsoft External Staff Moderator

2026-03-05T00:42:03.73+00:00

Hello @ Admin D. Horton.

Thanks for the confirmation

we will check internally and get back to you.
Ravi Varma Mudduluru 7,575 Reputation points Microsoft External Staff Moderator

2026-03-05T03:49:40.4433333+00:00

Hello @ Admin D. Horton

I noticed that the command entered in CMD is slightly incorrect. After net use Z: you are using a single backslash (\), but the correct command should have two backslashes (\\), as shown in the command shared earlier by Venkatesan.

Please also verify the following:

The storage account key is copied correctly.

The username format is correct

The file share path is correct.

If the issue still persists after verifying the above, please share a screenshot of the CMD error via private message along with the requested details in the private message. so, we can investigate further.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Admin D. Horton 0 Reputation points

2026-03-05T15:05:08.2333333+00:00

Not sure why it didn't paste correctly, the command I was using is "net use Z: \crblobs.file.core.windows.net\marketing-archive /user:Azure\crblobs 7qHZo..."
Venkatesan S 4,315 Reputation points Microsoft External Staff Moderator

2026-03-05T19:02:35.59+00:00

Hi Admin D. Horton,

Could you please try the below PowerShell command?

$connectTestResult = Test-NetConnection -ComputerName venkattest326.file.core.windows.net -Port 445 if ($connectTestResult.TcpTestSucceeded) { # Save the password so the drive will persist on reboot cmd.exe /C "cmdkey /add:`"<Your storage account name>.file.core.windows.net`" /user:`"localhost\venkattest326`" /pass:`"<Your storage account key>`"" # Mount the drive New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<Storage account name>.file.core.windows.net\<Files hare name>" -Persist } else { Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port." }

Let me know if you get any errors.
Admin D. Horton 0 Reputation points

2026-03-05T19:15:51.6166667+00:00

I am currently working on building out my VNet, Gateway, IPSec connections so that I am not going over the internet. Since I do not have any VMs on the VNet, do I need to create a private endpoint for the file share or storage resource?
Venkatesan S 4,315 Reputation points Microsoft External Staff Moderator

2026-03-05T19:59:41.1633333+00:00

Hi Admin D. Horton,

Could you please copy directly from portal like below and run in your environment?

Your storage account -> Fileshare -> connect ->copy the script and run in your environment.

I am currently working on building out my VNet, Gateway, IPSec connections so that I am not going over the internet. Since I do not have any VMs on the VNet, do I need to create a private endpoint for the file share or storage resource? **

No, you don't need private endpoints right now. Private endpoints are only required when:

VMs inside your VNet need to access the file share via private IP (10.x.x.x)

You want to completely eliminate public endpoint traffic.

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Admin D. Horton 0 Reputation points

2026-03-05T20:07:12.9633333+00:00

When I copy the script from the connect window, I still get access denied. That script assumes account vs role based access and does not use a share key. A previous comment was that I must set up the NTFS access, however, I cannot get any connection to the file share that allows me to setup the NTFS access. Another post stated that I cannot use public access to a file share, however, MS contradicts that statement if you are using SMB 3.1. I now have a vnet, vpn gateway, and vpn tunnels that are up. I also have created a private end point. I am now figuring out how to connect/map to that private endpoint.

Answer 1

Hi Admin D. Horton,

Thanks for reaching out in Microsoft Q&A forum,

When you are able to browse the Azure file share in the portal, and Test-NetConnection succeeds, but mapping the drive returns “Access Denied”, this typically indicates that networking is functioning correctly and the issue lies with authentication or authorization.

Based on your description, the storage account is reachable, the firewall is correctly configured, and SMB 3.1.1 is in use. The failure is occurring during identity validation or permission enforcement.

Azure Files with AD DS or Microsoft Entra authentication requires two permission layers:

1. Share-level (Azure RBAC)

Assign roles like Storage File Data SMB Share Reader, Contributor, Elevated Contributor, or Administrator.

These roles control access at the Azure level (control plane).

2. NTFS permissions (inside the file share)

You must configure NTFS ACLs on the root folder of the share.
RBAC alone is not enough without NTFS permissions, users will get **“**Access Denied”, even if authentication succeeds or they are subscription owners.

To confirm whether the issue is identity-related, temporarily map the drive using the storage account key:

net use Z: \\<storageaccount>.file.core.windows.net\<sharename> /user:Azure\<storageaccount> <storagekey>

If this works, the issue is definitively related to AD/Entra authentication or NTFS permissions.

User's image

You need to enable NTLM v2 authentication mechanism.

Reference:

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Admin D. Horton 0 Reputation points

2026-03-06T15:45:11.83+00:00

I had to change the file share access permissions for SMB to compatible settings instead of secure.

Share via

Access denied to azure SMB file share over public network

0 additional answers

Your answer