Storjshare-Daemon-CLI setup

Step by Step

 Contents

1 Introduction 2
2 Installing the necessary dependencies 3
2.1 GNU+Linux & Mac OSX 3
2.1.1 Installation of the required components 3
2.1.2 NTP synchronization for GNU+Linux systems 4
2.2 Windows 4
2.2.1 Installing Git 5
2.2.2 Installing NodeJS (LTS) 5
2.2.3 Git and NodeJS installation check 8
2.2.4 Installing the Windows Build Tools 9
2.2.5 NTP synchronization for windows 11
2.3 Installing Storjshare-daemon (CLI) 15
2.4 Text editor 16
2.4.1 GNU+Linux & Mac OSX 16
2.4.2 Windows 16
3 Storjshare-Daemon (CLI) setup and configuration 18
3.1 Storage location 18
3.1.1 GNU+Linux 18
3.1.2 Windows 19
3.2 Node configuration commands 19
3.3 Port Forwarding 20
3.3.1 Set the private IP address to static 20
3.3.2 Ensure your public IP address is static 21
3.3.3 Hostname configuration 22
3.3.4 Router TCP port forwarding configuration 26
3.4 Node config-file generation 31
3.5 Running the nodes with the new configurations 32
3.5.1 Save a snapshot of the running instances 34
3.5.2 Load a snapshot of the running instances 35
3.6 Confirm Port forwarding and monitor the node instances 35
4 Storj Share Troubleshooting 37
4.1 Windows Firewall 39
 4.2 Logger verbosity 39
5 Fine-tune your node 40
6 Some additional useful Storj Share monitoring tools 40
7 Migrating from Storj Share GUI to Storjshare-daemon-CLI or vise-versa 41
7.1 Migrating from the GUI to the CLI 41
7.2 Migrating from the CLI to the GUI 42
8 Conclusion 44
 1 Introduction
Storjshare-daemon-CLI is a command line tool that allows the user to rent-out storage space from a
variety of storage containers to the Storj network. It is intended for users which want the most
lightweight and command line application for renting out storage space. Storjshare-daemon-CLI and
Storjshare-GUI (+V.5.0) are compatible, meaning that both packages can run the same node, which
removes the necessity of walking through migration steps between the two packages. Both the CLI and
GUI versions of Storjshare-daemon can even run the same node simultaneously. With the CLI it is easier
than ever to monitor your node as it has a variety of monitoring and status options integrated in its
engine. Other large advantages include:
Allows the execution of an unlimited number of nodes as long as the internet and hardware
resources allow it.
Allows setting up tunnel mode only to provide tunnels to the rest of the network.
Allows fine-tuning of each of the nodes for maximal performance.
Higher performance than the GUI as it does not require the rendering of graphics.
Allows the manipulation via a terminal over SSH.
In the next sections we will walk you through setting up three nodes using Storjshare-daemon. Although
three nodes will be created in this guide, the user is free to run a different number of nodes, the setup
procedure remains the same.
 2 Installing the necessary dependencies

Before installing Storjshare-daemon-CLI it is necessary to get and install a few software packages that
are necessary to successfully install and run Storjshare. The steps below should be followed in order.

Note: Please keep all the installed packaged up-to-date to ensure maximum compatibility.

2.1 GNU+Linux & Mac OSX

2.1.1 Installation of the required components

First open a terminal as root and type in the following commands in a sequential order:
1) wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.33.0/install.sh | bash
2) exit from bash shell
3) run a new shell
4) nvm install --lts
5) apt install git python build-essential -y
6) npm install --global storjshare-daemon

Now logout from root and login into a user account on your system.

2.1.2 NTP synchronization for GNU+Linux systems

Having a system correctly synchronized with NTP is essential to ensure optimal functionality of the
Storjshare nodes. If the synchronization is off by more than 500 milliseconds, the nodes will start to fail
as it does not keep the same time as all the other nodes on the network. As most messages have a
timestamp, it is essential to have a good synchronization for optimal performance.
Open up a terminal and type in the following:
sudo apt-get install ntp
sudo service ntp stop
sudo ntpdate -s time.nist.gov
sudo service ntp start
timedatectl status
timedatectl list-timezones
sudo timedatectl set-timezone <your timezone>
(e.g. sudo timedatectl set-timezone CET)
Alternatively
Goto: vi /etc/ntp.conf
Youll find a lot of lines in there, but the important ones are the server lines. You can get a list of server
addresses at www.pool.ntp.org, find the preferred ones for your area, and then add them to the file. For
example if you are in the US:
server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org

Then youll need to restart or start the NTPD service:

/etc/init.d/ntpd restart
(vi can be nano)
Your clock is now correctly synchronized.

2.2 Windows

The process of setting setting-up the CLI on windows is a bit more of a lengthy process however still very
simple overall.

2.2.1 Installing Git

In some of the proceeding installation steps it will be necessary to install software packages using the
command line terminal (CMD). Git allows us to easily install these packages using the command line. To
install Git just press on the following link: https://git-scm.com/download/win, figure 2.1. The download
should start automatically and the file will be saved to the downloads folder. After the download is
completed move to the download directory and double click on the downloaded file. Click next on all
installation windows (figure 2.2). After the installation is completed we can exit the program.
 Figure 2.1.Git installation page (https://git-scm.com/download/win)

Figure 2.2.Git installation windows.

2.2.2 Installing NodeJS (LTS)

After the installation of Git for windows we install NodeJS (LTS). NodeJS is available for both 32bit (x86)
and 64bit (x64) systems. The correct version matching the system architecture should be downloaded.
To check the correct version we can open the control panel and type in system: (Control Panel\System
and Security\System). This will open up a window that shows the architecture of our system (figure 2.3).
The system in this guide is a 64 bit (x64) machine, indicating that the 64bit version of NodeJS should be
downloaded (figure 2.4).
 Figure 2.3. System architecture check.

After the system check the correct version can now be downloaded from the NodeJS download page
(https://nodejs.org/en/download/). Note that LTS must be selected (selected by default). We can now
click on the correct bit version and the executable should start downloading (figure 2.4). Clicking on
windows installer will automatically detect the system architecture and download the correct
executable. Note however that a manual check for the correct system bit version is always advisable as
browsers such as Google chrome are notorious for downloading only 32bit versions even if one is on a
64bit machine. After the download completes double click on the executable to initiate the installation.

Figure 2.4.NodeJS download page (https://nodejs.org/en/download/)

It normally takes a few seconds for NodeJS to calculate the necessary space required for the installation,
when completed the Next button can be pressed. Press Next on all windows and finally click on
install. It should now install NodeJS. After the installation click on finish, the node installation is now
completed (figure 2.5).
 Figure 2.5. NodeJS (LTS) installation windows.

2.2.3 Git and NodeJS installation check

We can now check if the previous packages installed correctly by opening a command line terminal
(CMD) either by right-clicking on the w
indows start icon and selecting command prompt, or by
pressing the windows + R key and typing in cmd and pressing enter. Both these methods should
work. Now type in the following (figure 2.6):
node --version
A correct version should be returned. Now type in:
npm --version
A correct version should also be returned. Only if both these commands return a correct value can we
proceed to the next step.

Figure 2.6. Node and Git installation check.

2.2.4 Installing the Windows Build Tools

We now proceed to the installation of the tools necessary to build Storjshare-daemon-CLI. More
information on these tools can be found here: https://www.npmjs.com/package/windows-build-tools.
To be able to install the windows build tools it is necessary to use an elevated PowerShell window. To
open this window, we follow the following steps:
1. Click on the windows start icon
2. Type PowerShell, this will start a windows search.
3. Below Best match right-click on Windows PowerShell (desktop App) and Run as
Administrator (figure 2.6). This should now launch a PowerShell window as Administrator.

Figure 2.6. Start a PowerShell terminal as Administrator.

Once the PowerShell terminal opens we can now install the windows build tools by pasting in the
following command into the terminal:
npm install --global windows-build-tools
Press enter and the tools will start installing (figure 2.7). The installation can take some time due to the
installation of the Visual Studio Build tools. During and after the installation no errors should appear and
if both installations succeeded the command terminal should return the following green colored text
successfully installed Python 2.x and successfully installed Visual Studio Build Tools.

Figure 2.7.Windows Build Tools installation (Note, this package was already installed in this system).

Note: If any errors appear (e.g. weak modules not found) please join our community at
https://storj.io/community.html where we will help to resolve the installation issues.

2.2.5 NTP synchronization for windows

Windows machines are notorious for keeping a poor time synchronization with net time (not local
machine time). If the synchronization is off by more than +-500 milliseconds the node will start to fail as
it does not keep the same time synchronization as all the other nodes on the network. As most
messages have a timestamp, it is essential to have a good synchronization for optimal performance. We
will use a simple tool called NetTime which can be downloaded here: http://www.timesynctool.com/
 We will download and install the latest stable version (Figure 2.8).

Figure 2.8. NetTime download page.

Once downloaded, open the download directory and double click on the executable to initiate
the installation.
Once the installation window appears, click on Next on all the following installation windows
(Figure 2.9).

Figure 2.9. NetTime installation.

Finally click on Finish.

To run the program, open to the system tray and double click on the NetTime icon (Figure 2.10). This will
open the main NetTime program.

Figure 2.10. NetTime tray icon.

Now click on setting which will bring up the settings menu.

Next head over to www.pool.ntp.org and select the region you live in, for example Europe
(http://www.pool.ntp.org/zone/europe).
Scroll down to the country you live in and click on it. This should open up a page with various
time servers (e.g. Server 3.pt.pool.ntp.org), we only need to copy the last part of the string after
Server (e.g. 3.pt.pool.ntp.org), figure 2.11.

Figure 2.11. Time servers for a specific country (Portugal In this example).
 Now paste the chosen server name into the first Time servers field in the NetTime Options
(Figure 2.12).
Set the update interval to 15 minutes, leave all the other fields as default values, and click on
OK (Figure 2.12).

Figure 2.12. NetTime settings with new parameters.

Finally, click on synchronize to synchronize NetTime with your own specified time server which
should lower the offset and lag parameters (Figure 2.13).

Figure 2.13. NetTime after successful configuration, the closer to zero the offset and lag parameters are
 the better.

After this step all the dependencies are successfully installed that are required to install and run
Storjshare-Daemon-CLI. If any of the above installations failed please contact support.

2.3 Installing Storjshare-daemon (CLI)

The following step is the most crucial step in this guide. We now install Storjshare-daemon-CLI by
opening a command terminal and pasting in the following (figure 2.14):
npm install -g storjshare-daemon
This will install the package globally using Node Package Manager.
If no red colored text lines appear during the installation we can check if the installation of the CLI was
successful. This can be done by typing in the following into the terminal:
storjshare --version
If this command returns a valid version number (figure 2.14) instead of an error, it indicates that the
Storjshare-daemon-CLI installation was successful.

Figure 2.14. Storjshare-daemon-CLI installation and installation check.

Note: Please update the CLI as soon as new versions are available here:
https://github.com/Storj/storjshare-daemon/releases

2.4 Text editor

During the configuration of Storjshare it is preferable to have a text editor that structures the text in a
user friendly manner.

2.4.1 GNU+Linux & Mac OSX

There are two main text editors, Vim and emacs that are included by default and thus no installation is
required. To access a file with the text editors (which we will do later) one can CD to the folder
containing the text file and execute the following command:
vi <name of text file>
Or
emacs <name of text file>

2.4.2 Windows
Notepad ++ is text editor of choice for windows. Notepad can be downloaded here (figure 2.15):
https://notepad-plus-plus.org/download/

Figure 2.15. Notepad++ download page (https://notepad-plus-plus.org/download/).

After the download is completed double-click on the executable in the download folder to launch the
installation. Click Next on all the installation windows (figure 2.16).

Figure 2.16. Notepad++ installation.

 3 Storjshare-Daemon (CLI) setup and configuration

3.1 Storage location

Before we can start the actual configuration of the farming nodes it is necessary to pre-determine the
location where we want to store the data for each node. The storage container and location will be
different for each individual, the following storage container devices are most commonly used with
storjshare:
1. Computer internal drives (e.g. HDDs, SSDs)
2. External Hard drives.
3. Network attached storage (e.g. NAS)
4. Other storage devices (SD cards, USB sticks, Micro-USB cards)
Each of the devices above have different characteristic and offer different levels of performance.
NVME-SSDs offer fast read-write speeds which has a large advantage over slower Solid state external
storage drives. Although it should be noted that the impact of the read-write speed largely depends on
the internet connection speeds, having a slow internet connection can completely nullify the read-write
speed advantage of modern SSDs as the limiting factor is network transfer speed. For gigabit networks
however this is not the case, giving SSDs the upper hand.
The maximum storage size of a single storjshare-daemon node is 8.0 TB
If one wants to rent out more storage space to the network it will be necessary add more nodes.
There is no minimum size for a node and thus even laptops with only a few MB-GB of free data can
successfully run storjshare-daemon-CLI. Multiple nodes can be configured if one has many storage
devices that are not agglomerated into one partition.
For example if one wants to rent out the extra space on an internal SSD drive of the computer and that
of an external backup device, at least two nodes must be configured. In this guide 3x nodes will be
configured to store the farming data on a 16GB external SD card. This is purely an example and the exact
same configuration can be applied for other storage containers and location. The method remains the
same. Firstly we have to create 3x folders for each node where the data will be stored.

3.1.1 GNU+Linux

First make sure the disk is mounted within your user account, if so, proceed.
Enter the storage container using ls/cd and type in the following commands:
mkdir Node_1 Node_2 Node_3

This will create three directories in which the data for each of the nodes will be stored. You can name
the directories as you like, however it is advisable to remain consistent with the folder naming when one
wants to add many nodes to prevent confusion.

3.1.2 Windows

Open the storage container folder and hold CTRL + SHIFT + N to create a new folder. You can name the
folder as you like, however it is advisable to remain consistent with the folder naming when one wants
to add many nodes to prevent confusion (figure 3.1).

Figure 3.1. Three folder are created in the storage container. One folder for each node.

3.2 Node configuration commands

The following steps involve the configuration of each of the CLI nodes. The table below illustrates the
configuration commands available for the setup of the Storjshare-daemon nodes. Info take from
https://github.com/Storj/storjshare-daemon/

Options Options info

--key <private key> specify the private key
-h, --help Output usage information
--sjcx <payout address> specify the SJCX payout address (required)
--storage <path to directory> specify the storage path
--size <maxsize> specify node storage size (e.g.: 10GB, 1TB)
--rpcport <port> specify the rpc port number (TCP or UPnP port that is open for
only one specific node)
--rpcaddress <address> specify the rpc address (Hostname (DDNS) or Public IP address)
--maxtunnels <tunnels>
--tunnelportmin <port>
--tunnelportmax <port>
--manualforwarding
--logfile <path>
--noedit
-o, --outfile <writepath>
Table 1. Storjshare configuration commands. (Usage: storjshare-create [options])
Specify the number of tunnels to open through which other
nodes can connect to the network.
specify the minimum tunnel gateway port number
specify maximum tunnel gateway port number
Use TCP port forwarding, do not use NAT (UPnP) traversal
strategies.
specify the logfile path
do not open generated config in editor
write config file to path

3.3 Port Forwarding

To successfully connect to the outside world storjshare can either use NAT traversal strategies by
accessing the network via UPnP/tunneling or by using a TCP forwarded ports. UPnP is configured by
default and requires no configuration from the user. Using NAT traversal strategies, the node will first
try to connect to the network directly via UPnP, however, if this fails it will connect through open tunnel
ports of other farmers (--maxtunnels command). One of the main disadvantages of traversal strategies
is that the node is dependent of the stability of the tunnel connection and thus bad performing nodes
can offer tunnels with poor stability, which will greatly influence the stability of our configured nodes.
Also, the speed at which you will be able to download/upload data depends on the internet speed of the
host that is offering the tunnel. It is for this reason that configuring TCP port forwarding is the preferred
method for users seeking the most stable configuration possible as you are not dependent on the
stability of other nodes.
Note: Although TCP port forwarding is the way to go, it is still essential to configure tunnel ports that
other users can access as it strengthens the network. In this way new users with little technical
experience can still run a successful node with limited configuration.

One of the main hurdles for setting up a good working node is the port forwarding step, which has been
the cause for many bad performing farmers. In this section we will look how to configure TCP port
forwarding for our 3x nodes. For more information on networking and port forwarding please have a
look at the following links:
https://docs.storj.io/docs/networking-101-for-storj-users
https://docs.storj.io/docs/storjshare-troubleshooting-guide in the Port forwarding section.

3.3.1 Set the private IP address to static

Most consumer routers used DHCP which gives your computers on the local network a new IP address
after a certain amount of time (normally 24 hours). If our computer is given a new private IP address,
suddenly the specified Storj Share TCP port does not match the private IP address of our system
anymore. When this happens our computer will not be able to access the port anymore and the port will
thus be closed. To prevent this from happening you have to setup a static private IP address. There are
plenty of tutorials on this topic on the internet, including:

3.3.1.1 Windows

Howtogeek.com/
Portforward.com/

3.3.1.2 Linux based systems

Howtoforge.com/
Cyberciti.biz/

When done make sure to restart your computer and check if the private IP address is still static, if the
IP address changed after a reboot it means that the IP is not static.

3.3.2 Ensure your public IP address is static

To be able to use TCP port forwarding in Storj Share it is necessary that the port you will forward is
linked to a public IP or hostname. Although one can use his or her public IP, most internet providers
(ISPs) do not give static public IPs, meaning that at some point in time your public IP address will change.
The consequence of this is that the port that you forwarded ceases to match to the IP address specified
in the Storj Share configuration file and thus the port will be inaccessible/closed. You can protect
yourself against public IP address change by assigning a hostname to your own local network with a
service like noip.com. If you are not sure if the public IP changes or not over time it is still a good idea to
configure a hostname just in case. Below we will walk through using both methods. If you plan to use a
hostname please skip the Use a public IP address below step.

3.3.2.1 Public IP address

If you are certain your public IP address is static this is the way to go.
Open a browser and head over to google, once I google type in whats my IP, google will now return
your public IP address. Keep this IP address at hand as we will need it later.
 Figure 3.2. Finding your public IP address.

3.3.3 Hostname configuration

Note: You should only use one hostname for your entire local network, even if plan to configure multiple
drives/nodes or run Storj Share on multiple machines. This is true as long as all machines are connected
to the same network and can thus be identified with the same public IP address. If you want to run one
of the nodes behind a proxy or VPN on the same network you would have to add another hostname.
You also need a new hostname if you want to run Storj Share on another network.

When your public IP address is not static, your ISP will provide you with a new IP address after a certain
amount of time. The consequence of this would be that when the IP address changes, Storj Share would
lose connection to the network. Adding a DDNS hostname solves the issue of public IP change. We will
add a free DDNS hostname using NoIP (http://www.noip.com/) which needs to be renewed for free
every 30 days on a free account. On the NoIP website scroll down to where it say Create Your Free
Hostname now, then do the following (Figure 3.4):
1) In the hostname input field select a hostname of your linking (e.g. myhomestorjfarm), it
can contain letters and numbers.
2) Next select any hostname of your liking (e.g. .ddns.net) in the box to the right.
3) Click on Sign Up

Figure 3.3. Adding our own DDNS hostname.

4) On the sign-up page enter your email, username and password. Make sure to write
these details down, we will need them later.
 Figure 3.4. NoIP registration page.

5) When done, click on Create My Free Account. NoIP will now send us a confirmation
email with an activation link to our email address. Once we click on the activation link it
should take us to the NoIP website and confirm that our account is now active.
6) We now scroll down to where it says How to remote access your device and click on
get started with dynamic DNS (Figure 3.5).

Figure 3.5. The activation page: click on the large blue box to go to the DDNS hostname setup page.

7) Clicking on the link should take us to our NoIP dashboard.

8) Now scroll down to Dynamic Update Client for Windows (DUC) and click on
Download (Figure 3.6). This should take us to the download page where we can
download the DUC tool. On the download page click on Download Now.
 Figure 3.6. Dynamic Update Client download.

9) After the file downloaded successfully we head over to the download folder and double
click on the DUCSetup executable.
10) On the resulting installation window, click on Agree -> Install -> Finish.

Figure 3.7. DUC installation.

The Dynamic Update Client should now open. Enter the details from step (4) above and click on Sign in
(Figure 3.8).
 Figure 3.8. Dynamic Update Client.

11) Once logged in successfully, the Edit groups/Hosts menu should be displayed (Figure
3.9). If not already selected, choose the hostname box and click on save.

Figure 3.9. From the Edit groups/Hosts menu, select the hostname and click on save.

12) The DUC tool will now come to life (Figure 5.8). Next head over to File -> Preferences
 and select Start this application automatically when the user logs on. In case your
computer reboots, DUC will automatically start in the background. This is very handy
because if Storj Share starts automatically, it will not run into a closed port as DUC is
also already running.

Figure 3.10. DUC once configured correctly.

3.3.4 Router TCP port forwarding configuration

3.3.4.1 Windows

Now that we have our public IP address or DDNS hostname (rpcaddress), it is necessary to link the
rpcaddress to a specific TCP port (rpcport) by forwarding that port in your router. All communication to
and from your node will pass through this port.
Note: Each drive/node should have its own TCP port.
First, before we can start our port forwarding journey, we need to know the gateway (router) private IP
address so that we can gain access to the router. This can be done in the following way:
Finding the router IP address can be accomplished by typing in `ipconfig` into a CMD window (Figure
3.11). We then scroll down to Default gateway and copy-paste the routers private IP address into a
browser window (Figure 3.12).
 Figure 3.11. Network settings.

Figure 3.12. Router Login page.

We can now log into our router and configure the TCP ports. The router manufacturer and model will
vary from user to user and thus the port-forwarding appearance and menu location within the router
GUI will also differ.
Doing a quick google or YouTube search for:
Port forwarding with <Your router brand and model>
Should bring up enough information to successfully configure port forwarding for your router.
Note: The port forwarding menu in most routers is under the Security menu called Virtual server or
just port forwarding.
Now copy the IPv4 address from the command prompt (CMD) window in which we executed the
`ipconfig` command. This IPv4 address is the private internal IP address of our computer and is required
to set the port forwarding rule (Figures 3.11 and 3.13).
In the example below the ports for 3 nodes/drives were added to the router:
Node 1: 4000 (rpcport) and tunnel ports (4001, 4002 and 4003)
Node 2: 4004 (rpcport) and tunnel ports (4005, 4006 and 4007)
Node 3: 4008 (rpcport) and tunnel ports (4009, 4010 and 4011)
Note: Tunnel ports are not mandatory, they allow other nodes with limited connection possibilities to
connect to the Storj network through your node. If you do not want to configure tunneling you can only
forward one port per node, e.g.
Node 1: 4000 (rpcport)
Node 2: 4001 (rpcport)
Node 3: 4002 (rpcport)

Figure 3.13. Port forwarding parameters for three nodes. Each row represents the forwarding
parameters for a single node.

3.3.4.2 Linux

The first thing we have to do is find our default gateway (router private IP address), this can be
accomplished by typing in the following command into a terminal (Figure 3.28):
`route -n`
Or
`ip route show`
 Figure 3.14. Find your router gateway IP address.

Now copy your Gateway address as shown in red in the figure above (Figure 3.14) and paste it into a
browser window (Figure 3.15), this should bring up the router login page.

Figure 3.15. Router Login page.

We can now log into our router and configure the TCP ports. The router manufacturer and model will
vary from user to user and thus the port-forwarding menu location within the router GUI will also differ.
Doing a quick google or YouTube search for:
Port forwarding with <Your router brand and model>
Should bring up enough information to open a port.
The port forwarding menu in most routers is under the Security menu called Virtual server.
You now have to find the private IP address of the machine on which you want to run Storj Share, this
can be done by executing the following command:
hostname -I
This should return your current static private IP address.
Now copy the IP address from the terminal window in which you executed the `hostname -I` command
and use it to set the port forwarding rule (Figure 3.16).
The example below shows how ports for configuring 3 nodes were added to the router:
Node 1: 4000 (rpcport) and tunnel ports (4001, 4002 and 4003)
Node 2: 4004 (rpcport) and tunnel ports (4005, 4006 and 4007)
Node 3: 4008 (rpcport) and tunnel ports (4009, 4010 and 4011)
Note: Tunnel ports are not mandatory, they allow other nodes with limited connection possibilities to
connect to the Storj network through your node. If you do not want to configure tunneling you can only
forward one port per node, e.g.
Node 1: 4000 (rpcport)
Node 2: 4001 (rpcport)
Node 3: 4002 (rpcport)

Figure 3.16. Port forwarding parameters for 3 nodes. Each row represents the forwarding parameters for
a single node.

Note: The exact port numbers you want to forward are of your own choice, the ports in this guides are
just suggestions.

After following all these steps you should have the following:
1. DDNS configured or know your static Public IP address
2. A static private IP address
3. Configured port forwarding for every node/drive you want to add to Storj Share.
These are all the network tools and settings that have to be configured to successfully run Storj Share
drives/nodes via TCP. Next we need to configure one more tool before we can proceed and configure
Storj Share.

3.4 Node config-file generation

We can now generate a configuration file for each of the node instances. We want to save the config file
in each of the node directories we created a few steps back. The configuration commands can be found
in Table 1. The examples below are pasted one by one into a command prompt window under windows
or a terminal as user (not root) under GNU+Linux. If all the parameters are correct, storjshare-daemon
will create a configuration file in each of the node directories, it will then return a success message and
open the config file in the text editor (figure 3.17). If an error is returned instead of a success message,
then either an invalid parameter was entered or the syntax is incorrect.
Node 1: storjshare-create --sjcx 1PxLPVqmYxM592U3KNAK6EUyhizBpXhA96 --storage
G:\Node_1 --size 3GB --outfile G:\Node_1\config.json --rpcaddress 83.83.66.231 --rpcport
4000 --maxtunnels 3 --tunnelportmin 4001 --tunnelportmax 4003 --manualforwarding true
--logfile G:\Node_1\node_1.log

Node 2: storjshare-create --sjcx 1PxLPVqmYxM592U3KNAK6EUyhizBpXhA96 --storage

G:\Node_2 --size 3GB --outfile G:\Node_2\config.json --rpcaddress 83.83.66.231 --rpcport
4004 --maxtunnels 3 --tunnelportmin 4005 --tunnelportmax 4007 --manualforwarding true
--logfile G:\Node_2\node_2.log

Node 3: storjshare-create --sjcx 1PxLPVqmYxM592U3KNAK6EUyhizBpXhA96 --storage

G:\Node_3 --size 3GB --outfile G:\Node_3\config.json --rpcaddress 83.83.66.231 --rpcport
4008 --maxtunnels 3 --tunnelportmin 4009 --tunnelportmax 4011 --manualforwarding true
--logfile G:\Node_3\node_3.log

VERY IMPORTANT: The parameters used above to create the config files are different from the
ones YOU will use, substitute the information above with your own parameters (e.g. paths,
payout address, public IP address, storage location storage size, ports).

Figure 3.17. In the windows terminal above we successfully created a configuration file for each of the
 nodes.

To confirm that the config.json file was successfully created we can open the node folders and open
the config file with a text editor, e.g. vi/nano or Notepad++ (right mouse click -> open with notepad ++),
figure 3.18. We can now scroll through the config.json file and check if all the entered parameters are
correct. If some of the parameters are incorrect they can be changed directly inside of the config file.
You can edit the parameters in the config file without the necessity of running setup again.

Figure 3.18. Config.json file opened in Notepad++.

Once we checked that all entered parameters are correct we can now proceed to the next step of
actually running the nodes.

3.5 Running the nodes with the new configurations

Once storjshare-daemon-CLI is installed and correctly configured we can now run all 3x nodes. Below in
Tables 2 and 3 the execution commands with coupled examples for storjshare-daemon-cli are
presented.
Commands Command info
start start a farming node
stop stop a farming node
restart restart a farming node
status check status of node(s)
logs tail the logs for a node
create create a new configuration
destroy kills the farming node
killall kills all shares and stops the
 daemon
Daemon starts the daemon
Help [CMD] display help for [cmd]
Table 2. Storjshare-daemon commands

Execution command examples Execution command info

storjshare daemon Starts the daemon
storjshare start --config Starts a specific farming node
path/to/config.json
storjshare stop --nodeid <nodeID> Stops a specific farming node
storjshare restart --nodeid <nodeID> Restarts a specific farming node
storjshare status Checks the status of the node(s)
storjshare logs --nodeid <nodeID> Tails the logs for a specific node
storjshare create --sjcx <address> Create a new node configuration
storjshare destroy --nodeid <nodeID> Kills a specific farming node
storjshare killall Kills all running nodes and stops
daemon
storjshare help logs Display help for the logs command
storjshare save Saves a snapshot of the running nodes
storjshare load Loads the saved snapshot
Table 3. Storjshare-daemon command execution examples.

First before we can start the nodes we have to start the daemon, this can be done by executing the
following command in a terminal as user (not root) for GNU + Linux based systems or within a command
prompt in windows systems:
storjshare daemon
This should return the following message:
* starting daemon in background
We can now start each of the nodes by executing the following commands:
storjshare start --config <path to config.json of Node_1>
storjshare start --config <path to config.json of Node_2>
storjshare start --config <path to config.json of Node_3>
For example under windows:
storjshare start --config G:\Node_1\config.json
storjshare start --config G:\Node_2\config.json
storjshare start --config G:\Node_3\config.json
Note: Make sure to include the config file name in the path. The path style will vary between different
platforms, for GNU + Linux systems just make sure you point it at a mounted drive.
If under a Linux based system you can check if all nodes are running by executing the following
command that will be discussed in the next chapter:
Storjshare status
If you are running windows on the other hand three NodeJS windows should open after starting each of
the three nodes, which indicates that all three nodes are running. Double-check if 3x NodeJS windows
are running (figure 3.19), if only 1-2 windows are open, execute the start command again for the node
that did not start until all 3x NodeJS windows are present. Sometimes the first startup fails. Note, if you
restart your computer you also have to restart storjshare.

Figure 3.19. Three NodeJS windows are open, indicating that all three nodes are running.

3.5.1 Save a snapshot of the running instances

Storjshare has a build in functionality to save a snapshot of the running instances, meaning that
storjshare will remember which nodes were running when the snapshot was created. First we have to
assure that all 3x nodes are running, we can then save a snapshot by executing the following command
in a terminal:
storjshare save
If all goes well the following message should be returned for windows:
* snapshot C:\Users\USER\.config\storjshare\snapshot saved
Or for GNU + Linux:
* snapshot ~/.config/storjshare/snapshot saved

The execution of this command writes a snapshot file to C:\Users\<user>\.config\storjshare for

windows and ~/.config/storjshare/snapshot for Linux. The snapshot contains the config file path and
nodeID for each of the nodes that were running when the snapshot was created.
Note: If one want to migrate or rename the config file to a different location the snapshot file can be
edited with a text editor to accommodate the new parameters.

3.5.2 Load a snapshot of the running instances

The next time we need to start storjshare we can now load our snapshot by executing the following
commands in order within a terminal:
1. storjshare daemon
2. storjshare load

Note: It is also possible to create a script with the daemon and load commands above. Executing the
script would then first start the daemon and then start all nodes with the load command.

3.6 Confirm Port forwarding and monitor the node instances

Now that all three nodes are running we have to check if the nodes can successfully talk to the outside
world. To do this we click on the following link: http://www.yougetsignal.com/tools/open-ports/. We
now enter the rpcport ports (e.g. 4000, 4004 and 4008) into the Port Number field one at a time and
click on Check. Yougetsignal should automatically detect your public IP address, if not, enter it
manually. If you are using a hostname use that in the Remote Address field. We now should see the
following for each of the ports (Figure 3.20):

Figure 3.20. All nodes can successfully communicate to the outside world.
We now know that all three nodes can successfully talk to the outside world. To be able to check the
health of the running nodes we open a terminal/CMD window and type in the following command:
storjshare status
This should now give us a good looking table with critical information about our three node (figure 3.21).

Figure 3.21. Check the status of the running node.

We can see that all three nodes are running and have a significant number of peers and none of the
nodes have restarted, which is very good. Through time the % shared fields should increase towards
100%.
With the Node IDs given in the table above we can also monitor the logs for each node. We can for
instance monitor the first node by typing in the following into a terminal/CMD window (figure 3.22):
storjshare logs --nodeid <nodeID>
e.g. storjshare logs --nodeid 892f4424811f20d77160ffcce0785cc61ae1284f
To select the node ID do a right mouse click -> mark the text. After marking do another right mouse
click to copy the node ID.
Note: if you want to run all the logs at the same time, 3x CMD window should be opened with each one
running the tails for each node.
 Figure 3.22. Log monitoring of one of the nodes.

Updating storjshare-daemon-CLI
New updated versions of the storjshare-daemon-CLI package are released very regularly. To check if any
updates are available since we installed storjshare we can check the following link:
https://github.com/Storj/storjshare-daemon/releases
If new releases appear in the list we can easily update storjshare by executing the following commands
in order:
1. storjshare killall
2. npm install -g storjshare-daemon
Note: Dont forget to start storjshare again after the update is complete.

4 Storj Share Troubleshooting

With very little effort one can check if the configured drives are working correctly by combining the
following sources of information:
1. Storj Share logs
2. Storj API
3. Port checker
If you are not sure if your node is working correctly or not, follow the next few steps:
1. Open the Log file for a specific node with a text editor.
2. Search/grep for Node created
Windows -> CTRL + F -> Node created
 GNU+Linux -> grep "node created" /path_to_your_log.log | tail
This should return something like this:
{"level":"info","message":"node created with nodeID
54e7a82b6e3b99e33a06d32014b2f261a3271365","timestamp":"2017-04-14T16:36:37.521Z"}

2. Now enter the nodeID into the Storj API in a web-browser to check the status of your node as
follows:
https://api.storj.io/contacts/nodeID

(e.g. https://api.storj.io/contacts/e24deba65d74263cd73a9a480d5c44d87139dd00)
This should return something like this:
{"lastSeen":"2017-04-15T17:15:11.930Z,"port":4000,"address": "5.67.55.122","userAgent":"6.1.4",
"protocol":"1.1.0","responseTime":7953.184871461389,"lastTimeout":"2017-04-15T17:14:42.617Z,"tim
eoutRate":0.000001423611111111111,"nodeID":"26dfd89c6c96df11cbcd4598e20117a7b72a97da"}
3. Now copy the address and port and enter them into
http://www.yougetsignal.com/tools/open-ports/ and click on Check, It should return the
following:

Port <port> is open on <IP address or hostname>.

If the port is closed then most likely the drive or router configuration is incorrect or the port is being
blocked by a firewall (see chapter five). If you configured port forwarding, check the config file and
router forwarding rule again.
Note: Sometimes your internet provider (ISP) does not allow port forwarding, giving them a call to ask if
TCP port forwarding is possible and asking them how to set it up if possible is a good idea.

4. Next search/grep the same log for delta, which is your clock synchronization.

Windows -> CTRL + F -> delta.

GNU+Linux -> grep "delta" /path_to_your_log.log | tail

This should return something like this:

{"level":"info","message":"clock is synchronized with ntp, delta: 82

ms","timestamp":"2017-04-14T16:36:37.774Z"}

We can see that in the example above, the delta value is 82ms which falls within the -500ms < delta <
500ms acceptable range. This indicates that our node is correctly synchronized. If the delta value falls
outside of the range above, please synchronized your clock again (see chapters above for more details).
5. Eventually if your node is working correctly you should start to see OFFER messages in your
log.
 6. Sometimes a fatal error can occur such as database corruption, searching the logs for the
following parameters allows you to check if any of these issues have occurred:

Windows -> CTRL + F -> UsedSpace.

GNU+Linux -> grep "UsedSpace" /path_to_your_log.log | tail

Windows -> CTRL + F -> kfs.

grep "kfs" /path_to_your_log.log | tail

Windows -> CTRL + F -> exception.

GNU+Linux -> grep "exception" /path_to_your_log.log | tail
If you encounter any of these issues please join our community at https://storj.io/community.html
where we will help to resolve this issue.

4.1 Windows Firewall

If you are having a hard-time to get Storjshare-CLI to connect through mainly the forwarded TCP ports
on a windows machine chances are that Storjshare-CLI is being blocked by the firewall.
To solve this do the following:
1. Enter the Control Panel
2. Search for Windows Firewall with Advanced Security
3. Once in the Windows firewall with Advanced Security click on Inbound Rules
4. The in the Actions list on the right-hand side click on New Rule
5. Once in the New Inbound Rule Wizard select the Port option and click on Next.
6. Next Select TCP and All Local Ports or just the Storj Share port range (e.g. 4000-4005) in
Specific Local ports and click Next.
7. Select Allow the connection and hit Next again.
8. Select all three rules (Domain, Private and Public) and click Next.
9. Now enter a description (e.g. Storj Ports) and click finish.

Now the firewall inbound rules has been set, we now have to do the same thing for the outbound rule.
Click on Outbound Rule and repeat the steps one through nine above.

4.2 Logger verbosity

You can instruct each node how detailed you want the logs to be, this can be done by clicking on the
gear next to the specific node, selecting Edit and then in the config file change the `loggerVerbosity`
value. The default value is three which shows All information, you can set it to for example four which
is the Debug mode. If you just want to view warnings you can set it to two. Setting it to one only
shows errors. If you dont want Storj Share to dump any information into the logs set the logger
verbosity to zero.
 Logger verbosity Log information
0 No logs
1 Only show Errors
2 Only show warnings
3 Show all information (Info +
warnings)
4 Debug mode
Table 4. Logger verbosity levels.

5 Fine-tune your node

There are two parameters in the config file of each node which can be tweaked to get the most out of
your node in case demand increases significantly. These parameters can be scaled upwards or
downwards depending on your internet and hardware resources. To access the config file, click on the
gear next to the drive and select Edit.
Below are the values that can be tweaked in the config file:
"MaxOfferConcurrency": (default value: 3) -> limited by CPU
"OfferBackoffLimit" (Default value: 4) -> Limited by internet speed/bandwidth
If you have a very fast machine and internet connection, you can increase these values a few at a time.
If you have a slow machine and/or a slow internet connection, decreasing each of the values towards
one is the best option.
Warning:
1. Do not set any of the values to zero.
2. Increasing the values will not have any effect when there is not much uploading/downloading
traffic taking place on the Storj network, however, when network activity increases drastically,
having very high values could completely crash your hardware and or internet connection.

6 Some additional useful Storj Share monitoring tools

There are a number of tools which people have been using through the Storj ages to monitor Storj Share
data usage. As Storj Share not only downloads data from renters but also uploads data back to them,
there can be intensive network usage. If one wants to quantify the amount of bandwidth Storj uses, this
can be easily achieved by installing a few third-party tools.
Windows
https://www.glasswire.com/download/
https://netbalancer.com/
Using task manager to track CPU and RAM usage of Storj Share is also very handy.
GNU + Linux
http://humdi.net/vnstat/

7 Migrating from Storj Share GUI to Storjshare-daemon-CLI or

vise-versa

Starting at Storj Share GUI v5.x both the GUI and the CLI of Storj Share run on the same codebase and
also have the same config file architecture. This essentially means that although they are cars with
different paint jobs, all the mechanical parts are the same. This allows the switching between the two in
a completely painless way by directly running the config file.

7.1 Migrating from the GUI to the CLI

The only thing you have to do is have to do is follow chapter two and install storjshare. When installed
follow chapter 3.5 to start the nodes. As the config files are the same we can directly call the Storj Share
GUI config file in the following way:
storjshare daemon
This should return the following message:
* starting daemon in background
We can now start each of the GUI nodes by executing the following commands:
storjshare start --config <path to the GUI nodeID.json file>

Note: The table below illustrates the default paths to where the GUI config files are saved.

Storj Share GUI v5+ Config file location

Windows C:\Users\USER\.config\storjshare\configs\nodeID.jso
n
OSX ~/.config/storjshare/configs/nodeID.json
Linux ~/.config/storjshare/configs/nodeID.json
Table 5. Default configuration file location for Storj Share GUI v5+.
7.2 Migrating from the CLI to the GUI

You can migrate from the CLI to Storj Share GUI v5+ by in the following way:

1. Download the latest GUI release from https://github.com/Storj/storjshare-gui/releases and

install it.
2. Once at the welcome screen, click on Im an experienced user, skip this step, Figure 7.1.

Figure 7.1. Now click on Import Config in the top-right corner.

3. You can now import the configuration file of a single node from the previously running CLI.
Note: If you did not specify a config file output name and location (-o) at the CLI setup (create
command), then the config files are saved to the default directory which are illustrated below in table
six:

Storj Share Config file location

Daemon-CLI
Windows C:\Users\USER\.config\storjshare\configs\nodeID.jso
n
OSX ~/.config/storjshare/configs/nodeID.json
Linux ~/.config/storjshare/configs/nodeID.json
Table 6. Default configuration file location for Storj Share Daemon-CLI.

4. Once you found the correct configuration file location click on the config file and select Open,
Figure 7.2.
 Figure 7.2. Click on Import config.

Thats it! Storj Share will now automatically import the config file and start the drive(s).
Note: The GUI will now import the config file and create a new config file in the GUI default config file
directory, see table seven below.

Storj Share GUI Config file location

v5+
Windows C:\Users\USER\.config\storjshare\configs\nodeID.jso
n
OSX ~/.config/storjshare/configs/nodeID.json
Linux ~/.config/storjshare/configs/nodeID.json
Table 7. Default configuration file location for Storj Share GUI v5+.
 8 Conclusion
In this guide we installed and configured Storjshare-daemon-CLI and all the necessary dependencies
including network configuration. We looked at how to troubleshoot each of the nodes and how to
fine-tune them for optimal performance. Finally the migration of nodes between the GUI and the CLI
was discussed.
If any of the chapters or steps is confusing or any error appears, feel free to join our awesome
community on Rocketchat (https://storj.io/community.html) which is full of very friendly and helpful
people that will be glad to help you on your way.

Happy farming!