Plex media server "Preferred Network Interface" always selects last in the list

Server Version#: 1.30.1.6562
Player Version#: not using

When I try to select the IP address from the list bound to the single Nic, It always uses the last in the list. Upon examination of the web source I noticed that the SELECT has all the entries marked as SELECTED, which means the last one will always be used.

EDIT: well it seems on service restart it just binds to them all..

any way to force it to just listen on one IP? Ive got multiple services running on this machine and they need unique IPs for proper DNS resolution.

maybe another setting that handles that?

– Chris

Those are aliases?

Netplan should allow you to create what you need.

This is why:

network:
  version: 2
  renderer:  networkd
  bonds:
    bond0:
      dhcp4: false
      dhcp6: false
      interfaces:
      - enp2s0f0
      - enp2s0f1
      parameters:
        lacp-rate: fast
        mode: 802.3ad
        transmit-hash-policy: layer3+4
  ethernets:
    enp2s0f0: {}
    enp2s0f1: {}
  bridges:
    br0:
      macaddress: c2:e5:24:d2:0f:8c
      addresses: []
      dhcp4: true
      dhcp6: true
      nameservers: {}
      interfaces:
        - bond0

which allows this to happen:

bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST>  mtu 1500
        ether c2:e5:24:d2:0f:8c  txqueuelen 1000  (Ethernet)
        RX packets 2846622643  bytes 3566812410251 (3.5 TB)
        RX errors 0  dropped 91275  overruns 0  frame 0
        TX packets 5530614614  bytes 7774397723218 (7.7 TB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.20  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::c0e5:24ff:fed2:f8c  prefixlen 64  scopeid 0x20<link>
        inet6 2601:985:500:360::2000  prefixlen 128  scopeid 0x0<global>
        inet6 2601:985:500:360:c0e5:24ff:fed2:f8c  prefixlen 64  scopeid 0x0<global>
        ether c2:e5:24:d2:0f:8c  txqueuelen 1000  (Ethernet)
        RX packets 596341647  bytes 1476200437530 (1.4 TB)
        RX errors 0  dropped 1165081  overruns 0  frame 0
        TX packets 307253115  bytes 7425466894594 (7.4 TB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp2s0f0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether c2:e5:24:d2:0f:8c  txqueuelen 1000  (Ethernet)
        RX packets 68109330  bytes 21690123048 (21.6 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3150932466  bytes 4571707652416 (4.5 TB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp2s0f1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether c2:e5:24:d2:0f:8c  txqueuelen 1000  (Ethernet)
        RX packets 2778513314  bytes 3545122287546 (3.5 TB)
        RX errors 0  dropped 91275  overruns 0  frame 0
        TX packets 2379682148  bytes 3202690070802 (3.2 TB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 10514114  bytes 1624544234 (1.6 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10514114  bytes 1624544234 (1.6 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth1d428247: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether d6:0e:7c:0b:42:44  txqueuelen 1000  (Ethernet)
        RX packets 34563  bytes 3436108 (3.4 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10530185  bytes 3729415970 (3.7 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth53f1f6c0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether ba:c3:04:31:d6:de  txqueuelen 1000  (Ethernet)
        RX packets 37988  bytes 4237987 (4.2 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10534529  bytes 3731060355 (3.7 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth69fd1524: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 72:92:ab:00:32:03  txqueuelen 1000  (Ethernet)
        RX packets 247586  bytes 24118969 (24.1 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10736265  bytes 3816959191 (3.8 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethb6951a7c: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 8e:40:a3:ba:41:e0  txqueuelen 1000  (Ethernet)
        RX packets 883534  bytes 446334199 (446.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9850430  bytes 3304909772 (3.3 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethcb0fd9bb: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 5a:e0:d3:d7:b6:ca  txqueuelen 1000  (Ethernet)
        RX packets 176879364  bytes 13971763899 (13.9 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 273973062  bytes 1247888755928 (1.2 TB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[chuck@glockner netplan.2010]$

Last I looked, if you create multiple bridge adapters, PMS will allow you to select it.
(Adapter has IP, LINK, and Gateway)

Ok so I understand what your getting at. If it will “see” an interface name and not the actual IP then the SELECT code above makes sense… The values above are all “ens1” and the code probably just says if “value” == “ens1” then “Selected” == “selected”…

to test this I put in another Nic and set it up with the single IP.

network:
  version: 2
  renderer: networkd
  ethernets:
        ens1:
                addresses:
                        - 192.168.200.2/24
                        - 192.168.200.4/24
                        - 192.168.200.5/24
                        - 192.168.200.6/24
                        - 192.168.200.7/24
                        - 192.168.200.8/24
                        - 192.168.200.9/24
                routes:
                        - to: default
                          via: 192.168.200.1
                nameservers:
                        addresses: [192.168.200.2]
        enp1s0:
                addresses:
                        - 192.168.200.3/24
                nameservers: 
                        addresses: [192.168.200.2]

Upon configuring it to use just this interface the UI does show that this one interface “enp1s0” is the only one selected:

This however still does not give [my] expected results. Looking at the open ports and services…

root@portable:~# netstat -an | grep 32400
tcp        0      0 0.0.0.0:32400           0.0.0.0:*               LISTEN     
tcp        0      0 192.168.200.2:32400     192.168.100.28:55944    ESTABLISHED

So regardless of the “Preferred network interface” it will always be listening on all interfaces… And indeed accepts connection on other addresses.

Looking this this seems to not work as I would expect… what intended with this parameter?

Thanks…

Chris

[EDIT] noting that your earlier explanation that it needed a LINK, IP and Gateway. Since the first IP entry has a default route, Netplan won’t allow a second “default” route (as it shouldn’t). Regardless this does route properly as my setup here has 5 distinct networks…

That is correct, and expected.

This parameter specifies the interface local Plex clients will use to connect to the server. It does not do this by using this as the interface to which it should bind. Rather it uses this to determine which local interface should be published to Plex’s servers. When signed-in clients ask Plex’s servers which local Plex Media Servers it has access to, this interface is what is given as the local connection information.

You can validate this by examining the XML returned from this URL:

https://plex.tv/api/resources?includeIPv6=1&includeHttps=1&X-Plex-Token=<your Plex online token>

(How to find your token)

It will list all of your signed-in servers and clients and their published connection information. As you change the preferred network interface, you can refresh that page and should see the change reflected there. It happens pretty quickly.

Ok understood…

So confirming, there is no way to force it to bind the web services to a particular interface?

Thanks

– Chris

To my knowledge, no.

Ok thanks for the response…

If anyones interested i’d like to add this to the wish list.

— Chris

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.