Azure Files

Connect an Azure file share to give staff, partners, and applications Files.com access to files already used by your Azure environment. Files.com connects through the Azure Files REST API over HTTPS. Applications that already access the share through Azure's SMB interface can continue to use their existing path, while Files.com provides its own web, desktop, API, and file-transfer access.

A Mount exposes the share as a Files.com folder. Operations through that folder act on the Azure files themselves, so coordinate changes with applications that also use the share. A Sync instead delivers a separate copy to its destination.

Account, Share, and Authentication

Select Azure Files when adding a Remote Server, and give the connection an identifiable internal name.

An access key grants broad storage-account access. A SAS token restricts the resources, operations, and validity period available to its holder. Choose a token scoped for the work and protect either credential as a secret. Azure's SAS guidance explains lifetime and permission choices.

Enter the credential directly or select a saved credential from the Remote Server Credential Manager. Operations use that connection identity, rather than passing each Files.com user's SSO identity through to Azure. Files.com folder permissions separately control which users can work through the mount.

Select the cloud environment where the share resides: Azure US (the public-cloud default), Azure US Government, or Azure China. Files.com chooses the corresponding Azure service endpoints.

Credential Rotation

Replace a SAS token before it expires, and update the saved credential before revoking an old access key. A SAS token does not refresh itself. Expired or revoked credentials interrupt dependent Mounts, Syncs, Automations, and transfers until access is restored.

After restoring access, review failed and partially completed work. Some files may already have transferred. A shared credential in the Credential Manager updates every Remote Server using it, so verify each affected connection.

Network Access and Upload Completion

Azure Storage firewall rules let you control network access to the public endpoint of your Azure Storage account. By default, Azure Storage accounts accept connections from any network. You can tighten security by defining network rules that specify which sources can connect.

For a connection to the public Azure Storage endpoint, allow the source IP addresses used by the Remote Server. The addresses depend on the connection's routing settings.

A private endpoint is reachable only from networks connected to its virtual network. If public access is disabled, route the connection through a Files.com Agent that can reach and resolve the private endpoint. Adding public IP firewall rules alone does not make a private endpoint reachable.

Azure Files transfers use Files.com's network. With Buffered Uploads set to Automatic, Files.com first receives an upload into Native Storage and delivers it to the share in the background. This lets the client finish independently of the share's receiving speed. Upload completion then confirms receipt by Files.com; check onward delivery before an application depends on the Azure file being present.

Names and Snapshots

Azure Files names are case-preserving and case-insensitive: names that differ only by capitalization identify the same item. Before copying or syncing from a case-sensitive source, resolve such collisions to avoid overwrites or merged folders. See case sensitivity and Azure's naming rules.

Azure file share snapshots are read-only copies of an entire share at a point in time. They are distinct from object versioning and do not appear in Files.com's regular browser. Use the Azure portal, PowerShell, or CLI to create, manage, and restore those snapshots. Files.com does not browse or restore share snapshots.