Trying to run non-docker SN on QNAP

It was going so well yesterday. Port forwarded in router. ARMv7 binary installed. Linux user created. Config file created and edited. Setup created all the necessary files and folders. SN started and waiting…

First problem: no traffic in or out.
2nd problem: can’t connect to console port.

It got late, so I shut down the SN and logged off the NAS.

Today I want to continue, but now the SN refuses to start: can’t find identity. It found it in the config yesterday, but today it looks in the default location. WTF?

Added config dir to command line, like this:

[/share/CACHEDEV1_DATA/sn] # ./storagenode dashboard --config-dir . --identity-dir .

Now it fails to connect to itself:

2021-01-03T13:25:12.260+0700 FATAL Unrecoverable error {"error": "rpc: dial tcp 127.0.0.1:7778: connect: connection refused", "errorVerbose": "rpc: dial tcp 127.0.0.1:7778: connect: connection refused\n\tstorj.io/common/rpc.TCPConnector.DialContextUnencrypted:107\n\tstorj.io/common/rpc.Dialer.dialTransportUnencrypted:178\n\tstorj.io/common/rpc.Dialer.dialUnencrypted.func1:161\n\tstorj.io/common/rpc/rpcpool.(*Conn).newConn:129\n\tstorj.io/common/rpc/rpcpool.(*Conn).getConn:158\n\tstorj.io/common/rpc/rpcpool.(*Conn).Invoke:194\n\tstorj.io/common/rpc/rpctracing.(*TracingWrapper).Invoke:31\n\tstorj.io/common/pb.(*drpcPieceStoreInspectorClient).Dashboard:1087\n\tmain.(*dashboardClient).dashboard:42\n\tmain.cmdDashboard:70\n\tstorj.io/private/process.cleanup.func1.4:362\n\tstorj.io/private/process.cleanup.func1:380\n\tgithub.com/spf13/cobra.(*Command).execute:842\n\tgithub.com/spf13/cobra.(*Command).ExecuteC:950\n\tgithub.com/spf13/cobra.(*Command).Execute:887\n\tstorj.io/private/process.ExecWithCustomConfig:88\n\tstorj.io/private/process.ExecCustomDebug:70\n\tmain.main:336\n\truntime.main:204"}

Now I would like to know how it can be that a program works one day and not the next? And how do I fix it?

I found that the private server line in config was commented out. I tried uncommenting it and then removing the 127.0.0.1 part, but nothing changes.

Thanks,
Peter.

Hello.
Could you provide us with the docker command you use to start the node ? (Please remove personal details like storj afdress, email, host…)

Also, did you use the special command for initializing the node, first? (With --setup)

Hi Pac,

No docker here, as it says in the title. The start command is:

./storagenode run --config-dir . --identity-dir .

Oh rhubarb: I just realised that I tried to run the dashboard, rather than starting the node. Duuuh!

Ok, status change, we are now were we were yesterday: the node starts, but there is zero traffic.
Port is open when SN is running, closed when not, as expected.

Trying to access dashboard from my PC does not work, “Firefox can’t establish a connection to the server at qm.local:14002.”

Yes, I ran setup to create all the files and dirs, incl. config.yaml.

1 Like

Ah right, my bad :sweat:
Sorry.

You need to specify an absolute paths to your config and the identity locations.
Please, also use a remote access configuration to connect to your dashboard from anywhere: https://documentation.storj.io/resources/faq/how-to-remote-access-the-web-dashboard
The other way is to configure console.address: to listen on LAN IP, not the localhost as default. This is not recommended if your local network is not trusted (for example - if it is a shared WiFi network).

Perhaps it’s worth to create and register the storagenode service like there:


You also can configure the updater:

Thank you Alexey.

I already have absolute paths in my config. To make sure I have also used them to start the SN. It makes no difference. It starts and syncs the clock with a satellite, so it must be communicating, but absolutely nothing happens in the log for hours:

2021-01-03T16:37:00.063+0700 INFO Configuration loaded {"Location": "/share/CACHEDEV1_DATA/sn/config.yaml"} 2021-01-03T16:37:00.095+0700 INFO Operator email {"Address": "xxx@gmail.com"} 2021-01-03T16:37:00.096+0700 INFO Operator wallet {"Address": "0xb1c9621fxxxxx34c4A8d05D47d"} 2021-01-03T16:37:02.324+0700 INFO Telemetry enabled 2021-01-03T16:37:02.532+0700 INFO db.migration Database Version {"version": 46} 2021-01-03T16:37:03.665+0700 INFO preflight:localtime start checking local system clock with trusted satellites' system clock. 2021-01-03T16:37:04.778+0700 INFO preflight:localtime **local system clock is in sync with trusted satellites'** system clock. 2021-01-03T16:37:04.779+0700 INFO bandwidth Performing bandwidth usage rollups 2021-01-03T16:37:04.779+0700 WARN piecestore:monitor Disk space is less than requested. Allocated space is {"bytes": 724781355008} 2021-01-03T16:37:04.780+0700 INFO Node 14cU4e4unH4cesN9Wu9oZfDRug5XiYNYn6mPZ4i3qhXrC7WU23 started 2021-01-03T16:37:04.781+0700 INFO Public server started on [::]:28968 2021-01-03T16:37:04.781+0700 INFO Private server started on 127.0.0.1:7778 2021-01-03T16:37:04.782+0700 INFO trust Scheduling next refresh {"after": "6h43m28.219546462s"} 2021-01-03T17:37:04.779+0700 INFO bandwidth Performing bandwidth usage rollups 2021-01-03T18:37:04.779+0700 INFO bandwidth Performing bandwidth usage rollups

The dashboard on my Windows SN is accessible from other PCs on the LAN. Why does this not work in Linux? As a former IT professional I thought I knew my networking stuff, but from where to where is the port being forwarded to? On which machine do I have to type the forwarding command? Do I have to do this every time I want to connect? I am totally confused.

I started working my way through the setup instructions you have linked. However, almost none of this applies to QTS, QNAP’s cut down Linux.

QTS does not have

  • a root account, it’s called admin
  • commands like su, sudo, service and many others
  • runlevels
  • systemd or another usable init system (it does use init, but it’s reloaded from NVRAM at boot, overwriting anything you may have done.)

QTS has

  • a root file system that is mostly not persistent across boots
  • sshd that permits logins only from admin

With these constraints I suspect that the auto updater will not work and I will have to roll my own. There are ways around some of the limitations and I will document my setup, in case others want to repeat it.

Regards,
Peter.

Not only in configs, you also need to use absolute paths in the storagenode run command.

The storagenode’s dashboard is listening on 127.0.0.1:14002 by default. In this case the dashboard will be available only on the QNAP itself. To change that you need to modify the console.address: in the config.yaml, like

console.address: :14002

You also need to check your firewall if exist and allow the connection to the 14002 port (and also node’s port) as well.

Maybe then it’s simpler to use a docker version in my opinion.

Yes, it would be simpler, but I’ve got 2 of the most low-end NAS they make and so docker and many other apps will not run. < 512MB RAM for a start.

But what I would really like to know: why is there no activity? No vetting, no repair uploads, nothing at all.

As if the node wasn’t reachable from outside :thinking:

Exactly. But yougetsignal says the port is open and if I stop the SN it says it’s closed.

Thank you again, that worked. Dashboard says it’s online, however, it’s 2 versions back, so I’ll grab the latest and try again.

10 mins later: Aha! v1.19.4 is working. :sunglasses: