What are the External NFS Server Configuration

External NFS Server Configuration
 
Cloudjiffy 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 the Cloudjiffy-hosted instance worldwide. Herewith, some special manual adjustments are required to be preliminarily performed on my server for each of these cases.

So, below we’ll consider such configurations on the example of Cloudjiffy Dedicated 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 the server:

2. Next, you need to declare the list of directories you'd like to share within the corresponding, etc/exports file (in Cloudjiffy, 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 at

    Be aware that such flow is highly insecure and should not be used for production purposes, as it will make my 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 the 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 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 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 have made.

 


Was this article helpful?

mood_bad Dislike 0
mood Like 0
visibility Views: 10546