Troubleshooting Lab: Create and configure a file share in Azure Files
Diagnostic Scenarios
Scenario 1 — Root Cause
An administrator reports that a Windows Server 2022 VM hosted in Azure cannot mount an Azure Files share using the following command:
net use Z: \\storprod01.file.core.windows.net\dados /user:Azure\storprod01 <access_key>
The returned output is:
System error 53 has occurred.
The network path was not found.
The administrator confirms that:
- The storage account name and share name are correct
- The access key was copied directly from the portal
- The VM has internet access and can resolve public DNS normally
- The storage account was created less than 24 hours ago
- The share has a configured quota of 50 GiB
A connectivity test was executed on the VM:
Test-NetConnection -ComputerName storprod01.file.core.windows.net -Port 445
ComputerName : storprod01.file.core.windows.net
RemoteAddress : 20.150.x.x
RemotePort : 445
TcpTestSucceeded : False
What is the root cause of the mounting failure?
A) The access key provided in the command is incorrect or expired.
B) Port 445 is blocked at the network layer between the VM and the Azure Files endpoint, preventing SMB communication.
C) The share was created with insufficient quota for the operating system to complete the mounting process.
D) The storage account DNS record has not been fully propagated yet, since the account is less than 24 hours old.
Scenario 2 — Action Decision
The infrastructure team identified that an on-premises file server synchronized via Azure File Sync is experiencing slowness when opening files. After investigation, the cause was confirmed: the cloud tiering feature is rhydrating files with high frequency because the local volume has only 8% free space, below the 20% threshold configured in the volume free space policy.
The environment has the following constraints:
- The server is in production with 200 active users
- It's not possible to add disk capacity for the next 6 hours
- Azure File Sync is synchronizing normally without agent errors
- There is a second server registered in the same Sync Group, currently without load
- The storage team can execute actions in the portal and via PowerShell
What is the correct action to take at this moment?
A) Disable cloud tiering on the affected server endpoint to force all files to remain local and eliminate rehydration.
B) Remove the affected server from the Sync Group and add the second server as an active endpoint, redirecting users immediately.
C) Adjust the cloud tiering policy to reduce the volume free space threshold to 5%, forcing more files to tier and freeing local space.
D) Transfer the access load to the second server registered in the Sync Group, which already has the synchronized metadata, while the primary server's space issue is resolved.
Scenario 3 — Root Cause
An administrator configures identity-based authentication on an Azure Files share to allow domain users to access content with granular permissions. The environment uses on-premises Active Directory Domain Services integrated via Microsoft Entra Connect.
After configuration, the administrator tests access by mounting the share on their own administrative machine, which is a domain member:
net use Z: \\storprodfs.file.core.windows.net\rh
The share mounts successfully. However, when trying to access a subfolder with NTFS permissions restricted to a specific security group, access is denied for all tested users, including confirmed group members.
Information collected:
| Item verified | Status |
|---|---|
| User is member of the group in on-premises AD | Confirmed |
| Group synchronized to Microsoft Entra ID | Confirmed |
| Share-level permission | Contributor assigned to the group |
| NTFS permissions on subfolder | Group with Allow: Read, Write |
| Kerberos ticket obtained successfully | Confirmed |
| Microsoft Entra Connect agent version | 2.1.x (updated) |
What is the root cause of the problem?
A) The Share-level permission configured as Contributor conflicts with the more restrictive NTFS permissions, and Azure Files applies the most restrictive permission between the two.
B) The Kerberos ticket obtained by the client does not include on-premises AD security groups when access is made via SMB to Azure Files, because the token is generated based on Microsoft Entra ID.
C) The NTFS permissions were configured correctly, but Azure Files requires that ACLs be propagated via icacls or Windows Explorer from a domain-joined machine with an authenticated session using the domain account, and this step was not completed.
D) The Microsoft Entra Connect version is outdated and does not correctly synchronize NTFS ACLs from on-premises AD to Azure Files.
Scenario 4 — Diagnostic Sequence
An administrator receives the following alert from a monitoring system:
Alert: Azure Files - Share Quota Exceeded
Storage Account: storbackup02
Share: backups-diarios
Configured Quota: 100 GiB
Current Usage: 100 GiB
New writes are being rejected.
The administrator has never worked on this storage account before and needs to diagnose the situation before acting. Below are the available investigation steps:
- Check if soft delete is enabled and if there are snapshots or versions retained occupying space not visible in active file listings.
- Increase the share quota to 200 GiB to immediately restore write capacity.
- Identify which files or directories consume the most space within the share using metrics or analysis tools.
- Confirm if the storage account is GPv2 or FileStorage and which tier is configured to understand applicable maximum limits.
- Check the storage account activity logs to identify if there was abnormal data growth in recent hours.
What is the correct diagnostic sequence before taking any corrective action?
A) 2 → 4 → 3 → 5 → 1
B) 4 → 5 → 3 → 1 → 2
C) 5 → 1 → 2 → 4 → 3
D) 3 → 1 → 4 → 5 → 2
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue is in the Test-NetConnection command output: TcpTestSucceeded: False on port 445. This confirms that the transport layer is blocked. Error 53 in net use ("network path was not found") is the exact symptom of TCP connectivity failure before any SMB negotiation occurs.
The information about the account being less than 24 hours old and the 50 GiB quota are irrelevant data inserted intentionally. DNS propagation would not cause TCP failure after successful name resolution, and quota has no relation to the mounting phase.
The most dangerous distractor is option A, which leads the administrator to waste time changing credentials instead of checking network connectivity. Choosing A would result in multiple frustrated attempts with valid keys, delaying the actual diagnosis.
Answer Key — Scenario 2
Answer: D
The cause has already been identified in the statement: insufficient local space causing excessive rehydration. The critical constraint is that disk cannot be added for the next 6 hours. The correct action should relieve the load immediately without abruptly removing the server from the production environment.
The second server is already registered in the same Sync Group, which means it has the same files (or reparse points) and can assume read load immediately, without needing complete resynchronization.
- Option A is technically possible, but disabling cloud tiering without available space would force total rehydration of all tiered files, which would immediately worsen the problem.
- Option C is contradictory: reducing the threshold below the current level (8%) does not force more tiering, since the system is already operating beyond the threshold; it would only free space if there were more files eligible for tiering, but does not resolve rehydration slowness.
- Option B is an irreversible and destructive action for an environment with 200 active users without a maintenance window.
Answer Key — Scenario 3
Answer: C
The scenario describes a technically correct configuration at all verified points: correct group, Share-level and NTFS permissions assigned, Kerberos working. The critical detail is in how the NTFS ACLs were configured.
In Azure Files with AD DS authentication, NTFS permissions need to be written directly to the share metadata by an authenticated session with domain identity. Configuring ACLs via portal or tools that don't use the authenticated Kerberos session results in ACLs not properly applied to the remote file system metadata. The step of applying ACLs via icacls or Windows Explorer from a domain session is mandatory and frequently omitted.
Option A represents a common misconception: Azure Files applies the intersection of Share-level and NTFS permissions, so a Contributor with NTFS Read/Write would result in access, not blocking.
Option D is the irrelevant distractor of the scenario: the Microsoft Entra Connect version never synchronizes NTFS ACLs to Azure Files; that is not its role in AD DS integration for Azure Files.
Answer Key — Scenario 4
Answer: B
The correct diagnostic sequence follows the logic of understanding the environment before any corrective action:
4 (understand account type and limits) → 5 (check if growth was abnormal or expected) → 3 (identify what is consuming space) → 1 (check if soft delete/snapshots are retaining invisible space) → 2 (only then expand quota, if necessary).
Step 2 is always last because increasing quota without understanding the cause can mask an uncontrolled growth problem, like a backup job with misconfigured retention.
Sequence A starts with corrective action (step 2) before any diagnosis, which is the most common error under pressure: solving the immediate symptom without understanding the cause, allowing the problem to repeat in hours.
Sequence C puts log analysis before infrastructure understanding, generating interpretative noise without context.
Troubleshooting Tree: Create and configure a file share in Azure Files
Legend:
| Color | Node type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question (binary or state-based decision) |
| Orange | Intermediate verification or validation |
| Red | Identified cause |
| Green | Recommended action or resolution |
To use this tree when facing a real problem, start with the root node describing the general symptom and traverse the branches by answering each question based on what you observe in the environment, not what you assume. Orange nodes indicate that additional verification is needed before confirming the cause. Never jump directly to an action node without having passed through the corresponding cause node: acting without confirming the diagnosis is the origin of most prolonged incidents in storage environments.