Skip to main content

Protocol-based File Transfer

Use these connections when Files.com needs to collect or deliver files on a server your organization or a partner operates. Files.com acts as the client and signs in with the account the remote operator provides. A partner connecting into Files.com is the opposite arrangement, covered in Clients and Protocols.

A Remote Server Mount exposes the remote working files through a Files.com folder. A Sync transfers a separate copy between locations, such as collecting a vendor's completed nightly files for an internal application. The remote connection supplies access; it does not define a collection schedule or make a separate copy by itself.

Protocol and Network Requirements

Choose the service the remote operator actually supports. SFTP uses SSH and can authenticate with a password, a private key, or both. FTP/FTPS uses FTP commands and separate data connections; select a required TLS mode to encrypt it. WebDAV uses HTTP-based file access and needs HTTPS for encryption. Port numbers are conventions, rather than proof of the protocol in use.

Arrange both account access and a network route. A public endpoint must allow the source addresses for the selected route. A private endpoint can use Agent routing from a network that reaches it. Successful login establishes neither access to every folder nor permission to replace or delete files there. FTP also needs its passive data ports reachable before listings and transfers can work.

The server's capacity and limits remain part of the workflow. Parallel connections, repeated listings, and overlapping jobs all add load. Keep the combined workload within the remote operator's limits, and distinguish buffered upload receipt from delivery when the destination uses buffering.

Connections Between Files.com Sites

Protocol-based Remote Servers can reach a different Files.com site, but cannot connect a site back to itself with its own hostname and credentials. Perform same-site work directly against its source and destination paths.

For separate Files.com sites, prefer the native Files.com connection when its access model fits. Use a protocol-based connection when the exchange needs the issuing site's protocol or network controls described in that comparison.