QNAP StorageNode Setup

[shackrock]

Hi all. Just wanting to get started here and I have some questions after running into some QNAP issues already.

https://registration.storj.io/ links directly to a .qpkg file versioned 1.0.2.

I found this github through old forum posts https://github.com/storj-thirdparty/qnap-storagenode-app which has the latest version at 1.1.0 from August 2020. This is also the same version that is loinked from the QNAP documentation page (I can’t add any more links to this post as a new user, sorry, but it’s at; /sno-applications/qnap-storage-node-app)

Finally we have docker containers at Docker Hub: /r/storjlabs/storagenode/tags?page=1&ordering=last_updated that appear to be at 1.15.6 (although I’m not sure on the proper containerstation setup for these dockers vs. the qpkg).

Can anyone advise which of these is the best path forward and any tips for getting started on QNAP in 2021? Thanks!

[Alexey]

Hello @shackrock,
Welcome to the forum!

Those packages are outdated, so the best way is to setup the CLI version (you need to ssh to your QNAP): https://documentation.storj.io/setup/cli
The identity is better to generate on PC, sign it with a new authorization token and transfer to the QNAP.
The rest part will be done on the QNAP via ssh.

[shackrock]

Gotcha, is it not ok to use the Container Station GUI? If not, I’ll give it a shot on the CLI method w/ SSH and cross my fingers! =)

Would love any tips about which folder to put the identity and storage in for QNAP (I saw on a video they used /public for the stoarage-dir).

[shackrock]

I have performed the CLI method, and it does show in Container Station’s docker after actually - great!

Unfortunately the dashboard at :14002 doesn’t load for me, and the CLI dashboard shows “Status OFFLINE”

[Alexey]

Please, do not use a GUI, by default it will bind storage with -v parameter instead of --mount and in case if the disk would not mount for any reason, your node can be disqualified because of losing data.
Now this probability is reduced by adding a separate setup step, but it’s better to do not risk.

The identity should be placed in userspace, if it’s /public - then fine. This is related to how the QNAP is handled updates. I do not have a QNAP myself, but I believe that they removes all folders outside the userspace during upgrade.

Regarding OFFLINE issue, please, use this checklist:

My Node is OFFLINE for 2 hours

It should connect in seconds. There are a few things you should check. Start with checking the port. On https://www.yougetsignal.com/tools/open-ports/?port=28967 you can fill in the domain or IP you are using in the run command. Then check the port. If it’s closed, it could still be several things. Make sure the WAN IP you see in your router settings matches the IP shown on the above page. Make sure your port forward is set up correctly. That means no filter on incoming IPs, forwarding to th…

To be able to access a web dashboard from your local network you can remove 127.0.0.1 address from the port mapping for the dashboard’s port, i.e. use -p 14002:14002 instead of -p 127.0.0.1:14002:14002 in your docker run command.
To change any parameter you should stop and remove the container and run it back with all your parameters include changed ones:

docker stop -t 300 storagenode
docker rm storagenode
docker run ....

[shackrock]

Alright, I’ve managed to get the dashboard running now, thanks!

On the “offline” issue - I think I just had to wait a few minutes =). Seemss to be working now!

Last few questions for now:

1. Should upgrades only be performed through the CLI? I can follow regular upgrade instructions?
2. Has anyone tried the watchtower in a QNAP that you know of? https://documentation.storj.io/setup/cli/software-updates
3. Can I stop/start the container through Container Station GUI? I assume it is ok because now it’s not setting anything up again.
4. If I use docker rm storagenode, I see the container disappear from the Container Station GUI. As soon as I run it again, it re-appears. This is great, but I want to confirm that the “mounts” stayed from the initial setup step of the container?

Thanks!!

[Alexey]

Watchtower is working with the docker itself, so it should just work. It’s better to use an automatic updates rather than manual, but you can do it of course. And yes, it’s better to do it via CLI.
Because to be able to update you should stop and remove a previous container, then pull a new image and run the container. As I said earlier the GUI will use a wrong option -v under the hood instead of --mount and can destroy your node.

@shackrock

Can I stop/start the container through Container Station GUI? I assume it is ok because now it’s not setting anything up again.

Yes you can stop and start it, but not update.

@shackrock

This is great, but I want to confirm that the “mounts” stayed from the initial setup step of the container?

The container will use parameters which you provide in the docker run command. The docker do not “remember” what was your mount and etc. when you removed the container with docker rm. You should instruct it how to run it every time if you remove the container.

If you just stop the container either via GUI or in the CLI with docker stop command - the docker will just stop the container, but not removes it. And you can start it back either in the GUI or with docker start.
However, to update the image (version) or any parameter, you need not only to stop the container, but also completely remove it, and create a new one with all parameters.

[shackrock]

@Alexey thanks, super clear now. Watchtower seems to be running w/ no issue too.

Can you advise the proper procedure to take the QNAP down for maintenance (i.e. to update the QNAP QTS operating system when updates are available)? I have been trying to find any info in the docs, but is there not a proper way to “notify” of planned maintenance to impact the network less abruptly?

[Alexey]

You can do it when you want.
With current changes the downtime could be up to 288 hours before suspension. Then you will have a week to fix the issue. Then it will be 30 days under review, as soon as it recover the online score more than 60%, it will went out of suspension. If the node would have an audit score below 60% after 30 review period - it will be disqualified.

So, you would have a plenty of time for maintenance before suspension.
Of course it will not be for free - while your node offline, its pieces considered as unhealthy and could trigger a repair. Repaired pieces will be recovered to other nodes, thus they will be removed from your node.