A Remote Server Mount attaches a remote storage location to a folder in your Files.com file tree. Users and workflows operate on the files at that location through Files.com accounts, permissions, apps, and protocols. The remote system remains the working storage, so a mount does not create an independent copy for use during a remote outage or for recovery.

The Remote Server holds the connection and credential. It can reach a cloud service, another Files.com site, a server using FTP, SFTP, WebDAV or S3, or storage exposed by the Files.com Agent. Site Administrators and Workspace Administrators configure mounts within their administrative scope.

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 mounting Site's permissions, supported Folder Settings, and Site settings as well as the remote connection's access and capabilities. Access Across Sites and Storage explains how these controls combine, including when the remote is another Files.com Site. 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.

Checksums and Hashes

Files.com's automatic checksum generation applies to files uploaded into Native Storage, not to files held on a Remote Server Mount. Calculating a new checksum would require reading the remote file's complete contents. If a workflow needs Files.com-generated checksums, a Sync into Native Storage creates a copy on which they can be calculated.

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.