Jellyfin Server not binding to LAN address

[chilled]

Having same issue on bare metal fresh install of Debian Bookworm with networkmanager (I use the PC as desktop and server but is not on 24/7). No proxy, no vm, no docker container, no https, only LAN access and same firewall rules I've used for years.

The only thing that's worked for me is login in and restarting the systemd unit: # systemctl restart jellyfin.service.

I've been using Jellyfin since at least three (3) years ago with the same PC/OS/installation combo without issues until yesterday, when I decided to make a clean up and reinstall the OS.

Can you stop jellyfin, delete network.xml, and start jellyfin?  It will regenerate the file with defaults.  A couple other people weird network issues and deleting this file helped them.

Nothing changed unfortunately, im calling that it's a debian issue
Update: it was a debian issue
had to replace this line

Code:

allow-hotplug enp4s0

with

Code:

auto enp4s0

this makes me honestly doubt the good reputation about debians stability, if an update breaks your networking randomly

Are you sure that solved the issue? It has been the default in Debian for the /etc/network/interfaces file since I can remember.

[Novus]

I think that I have the same issue but with Windows. Local Host is working but no other computers in the network can´t connect. Chrome says "ERR_CONNECTION_TIMED_OUT"
I deleted the network.xml but the problem is still there.

Windows 11 with Jellyfin localy installed the Host has HyperV running and the main "Networkcard" is a HyperV Virtual Networkcard.
Everthing ran fine with 10.8.13 until yesterday when I upgraded to 10.9.1

Any tips?

Code:

[2024-05-15 09:16:39.384 +02:00] [INF] [15] Emby.Server.Implementations.ScheduledTasks.TaskManager: "Aktualisiere Plugins" Completed after 0 minute(s) and 3 seconds
[2024-05-15 09:18:30.176 +02:00] [INF] [6] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "127.0.0.1" request
[2024-05-15 09:18:34.109 +02:00] [INF] [15] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "127.0.0.1" closed
[2024-05-15 09:20:25.895 +02:00] [INF] [9] Jellyfin.Networking.Manager.NetworkManager: Defined LAN addresses: ["127.0.0.1/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
[2024-05-15 09:20:25.899 +02:00] [INF] [9] Jellyfin.Networking.Manager.NetworkManager: Defined LAN exclusions: []
[2024-05-15 09:20:25.902 +02:00] [INF] [9] Jellyfin.Networking.Manager.NetworkManager: Using LAN addresses: ["127.0.0.1/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
[2024-05-15 09:20:25.906 +02:00] [INF] [9] Jellyfin.Networking.Manager.NetworkManager: Using bind addresses: []
[2024-05-15 09:20:25.914 +02:00] [INF] [9] Jellyfin.Networking.Manager.NetworkManager: Remote IP filter is "Allowlist"
[2024-05-15 09:20:25.916 +02:00] [INF] [9] Jellyfin.Networking.Manager.NetworkManager: Filter list: []
[2024-05-15 09:20:28.969 +02:00] [WRN] [9] Jellyfin.Networking.Manager.NetworkManager: "127.0.0.1": Only loopback "127.0.0.1" returned, using that as bind address.
[2024-05-15 09:20:32.196 +02:00] [INF] [22] Emby.Server.Implementations.Session.SessionManager: Sending shutdown notifications
[2024-05-15 09:20:32.208 +02:00] [INF] [9] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "127.0.0.1" closed
[2024-05-15 09:20:32.225 +02:00] [INF] [17] Jellyfin.Networking.PortForwardingHost: Stopping NAT discovery

Code:

<?xml version="1.0" encoding="utf-8"?>
<NetworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <BaseUrl />
  <EnableHttps>false</EnableHttps>
  <RequireHttps>false</RequireHttps>
  <InternalHttpPort>8096</InternalHttpPort>
  <InternalHttpsPort>8920</InternalHttpsPort>
  <PublicHttpPort>8096</PublicHttpPort>
  <PublicHttpsPort>8920</PublicHttpsPort>
  <AutoDiscovery>true</AutoDiscovery>
  <EnableUPnP>false</EnableUPnP>
  <EnableIPv4>true</EnableIPv4>
  <EnableIPv6>false</EnableIPv6>
  <EnableRemoteAccess>true</EnableRemoteAccess>
  <LocalNetworkSubnets />
  <LocalNetworkAddresses />
  <KnownProxies />
  <IgnoreVirtualInterfaces>true</IgnoreVirtualInterfaces>
  <VirtualInterfaceNames>
    <string>veth</string>
  </VirtualInterfaceNames>
  <EnablePublishedServerUriByRequest>false</EnablePublishedServerUriByRequest>
  <PublishedServerUriBySubnet />
  <RemoteIPFilter />
  <IsRemoteIPFilterBlacklist>false</IsRemoteIPFilterBlacklist>
</NetworkConfiguration>

Double check that the name of the HyperV NIC doesn't start with "veth" since Jellyfin ignores those by default.  Also double check that when you upgraded that the Windows Firewall rule is still there.

It was really the name of the network card. But that's new, isn't it? It still worked before with the 10.8

I checked the firewall first of all.
Thank you very much, I was getting desperate.

[TheDreadPirate]

Perhaps you disabled the vethernet ignore option before? And it was reset back to enabled during the upgrade? IDK.

[Novus]

I don't think I've ever heard of the option. Where can I deactivate this?

[TheDreadPirate]

Dashboard > Networking. There should be a check box or drop down to ignore virtual interfaces (I don't have my Jellyfin in front of me to find the exact name)

[Novus]

I cant find it but is okay. I will edit the XML on my other installion. Thank you!!

[penis]

Having same issue on bare metal fresh install of Debian Bookworm with networkmanager (I use the PC as desktop and server but is not on 24/7). No proxy, no vm, no docker container, no https, only LAN access and same firewall rules I've used for years.

The only thing that's worked for me is login in and restarting the systemd unit: # systemctl restart jellyfin.service.

I've been using Jellyfin since at least three (3) years ago with the same PC/OS/installation combo without issues until yesterday, when I decided to make a clean up and reinstall the OS.

Can you stop jellyfin, delete network.xml, and start jellyfin?  It will regenerate the file with defaults.  A couple other people weird network issues and deleting this file helped them.

Nothing changed unfortunately, im calling that it's a debian issue
Update: it was a debian issue
had to replace this line

Code:

allow-hotplug enp4s0

with

Code:

auto enp4s0

this makes me honestly doubt the good reputation about debians stability, if an update breaks your networking randomly

Are you sure that solved the issue? It has been the default in Debian for the /etc/network/interfaces file since I can remember.

Pretty sure it solved the issue. Changed it back and forth a few times and it consistently only worked when set to auto.
Not sure why debian decided to change it to allow-hotplug though. Maybe because my hardware is pretty exotic.