Remote Server Mount connects a folder on Files.com to a Remote Server in real time. Site Administrators and Workspace Administrators can configure Remote Server Mounts. Workspace Administrators can only configure mounts on folders within their Workspace.

The Remote Server can be a third party cloud, another Files.com account, an on-premise server running the Files.com On-Premise Agent, or any server accessible via FTP, SFTP, WebDAV, S3 protocol, or another supported protocol.

The mounted folder becomes a window onto the files stored in your remote server or cloud, in real time.

Remote Server Mount is also a way to use Files.com's apps, API, and workflows without using our storage services.

Once you configure a Mount, file operations act on the remote. Dropping a file into the folder, deleting a file, creating a subfolder, or any other file or folder operation your Files.com user has permissions for passes through to the remote, subject to the connection's settings. With Buffered Uploads, an upload can finish at Files.com before onward delivery completes.

How a file gets replaced in the mounted folder depends on the operation you use. Moving or copying a file onto one that already exists passes through as two operations rather than one. Files.com deletes the existing file and then writes the new one, so the account Files.com uses on the remote needs delete rights in the mounted folder as well as write. Uploading a file onto one that already exists passes through as a single operation. The upload writes over the existing file, so it needs no delete rights on the remote except on servers that refuse in-place replacement.

Customers on our Enterprise plan can also configure High Availability for Mounts, which automatically routes traffic via alternative connections.

Common use cases include accessing files on a counterparty's cloud without provisioning individual user access, 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 supported remote server types are listed under Cloud Storage and Content Collaboration Integrations.

Checksums and Hashes

Checksums and hashes are not available for files stored on a Remote Server Mount. Calculating these values would require transferring the entire file from the remote server to Files.com servers first, which would incur large data transfer costs. If your business processes require checksums to validate file integrity, you can configure a Sync instead.

Object Metadata

Files remain on the Remote Server. Files.com can store searchable metadata about them when Remote Metadata Index is enabled; this does not copy their file contents into Files.com storage.

When you view file and folder information, you see only the information the Remote Server makes available.

For example, a file stored on Files.com presents information such as creation time, modification time, creator, and geographic storage location. A Remote Server may present some, all, or none of this information.

Size and modification time are returned by many Remote Server types, but not by every type.

Concurrent Access

A Remote Server Mount exposes the remote files themselves, so changes made through Files.com and changes made directly on the remote system affect the same files. Coordinate operations that depend on those files staying in place or retaining particular contents.

For example, a user moving a file through the mount can remove the source a Sync is about to read. Two processes writing the same destination name can replace each other's output. These are race conditions: the result depends on which operation reaches the file first. Merely reading the same completed file from two places does not create that conflict.

Have applications finish writing files before making them available for pickup, and keep those files unchanged until the required transfers finish. Use separate working and pickup folders, distinct output names, or a temporary-name handoff that the producing application completes after writing. Use the workflow coordination examples to plan these handoffs, and review Sync Concurrent Access for transfer-specific considerations.