FTP (Outbound to a Remote)

---

In addition to Files.com's built in FTP capabilities for accepting inbound connections via the FTP or FTPS protocols, Files.com also supports connecting outbound to other services via FTP or FTPS.

You can even complete the loop and connect to Files.com via FTP and have Files.com proxy that connection out to another service also using FTP, SFTP, WebDAV, or any other outbound connection supported by Files.com.

Files.com's Remote Server Mount feature gives you the ability connect a specific folder on Files.com to the remote server in a real time manner.

That folder then becomes a client, or window, accessing the files stored in your remote server or cloud.

Once you configure a Mount, any operation you perform on or inside that folder will act directly on the remote in real time. Whether you are dropping a file into that folder, deleting a file, creating a subfolder, or performing any other file/folder operations your Files.com user has permissions for, those operations will "pass through" to the remote in real time.

This powerful feature enables a wide variety of use cases such as accessing files on a counterparty (client or vendor)'s cloud without provisioning individual access to individual users, reducing storage costs by leveraging on-premise or bulk storage solutions, enabling applications to access 3rd party clouds via Files.com API, FTP, SFTP, or Files.com Apps and many more.

Alternatively, Files.com's Remote Server Sync feature give you the ability to push or pull files to or from remote servers. This means that the files will exist in both places at the end of the sync process.

A remote sync can be a "push", where files from your Files.com site are transferred to the remote server, a "pull" where files are transferred from the remote server to your Files.com site, or a two-way "sync" where files that are new or changed in either location are pushed and pulled to maintain a synchronized state between the folder on your Files.com site and that on the remote server.

Type "Remote servers" in the search box at the top of every page, and then click on the matching result. Click the Add new remote server button and select FTP.

Most of the time, the default port value of 21 should be used for FTP. Only use an alternate port if you know the remote server requires it. The other commonly used remote port, 990, typically means that the server requires SSL using the Implicit method. When using port 990, you most likely need to also select Require SSL (Implicit) under the SSL selection.

If you have a Custom Domain installed on your site, that means Files.com has provisioned two dedicated IP addresses for your site and it will use them by default for outbound connections to the remote server. Provide these 2 IP addresses to your counterparties and ask them to whitelist them in any applicable firewall.

If you do not have a Custom Domain installed on your site, you do not have Dedicated IP Addresses provisioned for your site and Files.com will use its entire pool of IP addresses for connecting outbound to the remote server. If your counterparties maintain an IP Address whitelist, you will need to have them whitelist all of the IPs on this list.

Customers often ask for Dedicated IP addresses as a way to avoid having to ask their counterparty to whitelist a huge list of IP addresses.

We are able to offer that for Remote Server connection purposes via somewhat of a backdoor method, which is adding a Custom Domain to your site. Having a custom domain provides a justification for the dedicated IP address.

Files.com automatically provisions a pair of dedicated IP addresses for every site that has a custom domain enabled. We do that because FTP, unlike HTTP, requires that every custom domain be hosted on a dedicated IP address in order to have a custom SSL Certificate that matches the domain.

This means that if you have users who restrict outbound access via a firewall, they will only need to whitelist your two dedicated IP addresses. rather than having to whitelist our entire published list of IP addresses (see above).

Dedicated IPs, once provisioned, are used for both inbound connections to your site via your custom domain, as well as outbound connections from Files.com to certain applicable Remote Servers that are used for Remote Server Sync and Remote Server Mount.

By default, Files.com will use your dedicated IP addresses for outbound connections to FTP, SFTP, WebDAV, and S3 Compatible remote servers. However, you can disable the use of your dedicated IP in these circumstances if you need to. (You might do that if your counterparty has already whitelisted the main Files.com IP range, for example.)

Files.com will use SSL security for outbound FTP connections wherever possible. You can customize how Files.com will use SSL on this specific remote server connection. The available options are Use If Available, Require SSL (Explicit), Require SSL (Implicit), and Never use.

Choose Require SSL (Explicit) or Require SSL (Implicit) if you know that your remote FTP server does support SSL. This will require SSL, which is the most secure option.

Choose Never if your remote FTP server does not support SSL. This option is insecure.

By default, Files.com will ensure that the remote SSL Certificate matches the hostname used for the connection and also ensure that the remote SSL Certificate is signed by a trusted Certificate authority. You may relax this requirement by telling Files.com to allow non-matching certificates. This option is insecure.

You can configure a maximum number of connections that Files.com will make at a time to the remote FTP server. We recommend the default value of 25, as this will provide the a high level of parallelism, which improves performance.

Some server administrators will request that you reduce this number to reduce the pressure on their server. Be aware that reducing it too low will reduce performance because requests may have to wait for a free connection before they are able to complete.

Files.com will use best efforts to honor the maximum number specified here, though it may still burst above this number on certain occasions, such as when moving the connection to another one of our gateway servers internally. As a cloud-based service, we often reconfigure our network in real time to provide optimized performance. If we ever go above this number, you should expect the connection count to return to the specified number promptly.

Once your Remote Server is added, now you need to integrate it to Files.com as either a Remote Server Mount or Remote Server Sync.

Remote Server Mounts are created by mounting them onto an empty folder in Files.com. This folder should ideally not be the Root of your site, although that is supported if you need it.

From the Files icon on the left, navigate to the location where you want the mounted folder to be and create a new folder. Navigate into the newly created folder and click the Folder Settings button on the top right.

Select Remote Server Mount from the list and click Add new remote server mount button. Select the remote server.

Choose the Remote folder, which is the portion of the remote file system that will be mounted into this folder on Files.com. You can either by leave the default " / " (i.e., the remote server's root directory) or click on Choose a different folder link and navigate to the remote folder you want to this folder to connect to.

Click the Save button. The folder will reload and immediately list the remote folders/files from the selected remote path.

If you instead prefer to do a Sync with the remote, follow these directions.

From Files, navigate into the folder where you would like to add the remote server sync and click Folder settings > Sync to/from remote server.

Click the Add new remote server sync button to reveal the form.

Select the server you would like to transfer to or from by clicking on the Remote server menu.

Next choose your Sync direction. You have three choices:

Push to the remote server: This option uploads files and folders from your designated folder in your Files.com site to the remote server.

Pull from the remote server: This option downloads files from the remote server and saves them in your designated folder in your Files.com site.

Two-way sync: this option checks for new files, deleted files, and changed modification dates on both servers and then pushes and pulls as needed to keep the folders synchronized on both servers.

You have the option to delete files on the source server after a push or pull. Use the After copying menu to select whether you would like files that are successfully transferred to be deleted from or kept on the source server.

Enter the remote path to or from which you would like files and folders transferred, starting after the folder/directory your remote user lands in upon authentication.

For example: if the remote server has a folder structure folderA/folderB/folderC, and the user credentials that you have configured your sync server to log in with automatically land that user inside folderA, then to properly configure your sync folder behavior to transfer files to or from folderC, you would enter the path as folderB/folderC.

Certain remotes that use OAuth for authentication may require regular rotation of your credentials. When this is needed, you will see an alert in the top left of the web interface. You can click the link in that alert to re-authenticate and re-establish the connection to the remote.

When setting up a Remote Server for FTP, make sure that you configure it to match the configuration required by the remote FTP site. The FTP protocol supports distinct methods, and a variety of options, which determine whether a client application can connect. If your configuration doesn't match the requirements of the remote FTP site then a successful connection will not be established.

The remote FTP site should be using secure TLS/SSL-based FTP, generally referred to as FTPS. However FTPS has been implemented in 2 non-compatible methods.

The current recommended method is Explicit FTPS, which implements TLS on standard FTP ports, starting with TCP port 21.

The older depreciated method is Implicit FTPS, which implements TLS on TCP port 990.

Contact the operator of the remote FTP site and confirm which method of FTPS their site supports. Make sure that the configuration for the Remote Server matches the required method.

The remote FTPS site should be using fully valid and chained SSL Certificates. A fully valid certificate will have a host name and domain name that matches the remote site's host name and domain name, including any wildcards. A fully valid certificate will also be valid for the current date. It should not be expired nor contain a start date that is in the future. Finally, a fully valid certificate should be chained to a valid and trusted Certificate Authority.

If any of the above conditions are not met then the remote site is considered untrusted or self-signed. If the remote site is untrusted, or uses a self-signed certificate, then you can still connect to it by configuring the Remote Server to allow connections to sites using self-signed certificates.

There are many online tools available for checking the validity of a site's certificate, such as the SSL Shopper SSL checker and the DigiCert SSL certificate checker.

The remote FTP(S) site should already be configured to allow FTP(S) connections to it. However, firewalls at the remote FTP(S) site may be configured to only allow connections from specified IP addresses. Inform the operator of the remote FTP site that you will be connecting from a Files.com IP address. If you have a custom domain specified for your Files.com site then you can also connect from your dedicated IP addresses.

Files.com will connect to the remote FTP(S) site using Passive (PASV) Mode. In this mode, the remote FTP(S) site will tell Files.com which ports to use in order to traverse any firewalls. The operator of the remote site should ensure that these inbound PASV ports are open on their firewall. Each FTP(S) server provides configuration options to specify the range of ports to be used for PASV. The operator or administrator should refer to the documentation of their FTP(S) server to confirm which ports are being used for PASV and ensure that these inbound ports are not being blocked by their firewall. The entire range of inbound PASV ports should be open on the firewall as FTP(S) will use a randomized port within that range each time.

The FTP protocol uses different connection ports for Control and for Data. The Control channel is used for authentication and for control messages, such as navigating folders, listing folder contents, and setting transmission options. The Data channel is used for the transmission of file content.

If you can connect, navigate folders, and list folder contents, but not upload or download file content, then it's most likely that a firewall is blocking the PASV Data channels. A somewhat common effect of this is having a zero-byte file created whenever an upload or download is attempted. Contact the operator or administrator of the remote site's firewall and ask them to ensure that all PASV ports are open on their firewall.