[Beta] Can't access certain Rock-On UI (openSuse Leap Linux: 5.3.18-lp152.66-default / 4.0.6-0)

MainrtNr5 · March 14, 2021, 12:31pm

I have only tried with four different Rock-Ons so far (Home Assistant, Plex, Radarr and SABnzbd) but out of these I can only access the UI of Plex and Radarr. Initially I could access SABnzbd as well but after restarting the Rock-On for configuration purposes I can’t access it anymore.

The only error I get when trying to access Home Assistant and SABnzbd is “192.168.0.80 refused to connect.” (ERR_CONNECTION_REFUSED). Restarting the Rock-On doesn’t help, neither does restarting the Rock-On service.

Going through the Rockstor Logs I have a bunch of errors, but they don’t seem related to this specific issue. Let me know if you need me to upload the log file anyhow.

I’ll test with some more Rock-Ons to see if I can find any pattern to this.

[Edit] After re-installing the SABnzbd Rock-On I can access the UI but as soon as I restart the Rock-On I can no longer access the UI.

[Edit, part deux] Upgrading to 4.0.6.0 didn’t help.

phillxnet · March 14, 2021, 8:25pm

@MainrtNr5 Thanks again for yet more testing reports.

It may be that due to some fairly deep, but necessary changes in 4.0.6 you may have to uninstall and re-install the rock-ons. We haven’t yet had many reports with regard to 4.0.6 but it one that may be relevant to your experience here is a recent comment by @Marenz:

Take a look at that post and see what you think. And see if this sorts things out. We are still stabalizing the db entries ready for the nest stable so we may have a new rinkle going on here. Or an upstream update that we have yet to track down.

Cheers.

MainrtNr5 · March 15, 2021, 5:27pm

Hi.

A re-install of SABnzbd unfortunately doesn’t help, even after upgrading to 4.0.6.0.

I’ve also tried with Subsonic and PlexPy and I can access both their respective UI.

Is there any way I can get you more info from logs that aren’t exposed through the Rockstor web UI? I know my way around Linux well enough to dig out a log file.

phillxnet · March 15, 2021, 7:33pm

@MainrtNr5 Re logs.
Take a look in the following directory:

/opt/rockstor/var/log/

and of course via journalctl for the regular system log which is where most of the docker logging happens.

Hope that helps and thanks for following this up.

MainrtNr5 · March 21, 2021, 12:06pm

Hi.

Sorry for the late reply.

The log directory seems to be the same as the logs I can grab from the GUI, or am I mistaken? None the less there are a couple of docker errors related to SABnzbd in the Rockstor log, but none from today - when I did my testing - nor from accessing the GUI:

[15/Mar/2021 18:23:17] ERROR [system.osi:199] non-zero code(1) returned by command: ['/usr/bin/docker', 'stop', 'sabnzb']. output: [''] error: ['Error response from daemon: No such container: sabnzb', '']
[15/Mar/2021 18:23:17] ERROR [system.osi:199] non-zero code(1) returned by command: ['/usr/bin/docker', 'rm', 'sabnzb']. output: [''] error: ['Error: No such container: sabnzb', '']

To me this looks like Rockstor is trying to stop and uninstall a non-existing docker container. It might be related to my problems, I don’t know.

The journal repeats this error message, over and over again, every second:

mar 21 12:42:07 Rockstor linuxserver/sabnzbd:latest/sabnzb[11469]:
mar 21 12:42:07 Rockstor linuxserver/sabnzbd:latest/sabnzb[11469]: Fatal error:
mar 21 12:42:07 Rockstor linuxserver/sabnzbd:latest/sabnzb[11469]:   Unable to bind to port 8080 on localhost. Some other software uses the port or SABnzbd is already running.

It doesn’t matter if I try to access the Plex GUI or not, this still shows up.

Listing the ports that are used gave me the following result:

administrator@Rockstor:~> sudo lsof -nP -iTCP -sTCP:LISTEN
COMMAND     PID        USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
systemd       1        root   51u  IPv4    20838      0t0  TCP *:111 (LISTEN)
rpcbind     918         rpc    4u  IPv4    20838      0t0  TCP *:111 (LISTEN)
sshd       1226        root    3u  IPv4    27019      0t0  TCP *:22 (LISTEN)
postgres   1277    postgres    3u  IPv4    25272      0t0  TCP 127.0.0.1:5432 (LISTEN)
master     1496        root   13u  IPv4    27191      0t0  TCP 127.0.0.1:25 (LISTEN)
smbd       2803        root   32u  IPv4    31120      0t0  TCP *:445 (LISTEN)
smbd       2803        root   33u  IPv4    31123      0t0  TCP *:139 (LISTEN)
shellinab 11060 shellinabox    4u  IPv4 28414312      0t0  TCP 127.0.0.1:4200 (LISTEN)
docker-pr 11678        root    4u  IPv4   428148      0t0  TCP *:7878 (LISTEN)
Plex\x20M 12447        Plex   60u  IPv4   423581      0t0  TCP *:32400 (LISTEN)
Plex\x20M 12447        Plex   61u  IPv4   423583      0t0  TCP 127.0.0.1:32401 (LISTEN)
Plex\x20S 12531        Plex    7u  IPv4   424899      0t0  TCP 127.0.0.1:46467 (LISTEN)
Plex\x20T 13313        Plex   13u  IPv4   424910      0t0  TCP 127.0.0.1:32600 (LISTEN)
docker-pr 19036        root    4u  IPv4  2211898      0t0  TCP *:9090 (LISTEN)
docker-pr 19051        root    4u  IPv4  2211937      0t0  TCP *:8080 (LISTEN)
nginx     31516        root    6u  IPv4   628760      0t0  TCP *:443 (LISTEN)
gunicorn  31517        root    6u  IPv4   627869      0t0  TCP 127.0.0.1:8000 (LISTEN)
data-coll 31518        root    3u  IPv4   615405      0t0  TCP *:8001 (LISTEN)
nginx     31521       nginx    6u  IPv4   628760      0t0  TCP *:443 (LISTEN)
nginx     31522       nginx    6u  IPv4   628760      0t0  TCP *:443 (LISTEN)
gunicorn  31540        root    6u  IPv4   627869      0t0  TCP 127.0.0.1:8000 (LISTEN)
gunicorn  31541        root    6u  IPv4   627869      0t0  TCP 127.0.0.1:8000 (LISTEN)

This is where my troubleshooting skills for Linux ends though so let me know if there’s anything else you need to me to test or check.

When I try to access the GUI for Home Assistant (which also doesn’t work) this shows up in the journal:

mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: s6-chown: fatal: unable to chown /var/run/s6/etc/cont-init.d/udev.sh: Operation not permitted
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: s6-chmod: fatal: unable to change mode of /var/run/s6/etc/cont-init.d/udev.sh: Operation not permitted
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: s6-chown: fatal: unable to chown /var/run/s6/etc/services.d/home-assistant/run: Operation not permitted
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: s6-chmod: fatal: unable to change mode of /var/run/s6/etc/services.d/home-assistant/run: Operation not permitted
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: s6-chown: fatal: unable to chown /var/run/s6/etc/services.d/home-assistant/finish: Operation not permitted
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: s6-chmod: fatal: unable to change mode of /var/run/s6/etc/services.d/home-assistant/finish: Operation not permitted
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: [s6-init] ensuring user provided files have correct perms...exited 0.
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: [fix-attrs.d] applying ownership & permissions fixes...
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: [fix-attrs.d] done.
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: [cont-init.d] executing container initialization scripts...
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: [cont-init.d] udev.sh: executing...
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: foreground: warning: unable to spawn /var/run/s6/etc/cont-init.d/udev.sh: Permission denied
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: [cont-init.d] udev.sh: exited 127.
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: [cont-finish.d] executing container finish scripts...
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: [cont-finish.d] done.
mar 21 12:48:11 Rockstor homeassistant/home-assistant:latest/home-assistant[11469]: [s6-finish] waiting for services.

Again, I don’t have enough knowledge about Linux to do anything with this information so let me know if and how you want me to follow up on this.

Flox · March 21, 2021, 2:15pm

Hi @MainrtNr5,

Thanks a lot for the additional information in the logs, there, I believe you actually got to the bottom of it. Regaridng your Sabnzd issue, briefly, you didn’t do anything wrong, but it appears to be something upstream (on the image’s side, I believe).

You are correct: they are the same. Rockstor webUI “simply” provides a nice user interface to them.

[15/Mar/2021 18:23:17] ERROR [system.osi:199] non-zero code(1) returned by command: ['/usr/bin/docker', 'stop', 'sabnzb']. output: [''] error: ['Error response from daemon: No such container: sabnzb', '']
[15/Mar/2021 18:23:17] ERROR [system.osi:199] non-zero code(1) returned by command: ['/usr/bin/docker', 'rm', 'sabnzb']. output: [''] error: ['Error: No such container: sabnzb', '']

To me this looks like Rockstor is trying to stop and uninstall a non-existing docker container. It might be related to my problems, I don’t know.

Although it is reported as errors in the logs, these are normal and signs of normal operation. They occur upon a rock-on install if my memory is correct, as we first try to make sure there is no remnant of container with the same name before installing the rock-on. In a healthy system, this shouldn’t be the case so these “sanity-checks” fails as expected.

These are thus not the cause of your issue with sabnzd. What is, however, is highlighted by what you found in the docker logs:

The journal repeats this error message, over and over again, every second:

mar 21 12:42:07 Rockstor linuxserver/sabnzbd:latest/sabnzb[11469]:
mar 21 12:42:07 Rockstor linuxserver/sabnzbd:latest/sabnzb[11469]: Fatal error:
mar 21 12:42:07 Rockstor linuxserver/sabnzbd:latest/sabnzb[11469]:   Unable to bind to po

As mentioned earlier, I too can see this upon restarting the rock-on, as can many other users (independent of Rockstor). See the Github thread below:

github.com/linuxserver/docker-sabnzbd

Server not starting after update, port 8080 blocked

opened 01:38PM - 17 Aug 20 UTC

closed 08:51PM - 09 Aug 21 UTC

RafaelSchridi

no-issue-activity

Watchtower recently updated my version 3.0.0 and since then sabnzbd just won't s…tart. All i get in the log is >Fatal error:, Unable to bind to port 8080 on localhost. Some other software uses the port or SABnzbd is already running. I tried changing the outgoing port in docker to 8081 and changing the config file to also use port 8081 but that did nothing since it's always forced to 8080. here is my config ``` sabnzbd: container_name: sabnzbd restart: unless-stopped volumes: - '/opt/x/settings/sabnzbd:/config' - '/zfs/x/Content/Complete:/downloads' environment: - PGID=1001 - PUID=1001 - TZ=Europe/Amsterdam ports: - '8080:8080' image: linuxserver/sabnzbd networks: net: ipv4_address: 172.50.0.100 ``` It shares the network with other services but disabling those did nothing ``` networks: net: driver: bridge ipam: driver: default config: - subnet: 172.50.0.0/16 ``` I have now returned to 2.3.9-0ubuntu1jcfp218.04-ls67 ------------------------------ ## Expected Behavior I expect it to start and not complain about any used ports since it resides in a docker container. ## Current Behavior Doesn't start due to the above mentioned error. ## Steps to Reproduce 1. run the docker compose file 2. look at logs 3. see it restarting ## Environment **OS:** Arch **CPU architecture:** x86_64 **How docker service was installed:** Composer file ## Command used to create docker container (run/create/compose/screenshot) sudo docker-compose pull && sudo docker-compose up -d --remove-orphans ## Docker logs https://pastebin.com/raw/iY5vL4Vv

While a few users tend to first report it to be linked to IPv6 being disabled on the system (which is the case for us), a solution has been brought up, which turns out to be unrelated to IPv6. See the specific post below:

github.com/linuxserver/docker-sabnzbd

Server not starting after update, port 8080 blocked

opened 01:38PM - 17 Aug 20 UTC

closed 08:51PM - 09 Aug 21 UTC

RafaelSchridi

no-issue-activity

Watchtower recently updated my version 3.0.0 and since then sabnzbd just won't s…tart. All i get in the log is >Fatal error:, Unable to bind to port 8080 on localhost. Some other software uses the port or SABnzbd is already running. I tried changing the outgoing port in docker to 8081 and changing the config file to also use port 8081 but that did nothing since it's always forced to 8080. here is my config ``` sabnzbd: container_name: sabnzbd restart: unless-stopped volumes: - '/opt/x/settings/sabnzbd:/config' - '/zfs/x/Content/Complete:/downloads' environment: - PGID=1001 - PUID=1001 - TZ=Europe/Amsterdam ports: - '8080:8080' image: linuxserver/sabnzbd networks: net: ipv4_address: 172.50.0.100 ``` It shares the network with other services but disabling those did nothing ``` networks: net: driver: bridge ipam: driver: default config: - subnet: 172.50.0.0/16 ``` I have now returned to 2.3.9-0ubuntu1jcfp218.04-ls67 ------------------------------ ## Expected Behavior I expect it to start and not complain about any used ports since it resides in a docker container. ## Current Behavior Doesn't start due to the above mentioned error. ## Steps to Reproduce 1. run the docker compose file 2. look at logs 3. see it restarting ## Environment **OS:** Arch **CPU architecture:** x86_64 **How docker service was installed:** Composer file ## Command used to create docker container (run/create/compose/screenshot) sudo docker-compose pull && sudo docker-compose up -d --remove-orphans ## Docker logs https://pastebin.com/raw/iY5vL4Vv

This post describes a simple solution to this problem, hopefully while a fix will be implemented upstream. I tested it on my system and it does work. Let us know if you’d like additional details on this fix.

I haven’t tested to reproduce your HomeAssistant issue yet, so maybe in a little bit…

Flox · March 21, 2021, 3:08pm

@MainrtNr5, I just had a quick look at that, and it seems we need to update our Home Assistant rock-on. A lot has possibly changed since this rock-on was introduced (2016!) and here it seems we need to keep running this container as the root user (docker’s default), whereas we currently run it as the owner of the share chosen for the Home Assistant config.

In this context, I could reproduce your error if, for HA config, I set the owner as any user other than root. If I chose a share and left the ownership to root, the HA rock-on starts normally and you can access the webUI.

Can you confirm you did change this share’s ownership to a user other than root? If yes, try to either revert the ownership to root or a new share without changing ownership.

Let see how this goes.

We do need to update our HA rock-on still, and thank you for bringing this to light! We do rely on the community for this, so reports such as yours are essential; thanks a lot!

Flox · March 21, 2021, 3:19pm

Here’s the Github issue I just created to keep track of this:

github.com/rockstor/rockon-registry

Update Home Assistant rock-on to latest recommended settings

opened 03:18PM - 21 Mar 21 UTC

closed 02:58PM - 29 May 22 UTC

FroggyFlox

As reported by our forum user **MainrtNr5**, our Home Assistant rock-on needs so…me updating due to some limitation when using a share not-owned by `root`: https://forum.rockstor.com/t/beta-cant-access-certain-rock-on-ui-opensuse-leap-linux-5-3-18-lp152-66-default-4-0-6-0/7706/5 In addition to fixing this (by removing the `"uid"` instruction in our json definition, we might also stick to the project's defaults as defined in their installation instructions: https://www.home-assistant.io/installation/linux#platform-installation ```shell script docker run --init -d \ --name homeassistant \ --restart=unless-stopped \ -v /etc/localtime:/etc/localtime:ro \ -v /PATH_TO_YOUR_CONFIG:/config \ --network=host \ homeassistant/home-assistant:stable ``` When comparing this to our current settings, two points stand out: 1. We should add the `--init` flag 2. We might also prefer to use the `:stable` tag rather than the currently used `:latest`.

MainrtNr5 · March 22, 2021, 6:10pm

Yes, I create a unique user, group, and share for every Rock-On config and then set the unique user and group as owner of the share. Maybe this is just complicating things?

Changing the owner back to root on the existing config share didn’t work but creating a new share and keeping the default access controls did work.

MainrtNr5 · March 22, 2021, 6:11pm

Thanks, I never considered that the image might be broken but I’ll take a look at this right away.