Files.com connects the cloud storage your organization or a partner already uses to the people and systems that need its files. An S3 bucket feeding an application, an Azure container receiving partner data, or an Azure file share used by staff can participate in Files.com workflows without first moving all its contents to Files.com Native Storage.

The storage provider continues to hold the files and control its storage configuration. Files.com supplies the access point: user accounts and folder permissions, client apps and protocols, sharing, and automated file workflows. This separates where your organization keeps data from how employees, partners, and applications work with it.

The Storage Connection

A Cloud Storage Remote Server identifies the location and credentials Files.com uses to reach it. Depending on the provider, that location is a bucket, container, or file share. Use the native connection type for a listed provider. The S3 Compatible Remote Server connects other services and private storage that implement the S3 protocol.

The connection's identity needs enough access for its work, including listing and any required reads, writes, replacements, or deletions. Your Files.com users receive their own folder permissions; they do not each need the provider credential. A dedicated read-only feed and a shared working folder can therefore require different remote permissions even when they use the same provider. The shared connection model explains how the two permission systems combine.

Access to Existing Files or File Delivery

A Remote Server Mount makes the remote location available through a Files.com folder. A partner uploading to an S3-backed mount writes to that bucket, where an existing application can read the file. Staff can use the same mounted storage through their Files.com apps. Changes made directly in the bucket also affect those working files.

A Sync transfers selected files between locations. It fits a scheduled collection, recurring delivery, or a migration where the destination needs its own copy. An Automation can add processing or other actions around transfers through mounted folders. The receiving application remains responsible for consuming the delivered files; successful transfer does not establish successful application import.

A file written directly to the bucket by another application is visible through the mount, but Files.com did not receive that upload. For workflows that need actions from remote-side arrivals or removals, the Remote Metadata Index scans the mount on a schedule and records discovered changes. The index stores metadata rather than a copy of the file contents.

Mounted storage is not a separate backup. Its availability and recovery depend on the provider and connection. Versioning, retention, and storage-class choices remain important even when users reach the files through Files.com.

File Behavior and Data Paths

Object storage represents paths differently from a traditional file share. Empty folders can need placeholder objects, and a rename can involve copying and deleting many objects. Object Storage Behavior explains those consequences and how provider recovery settings affect deleted or replaced files. Azure Files provides a file share; Azure Blob's hierarchical namespace has its own directory behavior.

The location of the retained file is separate from its transfer path. Direct Routing automatically sends eligible transfers between the client and provider without relaying the contents through Files.com. Transfers that use Files.com's network count toward Transfer Usage. Buffered Uploads and required processing can temporarily store a complete upload on Files.com before delivery, even when the final destination is your own cloud account.