Plex no longer available on network

Rock-ons
1

Hi.

I’ve had some recent trouble with a Rock-On that i managed to sort out thanks to the help of @phillxnet :star: but thanks to this (or so I think) my Plex Rock-On is no longer available on the network.

The Rock-On (container) is up and running but if I check the ports my server is listening to using the ss -lntu command, I see all the usual suspects but nothing for port 32400.

Trying to re-configure the network for Plex tells me that it’s using a host network and when examining the networks closer with docker network ls I find that this is the only Rock-On using a host network and all the others are using a bridged network.

I can’t recall specifically choosing a host network for Plex, and when checking the installation instructions for the Plex Rock-On i can’t find any mention of explicitly chosing this option.

So, this leaves me with two questions:

  1. Should the Plex Rock-On have host networking to begin with?
  2. Regardless, what can I do to get Plex back on the network? :smile:

Thanks.

1 Like
2

@MainrtNr5

Glad you were able to sort out the other stuff. Yes, the Plex Rockon requires the host network (multi-cast messages and all that). You can see it in the json definition also being “hard-coded” (i.e. you never had a choice :slight_smile:).

image
image748×361 4.97 KB

May be you can post what your RockOn configuration currently looks like, e.g.:

image
image1164×633 30.6 KB

Cheers,

2 Likes
3

Hi Dan!

Here’s the config:

image
image789×392 7.78 KB

I have - as far as I know - not changed anything in here.

I have updated to the latest packages for OpenSuse, and I have reverted to the stable branch of Rockstor to see if that helped with my previous Rock-On issues.

4

Curious indeed. If I run ss -tulpwn | grep LISTEN | grep Plex

then I see this:

tcp	LISTEN	0	128	127.0.0.1:44303	0.0.0.0:*	users:(("Plex Script Hos",pid=26019,fd=4))
tcp	LISTEN	0	128	127.0.0.1:34833	0.0.0.0:*	users:(("Plex Script Hos",pid=26214,fd=4))
tcp	LISTEN	0	128	127.0.0.1:44017	0.0.0.0:*	users:(("Plex Script Hos",pid=25529,fd=4))
tcp	LISTEN	0	128	127.0.0.1:39473	0.0.0.0:*	users:(("Plex Script Hos",pid=25440,fd=8))
tcp	LISTEN	0	128	127.0.0.1:32401	0.0.0.0:*	users:(("Plex Media Serv",pid=25378,fd=57))
tcp	LISTEN	0	100	0.0.0.0:32469	0.0.0.0:*	users:(("Plex DLNA Serve",pid=25485,fd=22))
tcp	LISTEN	0	128	127.0.0.1:32600	0.0.0.0:*	users:(("Plex Tuner Serv",pid=25491,fd=9))
tcp	LISTEN	0	128	127.0.0.1:36871	0.0.0.0:*	users:(("Plex Script Hos",pid=25653,fd=4))
tcp	LISTEN	0	128	127.0.0.1:36011	0.0.0.0:*	users:(("Plex Script Hos",pid=25677,fd=6))
tcp	LISTEN	0	50	  0.0.0.0:1836  0.0.0.0:*	users:(("Plex DLNA Serve",pid=25485,fd=13))
tcp	LISTEN	0	128	        *:32400	      *:*	users:(("Plex Media Serv",pid=25378,fd=56))

My own solution would be to stop the Rockon, “uninstall” again using the script, and reinstall the Rockon. But I suspect @Flox or @phillxnet might have some better suggestions …

5

I’d rather not uninstall this Rock-On at all to be honest (it wasn’t this one I had problems with earlier). I’ve spent a bit of time getting things the way I want them in Plex. :slight_smile:

6

Understood. As long as you don’t remove the configuration directory that holds your Plex configuration, it should be a straightforward task, though

1 Like
7

Ah, so i uninstall the Rock-On and then re-install it using the same shares?

I’ve seen and read enough about the importance of shares when it comes to Rock-Ons to be a bit wary about re-using shares though. :sweat_smile:

8

I second all that @Hooverdan said.

I just wanted to bring further details on the following:

Always a good idea to be careful and ask before moving forward if you’re unsure, absolutely… I wish I had that wisdom many times in the past :wink:

It all comes down to what we’re doing when you select Shares to use during a Rock-on install wizard. Indeed, what you do there is simply selecting a Share to be bound to a docker container in a certain way. For instance, in Plex’s case, if you are selecting the share named Plex-config (that you created in Rockstor) to be used for the “Config Storage” field in the Plex Rock-on install wizard, it simply tells the Docker container that it can use this Share as the folder with the path /config as seen by the container. This folder still “belongs” to your Rockstor system, though, it is simply made available to the container. This means that when you uninstall the Rock-on and thus destroy the docker container, the “Plex-config” share will remain untouched and nothing will be deleted from there.
As Docker containers are designed to be ephemeral, binding shares/volumes like that is the only way to ensure you have persistent data when you destroy and rebuild the container.
This means that you can safely re-use the same Shares and settings (ports, etc…) when you re-install the same Rock-on and you should be back in the same state as you were before. Uninstalling a Rock-on and re-installing is using the same shares and settings as before is actually the recommended way to update a Rock-on (incidentally I am about to submit all this information to be added to our docs).

You are correct that re-using shares can be problematic in some cases, though: only when using the same share in multiple Rock-ons. Let’s continue with the Plex-config share example above, for instance. For Plex, this is where it will write to disk all the settings specific to Plex. Now, if you select this same Share as config storage for another Rock-on, you are risking the second Rock-on overwriting some of the files from the first one (and vice-versa). This is usually a very good recipe for creating conflicts so you should avoid it.

In general, I would recommend to always use distinct shares when installing Rock-ons, unless you know exactly how the Rock-on will use theses shares and you know you’ll be fine. Note, however, that you can add a share that is not initially pre-defined to some Rock-ons, in such case re-using the same is usually the intention. This is indeed commonly used to make some data available to multiple Rock-ons. You can have a look at the related section of our docs on that if you’re interested:
https://rockstor.com/docs/interface/overview.html#add-storage

Hope this helps,

1 Like
9

@MainrtNr5,

Sorry for the repeated messages, but I just realized I got distracted in my previous post and forgot to actually address your original issue.

First of all, could you describe how your issue is manifesting itself?
What happens when you click on the “Plex UI” button in Rockstor’s Rock-ons page?
What happens when you browse to the following? https://<your-rockstor-ip>:32400

Let’s see what re-installing will do to this problem first, as suggested by @Hooverdan. If it still does not fix the problem, here are a few places you can look at for further information (at the command line):

  • Docker logs: docker logs plex-linuxserver.io

This will likely spit out quite a bit of information so see if you can spot something with a warning or error, for instance.

You can also paste the output of the following to make sure it looks as it should be:

docker ps -a --filter "name=plex-linuxserver.io"

Finally, you can inspect the containers and make sure all settings are as they should (overkill but it will show you almost everything on the container’s settings):

docker inspect plex-linuxserver.io

Hopefully that will help move things forward.

2 Likes
10

The re-install didn’t help, and I figured out why with the help of the docker logs command; the share is read-only. The reason for this is that my SSD pool has a bad disk:

image
image811×308 18.7 KB

I knew about the bad disk, but I didn’t know that this meant that the shares would go into read-only mode. There’s more than this going on though as I can’t copy the data from the share to back it up, at least not using a SMB share.

Before I run the suggested btrfs command I just want to get some feedback on the situation, and if there’s anything else I should try or do first.

2 Likes