Azure Files shares require separate decisions about SMB identity, Azure resource roles, file ACLs, network reachability and recovery. This AZ-104 tutorial distinguishes Azure Files from File Sync and explains how snapshots, soft delete and data migration affect real administrative outcomes.
Azure Files is not the same thing as Azure File Sync
Azure File Sync helps extend a managed Azure file share to supported on-premises Windows Server caching, but synchronization does not override the underlying share’s identity, connectivity or recoverability requirements. A hybrid cache may show an older file while the cloud share is available, or a correctly synchronized file may remain unreadable under the caller’s permissions. The separate AZ-104 storage-authentication question concerns who can access the storage service and with what credential; that must be tested alongside directory and share-level SMB permissions.
This article addresses a separate AZ-104 operational objective: configure an Azure Files share, understand identity-based SMB access, verify what directory or share permissions mean, manage snapshots or soft delete and prove that a deleted or changed file is recoverable. These features have service, protocol and storage-tier requirements; do not assume every combination is supported in every region or account type.
Choose the share and access pattern first
Consider a fictional engineering company with approved reports accessed by Windows workstations and an automated service. Some employees should read reports, selected reviewers may modify them, and administrators maintain the share configuration. Define the intended protocol, network path, identity provider, share size/throughput needs, retention and failure tolerance before creating the resource.
An SMB file share has different access expectations from an NFS share. Identity-based SMB authentication can involve on-premises Active Directory Domain Services, Microsoft Entra Domain Services or supported Microsoft Entra Kerberos scenarios, depending on client/device and organizational identity design. The supported configurations change over time, so check Microsoft’s current Azure Files identity matrix rather than asserting that a tenant login alone grants access.
The file share should have the narrowest useful scope. If two departments require different access and retention, placing everything into a broadly writable share can make future permission reviews difficult. File names and paths can themselves reveal business information, so consider whether separate shares or storage accounts better match security boundaries.
Share-level authorization and file ACLs are different
For supported identity-based SMB access, Azure role assignments can control access at the file-share level, while Windows-style filesystem access control lists (ACLs) further restrict particular directories and files. Having a Storage File Data SMB Share Contributor assignment does not necessarily mean a user has unrestricted effective access to every folder when directory ACLs restrict it. Conversely, a permissive file ACL cannot override missing share-level access.
An administrator should examine both layers when a user receives access denied. First establish the caller’s authenticated identity and relevant share-level Azure RBAC assignment. Then inspect the file or directory ACL and group membership seen by the client. Group and token changes may require renewed sign-in or propagation; do not grant a general storage account management role merely because a user cannot open a document.
This also differs from blob data roles. A role allowing an app to read Azure Blob Storage does not automatically authorize SMB file reads. Treat storage service data planes and their authentication systems as independent, even when they share a storage account.
Networks can block an otherwise valid identity
SMB communication commonly depends on TCP port 445 and the client being able to resolve and reach the intended Azure Files endpoint. Some internet service providers or corporate networks restrict SMB traffic. Use a supported secure network design, such as appropriate private connectivity or a VPN, rather than disabling organizational security rules to reach the share.
A private endpoint requires working DNS from the accessing client, and the storage service must authorize the caller. An incorrect DNS record can send the request to an unintended public endpoint, while an authentication error may occur even when the private route is healthy. Record both network and identity outcomes in troubleshooting. A storage account firewall configuration belongs in the plan independently of directory ACLs.
Test the actual client context: an admin laptop on an office network, a domain-joined workstation and an Azure-hosted service may have different routes, identities and capabilities. One successful portal file preview does not establish every SMB client can access the share.
Share snapshots are point-in-time records
Azure Files share snapshots capture read-only point-in-time views of the share under supported platform conditions. They help recover an earlier file version without necessarily restoring the entire live share. A snapshot remains associated with its source share; if that share is permanently lost, the snapshot should not be treated as an independently recoverable offsite copy or an immutable legal archive. Plan its deletion and retention controls as part of the storage protection design.
For a synthetic invoice report, create a conceptual sequence: an approved report exists at noon, an operator edits it at two, and an unintended deletion occurs before the day ends. A prior share snapshot can contain the approved file version if it was taken before the change. The recovery task is to identify the right snapshot, copy or restore the correct content through a supported operation and verify the application sees the approved report after recovery.
Snapshots consume storage and need lifecycle oversight. An administrator should record which snapshots are expected to be available, when they expire and which authorized operator can recover from them. A recovery plan requiring a month-old version is invalid if the organization deletes every snapshot after a week.
Soft delete protects a different failure case
For classic Azure Files shares managed through the Microsoft.Storage provider, share soft delete can retain a deleted share for the configured protection window. Microsoft’s current guidance does not extend that feature to the Microsoft.FileShares provider, so verify the account and resource-provider type before relying on it. Share soft delete and an individual share snapshot do not accomplish the same thing. The former helps recover an entire deleted share during retention; the latter can preserve prior states of files within an existing share. Be precise about the object level being protected.
A test should distinguish these scenarios. When a whole share is deleted, determine if it is soft-deleted and recoverable within the configured window. When only one document is overwritten, determine whether an earlier snapshot or another accepted backup contains the needed version. If the retention window has expired, mark the result unrecoverable under that mechanism instead of creating a false success report.
Backup and retention requirements may warrant another protected copy or supported Azure Backup integration. A storage protection feature may not satisfy all disaster recovery, ransomware isolation or regional failure requirements merely because its name contains the word backup.
Move data without losing metadata silently
Azure Storage Explorer and AzCopy support various Azure Storage data movement workflows, subject to protocol, authentication and feature versions. Choose the tool that supports the exact operation and test whether access controls, timestamps, directory structure and file attributes are preserved as required. A successful byte transfer does not prove every SMB ACL or NTFS-style permission survived unchanged.
For the fictional engineering share, migrate a small synthetic directory tree containing two access groups. Before copying, record file count, relative paths, sizes, checksums where useful and expected access rules. After copying, verify that members of the read-only group cannot write the files and that the reviewers can perform their legitimate operations. If the chosen copy method does not preserve an ACL characteristic, include an approved separate migration step instead of assuming it did.
Data migration can also create a consistency window while users continue writing. Define a cutover plan, freeze or synchronize changes where supported, verify the final delta and coordinate the DNS/share path change. A copied file whose source changed halfway through transfer may need business reconciliation.
Separate File Sync from backup and permissions
An organization may use Azure File Sync to cache an Azure Files share at branch locations. A file server syncing to Azure does not automatically prove the cloud share’s directory permissions, backup schedule or point-in-time recovery strategy are configured correctly. The synchronization feature solves distribution and caching; identity enforcement, retention and recovery must still be explicitly planned.
For a branch-office disaster, ask what must happen if the local Windows Server is lost but the Azure share survives. That recovery path differs from a scenario where an employee accidentally overwrote a file that File Sync then synchronized. In the second case, the deletion or bad write can propagate, making snapshots or another supported protection mechanism important.
Azure File Sync extends supported Azure Files shares into a hybrid Windows Server caching and synchronization workflow, but synchronizing a file does not prove that every SMB client is authenticated correctly or that historical file versions are recoverable. For an administrator operating a managed Azure file share, first test share-level authorization, file/directory permissions and network reachability with the intended user. Then delete a synthetic file and recover it through a supported snapshot or retention mechanism. Those checks address a different operational risk from designing the broad on-premises caching topology.
An Azure Files acceptance exercise
Design one fictional storage account with a project share, two permitted users and one denied guest. Define share-level roles and directory ACLs separately. Test the intended SMB network path and identity source. Simulate an employee who has the right directory ACL but no share-level role; the correct result is denied access. Then give the expected share-level permission and verify that a forbidden directory remains inaccessible because of its ACL.
Next define snapshots at controlled intervals and a synthetic deletion. Verify which snapshot could restore the approved report. Then delete the entire test share under a supported soft-delete policy and confirm whether it can be recovered before retention expiry. These checks are plans until executed in a real Azure subscription, not claimed test results.
Record evidence for the share, user/group identity, selected role, NTFS/share ACL, network result, snapshot identifier, retention policy, restore operation and verified file contents. Avoid exposing real directory credentials or documents in a public tutorial.
Why AZ-104 treats storage configuration as administration
An accessible Azure Files share is not necessarily readable to the intended user: identity-based SMB access can depend on both a share-level authorization and directory/file permissions, alongside supported directory integration and network paths. Test three cases—successful authorized mount, valid authentication without permission to read a subfolder, and recovery of a deleted file from a supported snapshot or retention mechanism. The administrator should explain which layer failed, whose identity was used and which historical version is actually recoverable. In independent AZ-104 Azure Files practice questions, distinguish a created share from an authorized and tested file workflow, and do not assume that enabling snapshots proves every permission or application state can be restored.
A restoration record should say exactly which file or share state was recovered, which identity performed the operation and which attributes did not survive the chosen method. A successful copy of data does not necessarily restore historical permissions, client authentication settings, network access or a missed snapshot interval. Test one authorized restore and one denied restore with separate users; record the resulting file versions and access checks. This evidence is stronger than treating the presence of a soft-delete setting as proof of an end-to-end recoverable SMB workflow.