Remote Server Mount

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

The Remote Server can be a third party cloud, another Files.com account, or even an on-premise file server accessible via FTP, SFTP, WebDAV, S3 protocol or anything else.

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

Remote Server Mount is also a way to leverage Files.com's apps, API, and workflows without using our storage services.

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

The remote server types that we currently support include: Azure Blob Storage, Backblaze B2, Box, Dropbox, FTP, Google Cloud Storage, Google Drive, OneDrive, Rackspace Cloud Files, Amazon S3, SFTP, SharePoint, Wasabi, and WebDAV.

Setting up a Remote Server Mount

First, make sure that the Remote Server you wish to mount has already been added and configured. Available Remote Servers can be found by typing Remote Servers into the search bar at the top of every page, and then clicking on the matching result.

Web

To set up a Remote Server Mount using the web UI, follow these steps:

1. Navigate to the folder that you want to mount the Remote Server onto. (Or create the folder if it doesn't exist.)
2. Click the button containing a flag icon, at the upper right of the page, to show the configurable folder attributes.
3. Select the Remote server mount option.
4. Select the desired Remote server from the available choices.
5. Optionally, enter a Name and Description.
6. Select the Remote Folder by either typing in the folder path or by selecting the Choose a different remote folder link and selecting the remote folder.
7. Save the updated settings for this folder by clicking the Save button.

API

You can set up a Remote Server Mount programmatically using the Remote Server Mount Behavior API.

Command Line Interface

You can also configure the Remote Server Mount from the command line using the Files.com CLI App.

First, you'll need the ID of the Remote server which can be found using this command:

files-cli remote-servers list

Then you can configure the Remote Server Mount using this command:

files-cli behaviors create --path "path/to/folder" --behavior "remote_server_mount" --value '{ "remote_server_id": <ID>, "remote_path": "/remote/server/path/to/remote/folder" }'

In the above command, replace <ID> with the ID found with the previous command.

Folder Settings Available In Remote Server Mounted Folders

Most folder settings available in Files.com work with Remote Server Mounts, with the exception of the File Expiration and GPG Encryption settings.

We are aware that File Expiration and GPG Encryption would make great features to support on Remote Mounts and we have internal feature requests filed to support both of them.

The behavior of Webhooks, Automations, and Action/History Logging may also be a bit surprising on Mounts. We only log actions and history for file operations performed via Files.com. This is because we otherwise have no visibility into how, when, or by whom any files are modified on the Remote Server.

Since Webhooks are fired based on Action logging, they will not be fired when a file is changed on the remote server without going through Files.com. The same limitation also applies to Automations triggered by actions.

If you require Webhooks or Automations to be triggered on new files, we recommend you consider a Remote Server Sync instead of a Remote Server Mount.

All of the other folder settings, like Share Links, Inboxes, etc. will all work fine with Remote Server Mounts.

Moving Existing Files and Folders to Remote Server Mount

Because Remote Server Mount is a new capability, we are having a lot of existing Files.com customers seek to move high volumes of files from Files.com's internal storage to a Remote Server Mount.

As such, we've put together the following guidelines for moving things to a Remote Server Mount:

High Volume Copies or Moves

First, we recommend always using our Web Interface to perform moves. The web interface will show the progress of cross-remote moves via a status bar in the upper left. If you use some other client, such an FTP client, you will not get real-time status of the move.

Secondly, if the files being moved number in the thousands, or are more than a few levels deep, we recommend breaking up the move into smaller moves. You can do this by creating the top level of target folders inside your mounted folder as new folders, then move the files and folders they are to contain in batches. Again, do this via the web interface, using the Move command.

The services we allow you to integrate with all respond differently to high volume transfers, and managing with smaller batches helps ensure that your Files.com site does not overwhelm the remote service.

Managing Share Links, Inboxes, Permissions, Styles, and Notifications

Whenever you run a Move via the web UI, we will automatically update Share Links, Permissions, Styles, Notifications, and Folder Settings (including Inboxes) to the new destination.

This happens automatically and you do not have to make any changes for these things continue to function normally.

However, this only occurs when you do a direct move. If you Copy a folder from one location to another, no metadata or settings will be transferred during the copy.

This is why we recommend doing everything using a Move, rather than a Copy followed by a Delete.

Case Sensitivity

The case sensitivity of a remote server may be different from the case sensitivity of Files.com. There may be unexpected effects when moving or copying files and folders between systems with differing case sensitivity.

Checksums and Hashes

Checksums or hashes are not available for files stored on a remote server mount. Calculating these values would require transferring the entire file from the remote server to Files.com servers first, incurring potentially large data transfer costs for our customers. If your business processes require checksums to validate file integrity, you can configure a remote server sync instead.

Adding remote servers

Adding remote servers in Files.com is easy. As a Site Administrator, type Remote Servers in the search bar at the top of every page, then click on the matching result. Click on the Add New Remote Server button to select the type of server you want to add. Note that only Site Administrators can add or configure remote servers at this time.

Depending on the type of server you are adding, you may need to have different details on hand.

When you select the remote server type, the form will adapt to prompt you for the information needed specifically for that type. Any optional settings for your selected type will also appear on the form.

Number of Mounts

There are no limits for the number of Remote Server Mounts that you can configure on the Files.com platform. However, some systems limit the number of connections made to them. Contact the system administrator of the remote servers to determine what their limits are.

Maintaining a one-to-one relationship between Mounts and remote servers will allow you to have as many Mounts as you require. For example, if you have 50 remote servers then you can have 50 Mounts, each to one of the remote servers, without any issues.

When there is a many-to-one relationship between Mounts and a remote server, then the number of Mounts will be limited by the restrictions and performance of the remote server. For example, if you have 50 Mounts set up with the remote server, and it only supports 5 concurrent connections, then only 5 of the Mounts will work at a time.

Finding the exact number of Mounts for optimal performance will be based on factors such as the concurrent connection limitations of the remote server, the connection protocol's limitations, and the performance of the remote server. Calibrate the number of Mounts until you find the optimal quantity that work best with the remote server.

Troubleshooting

There are several issues that can cause remote mount failures, such as:

• authentication issues
• firewall issues on the remote server
• general remote server issues
• invalid file or folder names
• invalid file sizes
• slow transfer times

When these issues occur, you may see effects such as some files successfully being transferred while others fail. We provide detailed error messages that should allow you to determine the cause of the failure.

Authentication or Firewall issues

Authentication issues can usually be resolved by correcting any relevant credentials when setting up the Remote Server. However, sometimes authentication issues can occur because of IP address requirements.

Be aware of the following if the remote server enforces an IP address whitelist:

• If your site uses a custom domain, you have two dedicated IPs that may be used for outbound connections. To find your dedicated IPs, type Firewall in the search box at the top of every page, and then click on the matching result. Scroll to the bottom of that page to find your dedicated IP addresses. You can disable the use of your dedicated IP for specific remote server mounts. (You might do that if your counterparty has already whitelisted the main Files.com IP range, for example.)
• If you do not have a custom domain, ensure that our main IPs on this list are whitelisted, not just some of them. There are quite a lot of IPs on that list (over 80 at last count) and you need to whitelist all IPs or else you will experience failures. If whitelisting that many IP addresses is a problem for you, the solution is to move to a custom domain. This will get you a pair of IP addresses you can whitelist (see the prior bullet.)

Invalid file or folder names

Remote servers will likely prohibit certain characters from being used in file and folder names. This is usually caused by limitations in the underlying operating system being used. Operating systems such as Windows, Linux, and Mac each have their own specific restrictions for which characters can be used to name a file or folder. Additionally, 3rd party service providers can overlay their own restrictions. It is not practical for Files.com to maintain a database of any restrictions that may apply on the remote.

If you see issues with invalid file or folder names, we recommend you modify those names. Examples of restricted characters are:

• < (less than)
• > (greater than)
• : (colon)
• " (double quote)
• / (forward slash)
• \ (backslash)
• | (vertical bar or pipe)
• ? (question mark)
• * (asterisk)

Invalid folder names, such as . and .., might be allowed by some object storage solutions but will cause incompatibility with Files.com. Rename or remove these invalid folder names to restore compatibility.

Remote servers may also restrict the length of the file or folder name. Common length limits include:

• 160 characters
• 255 characters

Bear in mind that some remote servers calculate the total length as being either:

• just the file or folder name, including any extension
• the sum of the whole folder path + file name + extension + temporary suffix

To resolve this issue, shorten the name of files and folders so that they are below the length limits of the remote server.

On the Files.com side, the path limit is 550 characters for the sum of the full path, including folder names.

Invalid file sizes

Remote servers may have maximum size limits for files. Please check the documentation of the remote server for details on any file size limits or restrictions.

Remote servers that use APIs or HTTP based connections may also not support zero byte file sizes.

Slow transfer times

Slow transfers and long transfer durations can be caused by low network bandwidth, high network latency, large quantity of files being transferred, huge file sizes, network throttling, remote system performance, local system performance, encryption methods, and session time limits.

The physical limitations of a network or system cannot be circumvented. For example, if sending a 10GB file across the internet to the remote server takes you 2 hours then sending the same 10GB file across the internet to the remote server will take us 2 hours also, assuming we both have identical network connectivity with the remote server.

Remote server issues

If the remote server has a temporary issue, such as being temporarily offline or unavailable, then accessing the remote mount will fail but subsequent access attempts may succeed once the remote service is accessible again.

If the remote server has a permanent issue or limitation, such as not accepting file sizes greater than 2GB or having the incorrect access permissions set, then affected files will never be successfully uploaded or download.

To resolve these issues, make sure that the correct access permissions have been set on the remote server and that any known limitations are communicated to your users. For example, if the remote server cannot accept file sizes greater than 2GB then communicate to your users that file sizes should be kept below the 2GB limit.

To troubleshoot access permission issues, configure a connection to the remote server using credentials with full (read, write, update, delete, list, etc.) access permissions and see if the issue persists. If not, then an access permission is causing the issue. Reconfigure the access permissions one at a time and re-test the remote mount to determine exactly which access permission is causing the issue.

Connection timeout

If the connection to the remote mount times out then the remote server is most likely unreachable, offline, incorrectly configured, or blocked by a firewall.