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.

Files.com supplies accounts, folder permissions, client apps, sharing, and automated workflows around the cloud connection. The Remote Server ownership model explains how responsibilities divide between your team and the storage operator.

Buckets, Containers, and Locations

Amazon S3 and Google Cloud Storage group objects in buckets. Azure Blob Storage groups blobs in containers within a storage account. Each object has a name unique within that bucket or container; a path such as partners/acme/orders.csv identifies the object there. The provider's account, project, and resource policies establish the administrative boundary around it.

A bucket or container is more than a folder name. Its configuration helps determine where data is stored, which identities may access it, and which recovery, encryption, and lifecycle rules apply. An Azure file share is a different storage model, with files and directories rather than blobs.

The storage location affects application latency, data-location requirements, and transfer costs. An S3 bucket belongs to an AWS region. Azure uses the storage account's region and redundancy configuration. Google Cloud Storage offers regional, dual-region, and multi-region locations. A bucket is therefore not always confined to one region.

For storage your organization administers, location is part of the storage design. For a bucket supplied by another party, its location is an existing condition to account for in the workflow. Your Files.com site's storage region does not relocate it. Provider replication and separate copies also have their own locations. Keeping an application and its storage close can reduce latency and cross-region transfer charges; client access and any Files.com processing still have their own data paths.

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 remote administrator grants those permissions; your team configures the connection and access through Files.com. The shared connection model explains how the two permission systems combine. The cloud authentication guidance explains the responsibilities associated with the credential the administrator supplies, including renewal and replacement.

Access to Existing Files or File Delivery

Choose mounted access or a separate copy according to where the application needs its files. For example, a partner uploading to an S3-backed mount writes to the bucket an existing application reads. A Sync collecting that file into another location creates a separate delivery. The receiving application then imports the delivered data.

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.

The storage owner's data protection and lifecycle policies determine what remains recoverable, while storage classes and provider charges affect availability and cost.

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 to the remote cloud storage.