I have the transmission app running perfectly on my freedombox. I can access its web interface both in my local network and when outside.
Though, I cant seem to figure out any way to access it remotely with a client app (running on phone or desktop). If anyone has been successful, I would appreciate any guidance on how they setup their client.
Thanks in advance.
Hello again.
Can anyone get transmission-rpc working?
Thanks again…
Hi there,
can you explain in more detail what is not working?
I did a quick search and I found Transmission Remote GUI as a remote client and this article how to set it up.
Did you try this already?
Cheers
If you are using port 443, then you will need to configure Apache reverse proxy for the “RPC path”.
Hi @jonny
The error message I recieve on my client app is
QNetworkReply::NetworkError::ConnectionRefusedError: Connection refused
URL: https://mydomain.com:9091/transmission/rpc
Did not establish HTTP connection
My webui works just fine.
Tried a lot of things - just cant get my client to connect.
Now that you’ve asked; more detail on my configuration below.
Remote Client OS: Lineage OS - Android 10 (degoogled with Micro-G)
Remote Client App: Tremotesf (from F-Droid Repo)
Remote Client Configuration:
Domain: mydomain.com
Port: 9091
API path: /transmission/rpc
HTTPS checked (no certificates installed or checked)
Authentication: Username: transmission / Password: transmission
Host (FBX) Version: FreedomBox version 23.6
My /etc/transmission-daemon/settings.json file is as below (it’s the default configuration installed with FBX):
"rpc-authentication-required": false,
"rpc-bind-address": "0.0.0.0",
"rpc-enabled": true,
"rpc-host-whitelist": "",
"rpc-host-whitelist-enabled": true,
"rpc-password": "{b2467fdee0513622d6f502464a97b650245796b07t4HO529",
"rpc-port": 9091,
"rpc-url": "/transmission/",
"rpc-username": "transmission",
"rpc-whitelist": "127.0.0.1",
"rpc-whitelist-enabled": false,
Thanks.
Hi @jvalleroy
Tried following this with no success.
I created an /etc/apache2/sites-available/01-transmission.conf file with the following:
<VirtualHost *:443>
Servername mydomain.com
<Location "/transmission/rpc">
ProxyPass "http://localhost:9091/transmission/rpc"
ProxyPassReverse " http://localhost:9091/transmission/rpc"
SetEnv nokeepalive
</Location>
LogLevel Warn
ErrorLog ${APACHE_LOG_DIR}/tranmission-error.log
CustomLog ${APACHE_LOG_DIR}/transmission-access.log combined
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/mydomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.com/privkey.pem
</VirtualHost>
and configured my /etc/transmission-daemon/settings.json with following:
"rpc-enabled": true,
"rpc-bind-address": "127.0.0.1",
"rpc-port": 9091,
"rpc-url": "/transmission/",
"rpc-whitelist": "",
"rpc-whitelist-enabled": false,
"rpc-host-whitelist": "127.0.0.1",
"rpc-host-whitelist-enabled": true,
"rpc-authentication-required": false,
All of these align with the link I shared with above. The only thing I didn’t do (to not break my FBX user login) was the part requiring htpasswd
Haven’t succeded as my client is still giving
QNetworkReply::NetworkError::ConnectionRefusedError: Connection refused
URL: https://mydomain.com:9091/transmission/rpc
Did not establish HTTP connection
Any help appreciated.
Thanks.
I’m afraid I’m not as deep into the matter as you are. What I can tell you is, I experienced the same issue like you when I tried setting up a RPC Client yesterday.
A scan of port 9091 “nmap -p 9091 xyz.fbx.one” came out negative.
Found this. It seems like the same issue but with a docker installation.
thanks @jonny
I will keep looking when I have the time and share if I find any solution.
Likewise, will appreciate if you have any findings.
I submitted a merge request to enable remote access with transmission. The essential problem is that GUIs expect to use simple HTTP Basic authentication where FreedomBox has implemented more complex single sign-on. The merge request will setup Basic authentication on a slightly different URL /transmission-remote/rpc.
The change will be available in next version of Freedombox. In the meanwhile, if you wish to enable remote access do the following:
Create a file /etc/apache2/conf-available/my-transmission-remote.conf with following contents:
<Location /transmission-remote>
ProxyPass http://localhost:9091/transmission
Include includes/freedombox-auth-ldap.conf
Require ldap-group cn=admin,ou=groups,dc=thisbox
Require ldap-group cn=bit-torrent,ou=groups,dc=thisbox
</Location>
Then run the following commands:
sudo a2enconf my-transmission-remote
sudo systemctl reload apache2
Then connect with a Transmission remote GUI using the URL /transmission-remote/rpc. I tested with F-Droid app tremotesf.
Hi @sunil. Thanks for the support. Very much appreciated. Though unfortunately it still seems not to work. The client is giving the following error.
QNetworkReply::NetworkError::ConnectionRefusedError: Connection refused
URL: http://mydomain.com:9091/transmission-remote/rpc
Did not establish HTTP connection
Thanks again.
Hi @Ged296123, you need to specify the port as 443. I newly documented this here: FreedomBox/Manual/Transmission - Debian Wiki . If things work for you, feel free to add more details there.
Thanks @sunil, that did the trick.
My client successfully connected, though I am getting a “Parsing error” - one which I will look into to see if I can solve. It’ probably related to my Transmission configuration which I fiddled with to this point.
In regard to my “not being connected” issue, I think I can mark this post [SOLVED] (though for some reason I cant edit my initial post).
For anyone who wants to configure their client, I’m sharing my settings below:
Remote Client App: Tremotesf (from F-Droid Repo)
Conection Settings:
Will add further details if I solve the parsing error issue.
Happy torrenting!
My first assumption was that due to my fiddling with the settings.json file, the problem lie there. However, I’ve run the file through some online validation and the default file seemed fine.
I can’t reach the Android clients logs (lack of technical knowledge). Instead, I installed a flatpak on my linux desktop and run it from CLI to see any errors or outputs. I’m sharing the output below.
DEBUG fragments::app > Fragments (de.haeckerfelix.Fragments) () - Version 2.1 (default)
DEBUG fragments::backend::connection_store > Read connection data
DEBUG fragments::app::imp > Activate GIO Application...
INFO fragments::app::imp > Created application window.
DEBUG fragments::backend::connection_store > Write connection data
DEBUG fragments::backend::connection_manager > Connect to https://mydomain.com:443/transmission-remote/rpc
DEBUG transmission_gobject::client > Connect to https://mydomain.com:443/transmission-remote/rpc ...
WARN fragments::backend::connection_manager > Can't connect to https://mydomain.com:443/transmission-remote/rpc: transmission authentication needed
ERROR transmission_client::client > Unable to parse json: expected value at line 1 column 1
WARN transmission_client::client > JSON: "<h1>301: Moved Permanently</h1>"
WARN transmission_gobject::client > Unable to authenticate, no rpc connection
DEBUG fragments::backend::connection_manager > Connect to https://mydomain.com:443/transmission-remote/rpc
DEBUG transmission_gobject::client > Connect to https://mydomain.com:443/transmission-remote/rpc ...
ERROR transmission_client::client > Unable to parse json: expected value at line 1 column 1
WARN transmission_client::client > JSON: "<h1>301: Moved Permanently</h1>"
WARN fragments::backend::connection_manager > Can't connect to https://mydomain.com:443/transmission-remote/rpc: serde_json error
Is it possible that there’s something I should go back to and check? It seems like the problem is still on the server side.
Thanks.
As far as Android, you’ll probably need Android studio and put the phone in developer mode so you can connect it via USB and live read logging and such.
Looks like web server on your FreedomBox has returned a 301 redirect to another location when contacting the URL https://mydomain.com:443/transmission-remote/rpc. This should not have happened. If you done some experimentation with Apache configuration removing it might help. To check that all the configuration on the server side working, run the following test:
Open https://mydomain.com:443/transmission-remote/web using a web browser. It should open a username/password dialog. Enter FreedomBox credentials (admin account or account with bit-torrent group). You should see Transmission web UI and it should work as expected. If this part does not work, something wrong with web server configuration.
Now, try the mobile app.
I found the culprit!
After doing some search online, I found one site that mentioned of 301 errors happening if a Rewrite module created loop with a Location module.
It just hit me that my-transmission-remote.conf was enabled while the transmission-plinth.conf was also active. I went to @sunil 's very recent commit (to be merged) and copied his apache configuration for the transmission-plinth.conf, disable my new my-transmission-remote.conf and presto! All is in order now.
Thanks @sunil and everybody else for the support. Really happy to have this working.
@Ged296123 if you modify a file that is shipped by FreedomBox (transmission-plinth.conf), then FreedomBox won’t automatically upgrade to the next version. You will need to manually upgrade and choose to get the new configuration file discarding old changes.
BTW, having the configuration in two files my-transmission-remote.conf and transmission-plinth.conf should have worked fine. That is why I suggested that change.
@sunil my bad… didn’t know I’d break the update mechanism : (
After 1 manual update - would it get back to normal?
Maybe I made a mistake when copying your configuration file with my-transmission-remote… I’ve been trying to get this to work like I want for some time - I could easily have skipped something… thank you again.
During the manual upgrade, when it asks you to pick which configuration file you want to keep, select the one that comes with the new package (this will have configuration you need anyway). After this, you are back on track with the automatic upgrades.