Web UI not accessible anymore after QNAP NAS update

[Onirale]

Problem description

After updating my NAS the web UI of Transmission can't be accessed anymore.

Description

Recently I updated my QNAP to QTS 5.2.0. This involved rebooting the NAS, after that I could access all my other containers but the Transmission one remains unreachable as everything request times out. My NAS is still accessible and the router hasn't allocated a new local IP.

Below is the docker compose that was working before the restart.

version: '3.3'
services:
    transmission-openvpn:
        container_name: openvpn_transmission
        cap_add:
            - NET_ADMIN
        volumes:
            - '/share/Docker/transmission/configuration:/config'
            - '/share/Docker/transmission/downloads:/data'
            - '/share/Docker/protonvpn/:/etc/openvpn/custom/'
        restart: unless-stopped
        environment:
            - OPENVPN_PROVIDER=custom
            - OPENVPN_CONFIG=fr.protonvpn.udp
            - OPENVPN_USERNAME=<personal_usr>+pmp
            - OPENVPN_PASSWORD=<password>
            - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60
            - LOCAL_NETWORK=192.168.1.0/24
            
            - PUID=0
            - TRANSMISSION_WEB_UI=flood-for-transmission
            - TRANSMISSION_DOWNLOAD_DIR="/data/seeding"
            - TRANSMISSION_RPC_USERNAME="Onirale"
            - DEBUG=true
        logging:
            driver: json-file
            options:
                max-size: 10m
        ports:
            - '8952:9091'
            - '19453:5800'

        image: haugene/transmission-openvpn:latest
        
    firefox:
        container_name: openvpn_firefox
        image: jlesage/firefox:latest
        volumes:
            - "/share/Docker/openvpn_firefox:/config:rw"
        restart: unless-stopped
        network_mode: "service:transmission-openvpn"
        depends_on:
            - transmission-openvpn

Neither Transmission nor Firefox containers are available. I'm using Portainer to manage everything, from there I can access the console fine. In transmission container when typing curl ifconfig.me i've got a VPN address as expected. The transmission logs show that everything is alright:

Tue Sep 10 19:11:52 UTC 2024

transmission auth not required
waiting for transmission to become responsive
transmission became responsive
No action needed, port hasn't changed

╭───────────────────╮
│ The Forwarded Port is: 36142 │
╰───────────────────╯

Using Portainer container bash access

Through Portainer I can access to the container with bash. It was possible for me to see all my seedings and even DL a torrent (took the linux one).

Tranmission container doesn't have a firewall activated as shown below:

root@ebbdb60c2528:/# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

From my NAS through SSH

Connecting to my NAS using SSH I pinged the webui adress and the following is being returned:

PING 192.168.1.36:8952(192.168.1.36): 56 data bytes
64 bytes from 192.168.1.36: seq=0 ttl=64 time=0.074 ms
64 bytes from 192.168.1.36: seq=1 ttl=64 time=0.084 ms
64 bytes from 192.168.1.36: seq=2 ttl=64 time=0.063 ms
64 bytes from 192.168.1.36: seq=3 ttl=64 time=0.092 ms
64 bytes from 192.168.1.36: seq=4 ttl=64 time=0.085 ms
64 bytes from 192.168.1.36: seq=5 ttl=64 time=0.085 ms
64 bytes from 192.168.1.36: seq=6 ttl=64 time=0.084 ms
64 bytes from 192.168.1.36: seq=7 ttl=64 time=0.069 ms
64 bytes from 192.168.1.36: seq=8 ttl=64 time=0.083 ms
64 bytes from 192.168.1.36: seq=9 ttl=64 time=0.087 ms
64 bytes from 192.168.1.36: seq=10 ttl=64 time=0.087 ms
64 bytes from 192.168.1.36: seq=11 ttl=64 time=0.086 ms
64 bytes from 192.168.1.36: seq=12 ttl=64 time=0.076 ms
64 bytes from 192.168.1.36: seq=13 ttl=64 time=0.083 ms
64 bytes from 192.168.1.36: seq=14 ttl=64 time=0.090 ms
64 bytes from 192.168.1.36: seq=15 ttl=64 time=0.087 ms
64 bytes from 192.168.1.36: seq=16 ttl=64 time=0.067 ms
64 bytes from 192.168.1.36: seq=17 ttl=64 time=0.086 ms
64 bytes from 192.168.1.36: seq=18 ttl=64 time=0.086 ms
--- 192.168.1.36:8952ping statistics ---
19 packets transmitted, 19 packets received, 0% packet loss
round-trip min/avg/max = 0.063/0.081/0.092 ms

I've looked around the discussions but couldn't find any similar case. Any help would be greatly appreciated.
Thanks :)

[EDIT]: SOLUTION FOUND

Solution came from looking the container info from my NAS. Connecting through SSH on my NAS I then ran the following command docker inspect openvpn_transmission which returned all the info you need on your running container.
At the very end of it there's a NetworkSettings section detailling how network is handled in the container. In particular the Networks/transmission_default/IPAddress. Typing the given IP address there besides the unmapped port (ie: 9091 in transmission case) I was able to access the UI.

Can't explain why the routing is not happening but at least I can connect as a hotfix. I'll keep investigating on my side but I believe it's beyong the scope of this discussion.

Discussion will be left open as it might serve other people.

[Onirale]

SOLUTION FOUND

Solution came from looking the container info from my NAS. Connecting through SSH on my NAS I then ran the following command docker inspect openvpn_transmission which returned all the info you need on your running container.
At the very end of it there's a NetworkSettings section detailling how network is handled in the container. In particular the Networks/transmission_default/IPAddress. Typing the given IP address there besides the unmapped port (ie: 9091 in transmission case) I was able to access the UI.

Can't explain why the routing is not happening but at least I can connect as a hotfix. I'll keep investigating on my side but I believe it's beyong the scope of this discussion.

Discussion will be left open as it might serve other people.