Connect a Google Cloud Storage bucket to give staff, partners, and applications Files.com access to data already used by your Google Cloud workloads. Each connection targets one named bucket. It authenticates through a Service Account Key (JSON), HMAC keys, or OAuth; that choice affects credential ownership, permissions, and the available direct-transfer directions.

Use the bucket through a Remote Server Mount for access to remote files, or a Sync for transfers between storage locations.

Bucket and Authentication

Select Google Cloud Storage when adding a Remote Server, provide the Google Cloud Storage Bucket name, and give the connection an identifiable internal name.

Authentication Information

Files.com supports three authentication methods for connecting to Google Cloud Storage. The Google Cloud Storage Authentication Method option allows Service Account Key (JSON), HMAC, and OAuth.

With the Service Account Key (JSON) method, you enter your Google Cloud project ID and provide the JSON credentials from your service account. The Credentials (JSON) field must contain a JSON object that includes the access key and other required authentication details. Open the downloaded JSON key file in a text editor and copy its entire contents into this field. This JSON object is generated when you create a service account key in the Google Cloud Console. For more information, see Google's documentation.

With the HMAC (XML / S3-compatible API) method, Files.com connects through Google's S3-compatible API. Use it when JSON credentials are not preferred or feasible. This method requires an access key and a secret key. These keys are part of the HMAC authentication mechanism supported by Google Cloud. Generate them in the Google Cloud Console by following Google's HMAC setup guide.

You can store JSON credentials or HMAC keys in the Remote Server Credential Manager and select that credential when configuring the Remote Server.

With the OAuth method, there are no keys to create or manage. Provide the bucket name and choose whether the connection gets Read Only or Read/Write access. Read/Write is the default. When you create the Remote Server using the web interface, Google's sign-in and consent flow starts immediately. Approve the connection with a Google account that has access to the bucket. A Remote Server created another way, such as through the API, an SDK, or Terraform, shows an Inactive status until the sign-in is completed. Use the Connect action on the Remote Server in the web interface to start the sign-in flow.

We recommend using OAuth only when the Service Account Key and HMAC methods are not available to you. An OAuth connection is tied to the associated Google account. If that person leaves your organization or their account is disabled, the connection stops working, which makes personal credentials a poor fit for long-term connections. An organization policy that prevents service account key creation can therefore be a reason to choose OAuth.

Permissions for Files.com Access

Service Account Key and HMAC connections use the permissions of the associated service account. Grant access to the bucket and objects needed by the workflow, rather than bucket administration or IAM policy management. Files.com folder permissions separately govern each user's access through a mount.

OAuth uses the associated Google user's permissions, further restricted by the Remote Server's Read Only or Read/Write choice. The service-account permission sets below do not define the OAuth account's rights.

Full Access

For a connection that reads, writes, replaces, and deletes objects, the predefined Storage Object Admin role (roles/storage.objectAdmin) supplies object permissions. Grant storage.buckets.get separately when the connection requires bucket metadata; object roles do not include it.

A custom role for the same work includes:

storage.buckets.get
storage.objects.create
storage.objects.delete
storage.objects.get
storage.objects.list

Replacement of an existing GCS object requires create and delete permissions. This matters for recurring deliveries that reuse a filename as well as explicit delete operations.

Read-Only Access

For a source that Files.com may list and download but must not change, use Storage Object Viewer (roles/storage.objectViewer). Grant bucket metadata access separately when required. A custom role includes:

storage.buckets.get
storage.objects.get
storage.objects.list

This permits collection or mounted read access without granting upload, replacement, or deletion rights to the connection.

Write-Only Access

For delivery of new objects without permission to read their contents back, use a custom role containing:

storage.buckets.get
storage.objects.create
storage.objects.list

Files.com needs list access as well as create permission to inspect the destination and complete its upload handling. Listing exposes object names and listing metadata, even though the connection cannot download existing contents.

Without object delete permission, this connection cannot replace or delete existing objects. Deliveries therefore need new names. The restriction applies to this identity; it does not make the bucket immutable to other identities with broader permissions.

Network Access

The connection can use Files.com's dedicated outbound addresses. The selected route determines the source addresses the bucket's network rules need to allow for operations from Files.com. Direct client transfers instead originate on the client's network.

Incomplete Multipart Uploads

When using Google Cloud Storage (GCS) in S3 compatibility mode with Files.com, uploads use the Multipart Upload process, just like Amazon S3.

If multipart uploads are not completed or aborted, the uploaded parts can remain stored indefinitely, consuming storage space and potentially incurring costs.

To prevent this, configure a GCS Object Lifecycle Management rule that automatically aborts incomplete multipart uploads after a set period.

The following is an example GCS Lifecycle Rule:

{
  "rule": [
    {
      "action": { "type": "AbortIncompleteMultipartUpload" },
      "condition": { "age": 7 }
    }
  ]
}

This rule automatically aborts any multipart uploads older than seven days and deletes their parts.

Transfer Paths

With HMAC authentication, eligible client uploads and downloads use Direct Routing automatically. With a Service Account Key (JSON), downloads can use Direct Routing while uploads use Files.com's network. OAuth connections use Files.com's network for uploads and downloads.

Directly transferred contents do not count toward Files.com Transfer Usage. Required processing, buffering, and network routing also affect a particular operation. The Direct Routing reference lists the client and operation requirements.

A mounted bucket can participate in Automations as well as user file operations. Choose mounted access or a separate delivery according to which system should hold the working files.

Case Sensitivity

Be aware of case sensitivity differences when copying, moving, or syncing files and folders between Google Cloud Storage and other storage locations. Google Cloud Storage is a case sensitive system, whereas other systems may not be. Files can be overwritten, and folders can have their contents merged, if their case insensitive names match.

Versioning

Google Cloud Storage supports object versioning. When versioning is enabled on a bucket, GCS retains previous versions of each object. Files.com's standard file listing shows only the current version. Noncurrent versions are not visible in the file browser.

For details on how deletions, renames, and moves behave on versioned buckets, see Object Storage Behavior.

Folder Representation Using Slash Files

For flat-namespace buckets, Files.com presents object prefixes as folders and creates slash-file placeholders when needed, including for empty folders. Google Cloud Storage also offers hierarchical-namespace buckets, with different directory and feature behavior. Google's namespace documentation explains the storage choice; object versioning is not supported on hierarchical-namespace buckets.