External NFS Server Configuration

External NFS Server Configuration

 BitssCloud allows to interact with Data Storage Container not only internally (i.e. within a single account or platform), but also with external instances anywhere over the Internet. This means that it supports both mounting data from a third-party NFS storage server and exporting files from your BitssCloud-hosted instance worldwide. Herewith, some special manual adjustments are required to be preliminarily performed on your server for each of these cases.

So, below we’ll consider such configurations on the example of BitssCloudDedicated Storage Container usage, whilst the described flow is suitable for any NFS-based storage server.

1. First of all, in order to share data over the Internet, it’s required to attach a Public IP address to your server:

2. Next, you need to declare the list of directories you’d like to share within the corresponding, etc/exports file (in BitssCloud, it can be easily accessed through the Exports section of the inbuilt Configuration Manager, opened with the Config button).

Here, the following format should be used:{directory} {server}([option],[option],..)
 where:

• {directory} – path to the folder (relative to the Root folder) that should be exported
• {server} – custom domain name or Public IP address of the client node the exported files should be mounted atBe aware that such flow is highly insecure and should not be used for production purposes, as it will make your shared data available for any container on the same hardware node.
• [option] – some additional parameters to describe the access permissions, where the main are:
  • async – allows client-server to receive a response from the storage as soon as its request on adding content is processed (but before the data is actually written to storage). This gives better performance but leaves a risk that some part of your data may be lost if the storage server will be stopped when still holding unwritten data in its cache. To increase reliability, an opposite sync option can be used;
  • ro – defines read-only permissions to make the client node available to view the shared data but not to edit it;
  • RW – states read & write permissions for the client node so it will be able to view and edit the shared data;
  • no_root_squash – gives the root user of a client-server the same level of access to the files as a root user on a storage container has;
  • no_subtree_check – disables the subtree checking the option, which verifies whether the requested file should be accessible (can come in handy if only a part of the folder is exported or to speed up a transfer in case of exporting the entire directory by means of eliminating the necessity to re-check which files should be available).

Don’t forget to save the changes you’ve made.