Problem with adding the service ( Jellyfin ) - rejected ports

[Qbaakr]

Hello I would like to replace Plex with Jellyfin I made some corrections in the config.yaml file:

Jellyfin

• name: jellyfin enabled: true VPN: false

  customFile: custom/jellyfin.yaml traefik: enabled: true rules:

  • host: jellyfin.${TRAEFIK_DOMAIN} httpAuth: false internalPort: 8096 httpOnly: true

and I added yaml in custom: version: '3.5' services: jellyfin: image: jellyfin/jellyfin container_name: jellyfin restart: always network_mode: host ports:

• "8096:8096"
• "8920:8920" #optional
• "7359:7359/udp" #optional
• "1900:1900/udp" #optional volumes:
• configjellyfin:/config
• /data/torrents:/media
• /data/config:/cashe

  Optional - alternative address used for autodiscovery

  environment:

• TZ=${TZ}
• VERSION=latest
• PGID=${PGID}
• PUID=${PUID}

volumes: configjellyfin: driver: local-persist driver_opts: mountpoint: $HOST_CONFIG_PATH/jellyfin

I did the same thing as configuring Plex, but I still get an error: ! jellyfin Published ports are discarded when using host network mode Anyone have an idea where I made a mistake? Regards

[tblaudez]

Hey there,

When it comes to Docker, you have two choices regarding port mapping :

1. You use the network_mode: host to publish every ports used by the container on your host system
2. You use the ports config to publish only the ports you believe are necessary

@jfroment made his choice in the dev branch regarding Plex, he chose to use network_mode: host and removed all the lines regarding the specific ports (https://github.com/jfroment/seedbox/commit/26909f2a7edc8b18cdbd986b462f6d50a2de295a) I chose to do the opposite and I explicitely published all the ports needed by Plex. Both work fine.

I assume the same logic can be applied to Jellyfin. You didn't explain what kind of error you encounter, can you give more details ?

[Qbaakr]

Hello ;) Thanks for the answer Even if I remove the ports from custom.yaml and leave the "host" alone, it starts but - "BAD GETEWAY" If necessary, I can post the log from the container. p.s.

• /data/config:/cashe corrected to cache

[tblaudez]

I see you added the line httpOnly: true in your Jellyfin configuration inside the config.yaml, is that intended ? The BAD GATEWAY error seems to indicate that the Traefik container is failing to connect to the Jellyfin container.

[Qbaakr]

Hi Yes, httpOnly: true is correct because I have a problem with generating certificates - which was discussed in an earlier topic, and due to lack of knowledge and skills, I abandoned this topic :( If I understood correctly, I should set network_mode in config Jellyfin yaml: traefik_network? because at this point there is a host - and in fact after entering http://localhost:8096 it connects to the server. But would it be correct if I added the ports to traefik in config/ports or just to the Jellyfin yaml?

[jfroment]

I'm not quite sure I understood the issue. With docker, there are two modes for networking (in fact there's more but that's irrelevant for this issue):

• bridge mode (default one) - where all containers run in a subnet, which is bridged from the outside world using NAT. In docker compose, all containers from the stack use the same network (which is defined here). Container expose ports, and Traefik connects to the containers using hostname (which is the name of the docker compose service) + port (which is the field internalPort in the config.yaml). Exposing a port for a bridged container indicates docker that a firewall port mapping rule must be created for a given port.
• host mode - where the container runs using the host's network stack. All container ports are automatically exposed directly at the host level, as you would have without docker (when you install Jellyfin directly on your system using a package manager for example), given no host firewall is set in DENY mode for inbound. So with host mode, there's no NAT, so no need of port mapping / expose at container definition (in docker compose).

Concerning the httpOnly, this is only to tell Traefik to listen on port 80 to bypass certificate generation and be able to access the service without TLS via Traefik. But Traefik is used only when you access the service using a hostname. (something.yourdomain.com). If you access it via IP:port, you bypass Traefik, so httpOnly is irrelevant here. Bridge/Host considerations are completely separate from this topic. So you have a total of 4 choices to access your services:

• Bridge mode + TLS via Traefik (hostname) => the default for most services in this repo
• Bridge mode + httpOnly (hostname) => if you do not need certificates but still have a domain and do not want to open unnecessary ports.
• Host mode + TLS via Traefik (hostname for TLS + direct access on host ip:exposed port) => If your app should be accessed both from web (hostname/TLS) + some other client directly on a given port, and plenty of ports must be open, like Plex. Also for Plex, using host mode lets it distinguish streams from Internet (family, friends) and from your LAN. If Plex was bridged, everything would be seen as "WAN/Internet/Remote stream".
• Host mode + httpOnly => If your container does not need TLS access or provides it (like Nextcloud which has a passthrough requirement by default) and there are many ports to open. I do not have an example of such a good se case for this.

[Qbaakr]

Hello As I wrote earlier, unfortunately I have a problem with certificates and I don't know how to deal with it - that's why I use httpOnly. Therefore, the first and third options are out of the question for now. In Host mode it works correctly - after the ip address :port I wanted to run it in the second option. In bridge mode, it displays a "bad gateway" error In the /service/customs/jellyfin.yaml file network_mode: bridge ports:

• "8096:8096"
• "8920:8920" #optional
• "7359:7359/udp" #optional
• "1900:1900/udp" #optional and in config.yaml customFile: custom/jellyfin.yaml traefik: enabled: true rules:
  • host: jellyfin.${TRAEFIK_DOMAIN} httpAuth: false internalPort: 8096 httpOnly: true and I can't find the error here :( Regards

p.s. I know I'm doing something wrong with port forwarding because after changing the httpAuth: to true configuration, it normally requests username and password even though it doesn't display the page...