Forum Discussion

Adrian Chirtoc's avatar
Aug 28, 2025

Storage not reachable from network using service endpoint.

Hello,

Here is the situation.

The storage (File share )had assigned networks to allow access.

We refresh some changes in the NSG from the network using bicep code ( Outbound was permitted all- no change. Inbound - we updated a name of a rule).

What happened: no more access to the storage. No more connection on SMB port. The port was reported as closed.

We removed the storage configuration of allowed networks ( the status was still Green), we add it back and magically it started to work.

Any hints of what could have went wrong?

Thank you

 

2 Replies

  • Hi Adrian.


    Sounds like one of those lovely Azure quirks. On paper nothing you did should have killed access, but when you “rename” an NSG rule in Bicep it’s actually a delete and recreate. That can cause the subnet-to-storage firewall validation to fall out of sync for a while, which is why 445 suddenly looked closed.

     

    By removing and re-adding the network rule on the storage account you basically gave it a kick, forcing Azure to re-evaluate the association. That’s why it came back.

     

    I’ve seen this a couple of times. My takeaway is:

     

    • Don’t rename NSG rules if you can avoid it. Treat the name as immutable and stick to description for readability.
    • Check effective rules with az network nic show-effective-nsg if you want to be sure 445 is actually allowed.
    • Use az storage account network-rule list to confirm the subnet is still properly registered.

     

     

    Root cause is fuzzy, but the pattern is consistent: rename equals recreate, recreate equals temporary mismatch, mismatch equals firewall says no.

  • peseaj's avatar
    peseaj
    Copper Contributor

    Hello Adrian Chirtoc​ ,

    To be sure I understand this:
    1. You changed a name (Inbound NSG name),
    2. You lost access to your file share due to SMB port disconnection,
    3. You removed a config and replaced the exact config,
    4. You gain access again to file share.

    If this is the case, the prime suspect when no actual configuration change (name-change not included) is made is likely due to a network issue that either happened during transit or at the Microsoft backbone network.

    If you can replicate this, then it should be an actual bug.

Resources