A High Availability Mount provides alternate connections to the same shared storage. For example, a NAS folder can remain reachable through a second server or supported protocol if one connection fails. Files.com selects an eligible backend automatically, so the mount can continue using that storage without an administrator changing its connection each time.

This Enterprise-plan capability protects the connection path. It does not copy files between independent storage locations or make unavailable shared storage accessible. All backends must reach the same working files with the access the workflow requires.

Backends and Shared Storage

Each backend identifies a Remote Server and remote folder for the mount. Configure every backend for the same shared location, folder path, and effective access. A second folder with similar contents is not an interchangeable backend: switching to it can expose different or stale files.

The first backend must use the Remote Server originally configured on the Mount. Keep a backend for that original connection when editing the set. Additional backends can use other servers or protocols, such as SFTP and FTPS connections to the same NAS folder.

Backend Selection

Priority orders eligible backends: lower numbers take precedence. Files.com selects a healthy backend before any degraded backend, then uses priority within that health category. Failed and desynced backends are excluded.

This is connection selection rather than load balancing across all healthy backends. A recovered backend becomes eligible again; when it has the preferred priority among healthy backends, subsequent operations can use it again. Do not assume the mount remains on a fallback until an administrator switches it back.

Detection and recovery depend on the health-check interval and stability thresholds. Review failed or interrupted operations after an outage; a healthy alternate path does not by itself establish that every earlier transfer completed.

Health Checks

Health checks use a canary file: a small file at a known remote path that lets Files.com test access. Active checks also compare timestamp data seen through the backends to detect inconsistent views of shared storage.

Mode	Required Access and Result
Active	Writes and reads timestamp data in canary files, then compares the views through the backends. The account needs read and write access.
Passive	Reads an existing canary file. This supports a read-only backend but does not perform the active write-and-timestamp comparison.

Canary File Path

Keep the canary paths in the same shared folder location, within the mount's configured remote folder, and accessible through the backends. Choose a location outside routine cleanup and file-processing work. A Sync, Automation, or script that deletes, moves, renames, or edits a canary can make a working connection appear unhealthy or inconsistent.

Passive checks need an existing readable file. Active checks need permission to create or update their canary files as well as read them. A successful connection test alone does not establish those file permissions.

Check Intervals

The health-check interval defaults to 60 seconds. Shorter intervals detect changes sooner but generate more remote operations. Choose the interval with the stability thresholds so the mount tolerates brief disruptions without delaying a needed change excessively.

Stability Thresholds

A backend has thresholds for consecutive failures and consecutive successes; both default to 1. A failure threshold of 5 requires five failed checks before Failed status, while a success threshold of 5 requires five successful checks before Healthy status.

Higher thresholds require a longer run of consistent results. A backend can become Degraded before the failure threshold is reached, so a healthy alternate can take precedence during that period.

Health Status

Health and priority together determine which connection serves the mount. Use the status to distinguish unavailable access from inconsistent shared data before changing a backend's configuration.

Status	Meaning and Selection
Healthy	Checks establish the access required by their selected mode. Preferred over degraded backends.
Degraded	Check results are inconsistent or have not met the configured stability threshold. Available only when no healthy backend is available.
Failed	Failures have met the configured threshold. Excluded until successful checks restore eligibility.
Desynced	Backends did not observe consistent current canary data. Excluded until the condition is investigated and the status is reset.

Restored connectivity alone does not clear Desynced. Confirm that the connections reach the same intended folder and current data before using Reset. The HA troubleshooting reference explains the checks for each failure condition.