Connect an Azure Blob container when files should stay in your Azure storage account while people and systems reach them through Files.com. A Mount exposes those files as a Files.com folder; a Sync transfers a separate copy between the container and another location.

The connection uses a storage account access key or Shared Access Signature (SAS) token over HTTPS. Your Azure account's namespace, network restrictions, and recovery settings remain consequential: connecting it to Files.com does not change those settings or give the connection additional Azure permissions.

Connection Details

Select Azure Blob Storage when adding the Remote Server. Give the connection an identifiable internal name. The storage account and container together identify the location, because container names are not globally unique.

Setting	Value
Account	The Azure Storage Account name, shown under Storage Accounts in the Azure portal.
Container	The container name under the selected account's Data Storage > Containers.
Access Key or Shared Access Signature (SAS) Token	The credential for this storage location. Enter it directly or select a saved credential from the Remote Server Credential Manager.
Use Hierarchical Namespace (Azure Data Lake Storage Gen2)	Select this when hierarchical namespace is enabled on the Azure storage account.
Test Path for Bucket/Container	An accessible path for testing credentials that cannot access the container root.

Azure Cloud Selection

Select the Azure cloud environment containing the account: Azure US for the public cloud, Azure US Government, or Azure China. Azure US is the default. Files.com uses the corresponding service endpoints. This selection identifies the Azure destination; it is separate from Files.com's own storage and routing regions.

Credentials and Permissions

An access key grants broad account access. A SAS token limits the resources, operations, and validity period granted to its holder. Choose the scope and permissions for the actual work: listing a source, uploading deliveries, replacing files, and moving files can require different rights.

Files.com users act through the credential saved on this connection. Their Files.com SSO identity is not passed through to Azure Blob Storage. Files.com folder permissions independently control their access to the mounted container.

The SAS signing method also matters. Microsoft Entra RBAC assignments do not narrow an access key or an account-key-signed SAS. A user-delegation SAS is limited by both the token and its issuing identity's permissions. The credential reference explains the permission sets and rotation requirements.

Network Access and Transfers

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.

Eligible downloads use Direct Routing automatically, transferring contents from Azure to the client without Files.com Transfer Usage for those contents. Uploads use Files.com's network. Required processing can also stage uploads in Files.com Native Storage before onward delivery.

A client receiving a direct download needs network access to the Azure endpoint. Allowing Files.com's outbound addresses alone does not grant that workstation access. Private endpoints require a reachable network route and working DNS, as described in Agent routing for cloud storage.

Folders, Names, and Recovery

A standard Blob account uses a flat namespace. Files.com presents prefixes as folders and creates zero-byte slash-file placeholders as needed, including for empty folders. Object Storage Behavior explains the resulting moves, deletions, replacements, and retained content.

A storage account with hierarchical namespace enabled uses directory-aware behavior. Match the Remote Server setting to that account configuration. Enabling this option in Files.com does not convert the Azure account's namespace.

Azure Blob names are case-sensitive. Before transferring to a case-insensitive destination, resolve names that differ only by capitalization to avoid overwrites or merged folder contents.

With Blob versioning enabled, Azure retains previous versions. Deleting a versioned blob leaves previous versions in storage while removing the current file from the regular Files.com listing. Recovery and expiration use Azure's controls. Blob versioning is not available on accounts with hierarchical namespace enabled.

Checksums

Files.com's automatic checksum generation applies to uploads into Files.com Native Storage, rather than uploads into this mounted container. Enabling that setting does not calculate a Files.com checksum for each Azure-mounted file.

When comparing an existing MD5 value from Files.com with an MD5 value displayed by Azure, compare their encoding as well as their contents. Files.com represents MD5 as 32 hexadecimal digits, while Azure represents its MD5 property as a base64-encoded byte array. Decode the hexadecimal value into its 16 bytes and base64-encode those bytes to compare the values. Encoding the hexadecimal text itself produces a different result.

OneLake Compatibility

Microsoft OneLake exposes APIs compatible with Azure Data Lake Storage Gen2, but the differences prevent this Azure Blob Storage integration from working with OneLake. Files.com does not support OneLake through this connector. Contact us if your organization needs that integration.