Files.com integrates with Google Cloud Storage (GCS) buckets in several ways.

The Remote Server Mount feature connects a specific folder on Files.com to the remote server in real time. That folder becomes a client, or window, accessing the files stored in your remote server or cloud. Any operation you perform on or inside the folder acts directly on the remote in real time. Dropping a file into the folder, deleting a file, creating a subfolder, or any other file or folder operation your Files.com user has permission to perform passes through to the remote in real time.

This enables use cases such as accessing files on a counterparty's cloud without provisioning individual access for individual users, reducing storage costs by using on-premise or bulk storage, and enabling applications to access third-party clouds via Files.com API, FTP, SFTP, or Files.com Apps.

The Sync feature pushes or pulls files to or from remote servers. The files exist in both places at the end of the sync process. A sync can be a push, where files from your Files.com site transfer to the remote server, or a pull, where files transfer from the remote server to your Files.com site.

Add Google Cloud Storage as a Remote Server

Add a new Remote Server to your site and select Google Cloud Storage as the server type.

Provide an Internal name for this connection. If you manage multiple remote servers, make the name clear enough to easily identify this connection.

Provide the Google Cloud Storage Bucket name that Files.com will connect to.

The Authentication Information is required because it contains the credentials Files.com uses to connect to the remote system.

Once your Remote Server is added, you can integrate it with Files.com as either a Remote Server Mount or a Sync.

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. Google Cloud organizations created on or after May 2024 disable service account key creation by default, which previously meant connecting GCS to Files.com required a policy exemption from your security team.

Permissions for Files.com Access

When you connect a Google Cloud Storage (GCS) bucket to Files.com using a Service Account Key or HMAC keys, Files.com authenticates using a Service Account that you create in your Google Cloud project. The permissions granted to that Service Account determine what Files.com can do inside your bucket, such as reading, writing, or deleting files.

Assign only the permissions your workflow requires. Files.com does not need to manage bucket-level settings or IAM policies.

OAuth connections do not use a Service Account. An OAuth connection uses the permissions of the associated Google account, in addition to being restricted by the Read Only or Read/Write option for the Remote Server. The IAM guidance below only applies to Service Account Key and HMAC connections.

Full Access

Full access lets Files.com perform create, read, update, and delete (CRUD) operations on all objects within your GCS bucket. Use this configuration when Files.com needs to both upload and download files, synchronize folders, or manage data through Automations and Syncs.

The recommended approach is to grant the predefined Google Cloud IAM role Storage Object Admin (roles/storage.objectAdmin), which provides all necessary object-level permissions.

If you prefer a custom IAM role instead, it must include the following permissions:

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

These permissions let Files.com add, modify, and remove files as required.

Full access is typically used when Files.com must synchronize content bi-directionally with your GCS bucket, move or delete files automatically through Automations, or manage an ongoing file exchange or archival workflow.

Read-Only Access

Read-only access lets Files.com view and download files from your GCS bucket without changing the data. Use this configuration when Files.com needs to import data or read existing files but must not upload, overwrite, or delete anything in the bucket.

To enable this mode, assign the predefined IAM role Storage Object Viewer (roles/storage.objectViewer), which grants permission to view object metadata and read file contents.

If you prefer a custom IAM role instead, it must include the following permissions:

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

These permissions let Files.com retrieve objects and list directory contents while preventing modifications.

Read-only access fits workflows where Files.com imports files for downstream processing, synchronizes data in a one-way direction, or provides visibility into files for partners, auditors, or compliance use cases without altering the source data.

Write-Only Access

Write-only access in Google Cloud Storage functions as an archive-only mode. Files.com uploads new files into your GCS bucket without viewing, modifying, or deleting any existing data. In this configuration, Files.com can deliver files to the bucket but cannot retrieve or replace objects that are already stored there. Because GCS enforces strong object immutability rules at the permission level, overwriting or deleting files is not permitted when access is limited in this way.

To configure this level of access, create a custom IAM role that includes the following permissions:

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

The create permission lets Files.com add new objects to the bucket. The list permission is required for upload operations to complete successfully. Without list access, GCS cannot validate the target location and rejects write requests, even when the file name is new.

This configuration fits workflows where Files.com acts as a secure drop-off point for incoming data. Typical use cases include archival or compliance environments that prohibit modification of existing records, and one-way delivery pipelines that continuously write new files to GCS for downstream consumption or long-term retention.

Under write-only access, Files.com has no visibility into the contents of the bucket beyond confirming successful uploads. Existing objects remain fully protected and immutable from the Files.com connection.

Dedicated IPs

If your site has dedicated IP addresses, you can choose whether Files.com uses those dedicated IP addresses to interact with the remote server. Enable this to simplify networking rules in the remote system. If you do not have dedicated IP addresses, or you disable this option, connections to the remote server can come from any of Files.com's available IP Addresses.

Cleaning Up Incomplete Multipart Uploads in S3 Emulation Mode

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" # Abort incomplete uploads after 7 days
      }
       condition {
         age = 7
      }
    }
  ]
}

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

Add Remote Server Mount

Remote Server Mounts are created by mounting them onto an empty folder in Files.com. We recommend against mounting onto the Root of your site, although that is supported if you need it.

Add Sync

After creating the Remote Server, you can use it to perform Syncs between your remote server and Files.com.

Automations

Folders configured with a Remote Server Mount to Google Cloud can also be used with automations. You can include Google Cloud Storage buckets as source locations or destinations for your automations.

Direct Routing

When your GCS Remote Server uses HMAC authentication, transfers made through the CLI App, the Desktop App, or an official SDK use Direct Routing in both directions, avoiding the extra hop through Files.com's network. This makes transfers faster and changes how they count toward your site's Transfer Usage. Remote Servers using the Service Account Key (JSON) authentication method get Direct Routing for downloads only.

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 File Operations on Object Storage.

Folder Representation Using Slash Files

Google Cloud Storage does not natively support hierarchical folders and instead stores data in a flat namespace. Files.com represents folder structures in Google Cloud Storage using slash files, a convention that simulates directories while remaining compatible with Google's underlying storage model.