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.

A Common File System View

Files.com translates paths, folder listings, and file operations into the requests the connected system understands. This lets a partner use SFTP to reach files in an S3 bucket, or an employee use the Desktop App to work with files on a server reached through the Agent. The access method the user chooses does not have to match the storage system's own interface.

For example, a mount can expose a remote folder named exports/acme at the Files.com path Partners/Acme. A request for Partners/Acme/orders.csv acts on exports/acme/orders.csv through the configured connection. Renaming or deleting the file through that path changes the remote file that other applications use.

The folders in that view can have very different representations underneath. A file server has directories; flat object storage has object names from which Files.com infers folders and creates empty-folder placeholders. Services such as Google Drive identify items independently of their displayed paths. Files.com translates those representations so people and workflows can address files through the same folder model. Object Storage Behavior explains prefixes and placeholders, while the Google Drive guidance explains duplicate names and exported Google documents.

This common view does not make every operation equivalent to one on Native Storage. A file rename can be a remote rename, a provider-side copy followed by deletion, or a transfer to another location. Copying through FTP or SFTP reads and uploads the contents even when both paths are on the same server. Folder operations can process every child individually. File Operations explains the connector-specific behavior and its consequences for availability, time, and usage.

Access and File Rules

Once you configure a Mount, Files.com checks the user's folder permissions and the mounting Site's supported Folder Settings and Site settings. The remote service separately checks the connection's credential. The connection needs the rights required by the underlying operations, which can include reading, creating, and deleting files to complete one requested action.

Files.com folder permissions govern access through Files.com; they do not reconfigure the remote system's permissions or control applications connecting directly to it. Access Across Sites and Storage explains how the controls combine, including when the remote is another Files.com Site.

Supported Folder Settings apply processing and controls to work through the mount. GPG processing and Auto Unzip can stage arriving files in Files.com Native Storage before remote delivery. Uploading directly to the remote system bypasses those Files.com upload-processing steps.

Names must satisfy both Files.com's naming rules and the remote system's restrictions. Case-sensitive remote storage can contain separate names that Files.com compares equally. Files.com permission and path-restriction comparisons still apply to both, so names differing only in case or equivalent Unicode spelling are unsuitable for separating access.

The reverse also matters: some remote systems, including storage using Windows path rules, resolve HR and HR. to the same folder even though Files.com treats them as different paths. A Permission Fence on HR does not block access through HR. supplied by a broader parent grant.

Use Permission Fences within mounted storage only when you fully understand the filesystem semantics of every affected folder and subfolder and can guarantee the intended access boundary. Otherwise, keep confidential content outside broader parent grants, using separate permitted subfolders or a separately scoped mount. The mounted-storage access guidance explains both naming differences and the folder layouts needed to separate access.

Contents, Delivery, and Availability

A mount keeps the remote system as working storage, while the transfer path depends on the operation. Eligible Direct Routing transfers carry contents between a client and cloud storage. Other transfers relay through Files.com or a configured Agent. With Buffered Uploads, an upload can finish at Files.com before onward delivery completes.

The remote system's capacity, response time, and availability remain part of the workflow. A mount is not an offline copy. Enterprise customers can configure a High Availability Mount with alternate connections to the same shared files; that protects connection availability rather than replicating the storage.

Deletion and replacement act on the remote contents. Recovery depends on that system's recovery features. The mounting Site's Archive Removed Files setting does not preserve remote files; Folder Settings Within Remote Server Mount explains the retention boundaries.

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.com presents the file information the Remote Server makes available, such as size and modification time. A remote service may omit information available on Native Storage, including creation time, creator, or geographic storage location. A copy or replacement can also change the remote modification time even when the contents are unchanged.

Listings and file information can be cached briefly, so a change made directly on the remote system need not appear immediately in an already-open Files.com view. That is separate from maintaining a searchable inventory of the mount.

The Remote Metadata Index records metadata on a schedule for search and discovery of remote-side arrivals and removals. It stores metadata rather than file contents. Indexing does not turn the mount into a separate copy or make remote-side changes immediate Files.com events.

Operations performed through Files.com produce Files.com activity records. Changes made directly on remote storage follow the index's discovery rules, and the remote service's own records remain necessary when investigating work performed outside Files.com.

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 or distinct output names. A temporary-name handoff is useful when the final rename has the completion behavior the receiving application needs; a copy-and-delete rename is not an indivisible handoff. Use the workflow coordination examples to plan these arrangements, and review Sync Concurrent Access for transfer-specific considerations.