Docker-transmission-openvpn: web ui on transmission doesn't show any activity

[hildebrau]

I've been battling this all container all day. It was working fine a few months back. Today I had to overhaul the VPN connection and set it to custom and provide it with a new .ovpn file to get it to connect. Then transmission finally started. That's where this issue starts.

I've tried the latest, 1.9, and dev tags. I'm currently on the haugene/transmission-openvpn:dev tag.

I've tried all three WEB UI's. The default throws an error of not being able to connect and asks me to reload the page. Mind you, the Transmission UI loads up fine, but it simply doesn't show any active torrent history, etc.

The other two WEB UI's do not throw errors; but they also do not show me any active torrent or past torrent history.

Inside the container terminal, I was able to do a "transmission-remote" command to list the current torrent queue and even add a torrent. That torrent has since wrapped up to completion. But I've yet to get the web UI to show anything about it.

I'm sort of out of ideas. I've been through the container console logs, and the transmission.log; but I don't see anything of use in there. It seems to think it is working just peachy.

I've checked permissions; and near as I can tell, all the /data subdirs and files have user +rw access at least, and most have g+rw and o+r access. User and Group are the "abc:users" default. transmission-daemon appears to be running as user 'abc' in the container.

[2018-02-20 14:36:11.440 CST] Transmission 2.84 (14307) started (session.c:738)
[2018-02-20 14:36:11.440 CST] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:878)
[2018-02-20 14:36:11.440 CST] RPC Server Serving RPC and Web requests on port 127.0.0.1:9091/transmission/ (rpc-server.c:1122)
[2018-02-20 14:36:11.440 CST] Port Forwarding Stopped (port-forwarding.c:180)
[2018-02-20 14:36:11.440 CST] UDP Failed to set receive buffer: requested 4194304, got 425984 (tr-udp.c:78)
[2018-02-20 14:36:11.440 CST] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:83)
[2018-02-20 14:36:11.440 CST] UDP Failed to set send buffer: requested 1048576, got 425984 (tr-udp.c:89)
[2018-02-20 14:36:11.440 CST] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:94)
[2018-02-20 14:36:11.440 CST] DHT Reusing old id (tr-dht.c:306)
[2018-02-20 14:36:11.440 CST] DHT Bootstrapping from 42 IPv4 nodes (tr-dht.c:154)
[2018-02-20 14:36:11.440 CST] Using settings from "/data/transmission-home" (daemon.c:557)
[2018-02-20 14:36:11.440 CST] Saved "/data/transmission-home/settings.json" (variant.c:1214)
[2018-02-20 14:36:11.440 CST] Watching "/data/watch" for new .torrent files (daemon.c:595)
[2018-02-20 14:36:11.440 CST] Using inotify to watch directory "/data/watch" (watch.c:72)
[2018-02-20 14:36:11.440 CST] Loaded 1 torrents (session.c:1994)

What can I look at next to hunt down this GUI problem?

Thanks!

[berglh]

I think I'm experiencing the same problem. transmission-remote command inside the contain seems to show the daemon running OK and listing all torrents correctly, I can get the web ui to load perfectly fine, but have the same error message in the web ui that is unable to talk to the daemon.

Connection Failed
Could not connect to the server. You may need to reload the page to reconnect.

I too have been running out of ideas for this particular problem.

[berglh]

@hildebrau As I was running the container behind a reverse proxy server, I had always relied on the rpc-host-whitelist-enabled defaulting to false. Looking at the transmission settings page I noticed, rpc-host-whitelist-enabled: Boolean (default = true. Added in v2.93)

So in my docker environment file for the container, I added the following variable:
TRANSMISSION_RPC_HOST_WHITELIST_ENABLED=false

Now everything appears to be working for me. This at least solved my problem.

[Mikiya83]

I can't access WebUI by default but i added -e "TRANSMISSION_RPC_HOST_WHITELIST=*" \ and it's working with version 1.22, thanks for the update :)

[h45rd]

You could also completely disable the new whitelisting approach with TRANSMISSION_RPC_HOST_WHITELIST_ENABLED=false

[hildebrau]

berglh, thank you for figuring that out. I should have mentioned I'm doing the reverse proxy with nginx as well. Your solution worked perfectly in my docker compose file.

Now, if I could just figure out how to get this container to work with the nzb360 Android app. I think it's the app that isn't working yet.

[haugene]

Changed default settings to not run with the whitelist. We're already disabling the other whitelist parameter, while they're both true by transmission defaults. The rationale being that networking is different in containers and depending on local setup. This should therefore be a config option for those who want stricter security, but not on by default.

Hopefully that resolves this issue. Closing now, re-open if the problem persists.

EDIT: For now, the changes are only available on the dev tag