I’m running node in LXC container in proxmox since last october. Yesterday it went offline without any visible reason (ie me updating software or messing with server in general).
Docker image is running
root@storj:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3bdb216fc959 storjlabs/storagenode:latest "/entrypoint --opera…" 10 months ago Up 13 seconds 0.0.0.0:14002->14002/tcp, :::14002->14002/tcp, 0.0.0.0:28967->28967/tcp, :::28967->28967/tcp, 0.0.0.0:28967->28967/udp, :::28967->28967/udp storagenode
Turned out I had to set up DNS IP in LXC container settings. It was empty by default and optional. I’ve set it to 8.8.8.8 and node came online. Why did it become necessary after 10 months of smooth working? Who knows.
“Storagenode diag” still produces same output BTW
root@storj:~# docker exec storagenode /app/config/bin/storagenode diag
2025-08-27T08:35:25Z INFO Anonymized tracing enabled {"Process": "storagenode"}
storage node directory doesn't exist /root/.local/share/storj/storagenode
Error: stat /root/.local/share/storj/storagenode: no such file or directory
This makes zero sense. Looks like you have multiple issues. DNS settings don’t make files in users local home unreadable. Restarting the container after setting dns is what made a difference. This time. It will fail again. Because you did not find, let alone fix, the root cause
Look, during two days of digging into it I’ve restarted the container like two dozens times, rebooted whole server twice - didn’t help. And this thing with DNS is repeatable, I changed it back and forth several times to check for sure.
And about this message
Error: stat /root/.local/share/storj/storagenode: no such file or directory
storage node directory doesn't exist /root/.local/share/storj/storagenode
AFAIK it’s about mounting the “identity” folder, according to docker config
It’s not an external path. By default, if nothing is configured in config.yml, or not passed as arguments to storagenode, it will indeed be looking for identity under ~/.local/share/storj/identity/<name>. It just happens to be the same in the container as on your host because in both cases username is root (seriously, don’t run node as root), but it’s not reaching outside – that is simply impossible.
The fact that it attempts to look there in the container is a strong signal that either your other docker run arguments are ducked, or the config file is unreadable for whatever reason – because otherwise it would be looking for it under /app.
Understand, that while DNS could be a culprit if you mount some network share by unicast names, specifying public DNS would not fix it – cloudflare does not know about your network layout.
Show your full continer invocation and/or LCX config and node invocation. It shall closely match Storage Node - Storj Docs. Also check permissions on the config file. If you have AppArmor/selinux enabled – then it would be whole other can of worms.
(However, inside LCX, it shall be indistinguishable from full linux, so if that does not work – it only means LCX still suck, and you shall migrate to a proper OS that just works instead of fighting windmills. I’m talking FreeBSD & jails. (the degree of contempt I feel towards majority of linux is indescribable). As a stop-gap measure you can scrap LCX and run storj container in Podman rootless. This is a supported configuration and should work well.)
It’s a literal command, so you can copy and execute as is, config here is a folder named config and it’s in the current directory, because the image has a workdir is set to /app. So, you may also specify it as --config-dir /app/config to do not use a relative location.
because if you do not provide a path, it will try to use the default location, which is
