Transmission error: "Could not connect to the server."

problema · September 24, 2025, 7:57pm

Hi.

Problem description
When starting the Transmission web interface, the error shown in the image appears, making it impossible to manage the app.

The Plinth diagnostic tool returns perfect results.
And journalctl -u transmission-daemon does not return any errors.

Things I tried that didn’t work:

reload page with Ctrl+Shift+R,
changing the Transmission download location from Plinth,
restarting the service from Plinth,
restarting the server,
reinstalling the application.

Steps to reproduce
Difficult. I hadn’t used Transmission for a long time, so I can’t say exactly when it happened or what events might have caused it.

Expected results
Use the Transmission web interface as usual.

Actual results
An error pop-up window appears with this message:

Connection failed

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

Screenshot

Information

Software: FreedomBox v25.11 on Debian GNU/Linux 13 (trixie)
Hardware: x86-64 PC
Installation method: via apt install freedombox

Sunil · September 24, 2025, 9:15pm

I could not reproduce this problem by installing on Trixie development setup. Everything seems to be working fine. It is strange that the web interface related files such as CSS and JS files are loading fine but RPC calls from the webpage are not working.

To debug,

Open the browser’s developer tools and visit the network tab and reload the page. Notice if the request to …/rpc URLs are going fine and what the errors are.

Create a file called /etc/systemd/system/transmission-daemon.service.d/debug.conf with the following contents

[Service]
ExecStart=
ExecStart=/usr/bin/transmission-daemon -f --log-level=debug

Then run

systemctl daemon-reload
systemctl restart transmission-daemon.service
journalctl -fu transmission-daemon.service

Reload the web interface page.

problema · September 25, 2025, 7:05am

Thank you for your prompt reply.

The web browser only displays POST requests related to RPC without errors.
The directory /etc/systemd/system/transmission-daemon.service.d/ does not exist. I can’t create the file or the directory. The daemon is active.

Just in case: /usr/bin/transmission-daemon and /var/lib/transmission-daemon/info/settings.json belong to root:root (not to debian-transmission).
curl -v http://my.domain:9091/transmission/rpc and curl -v http://localhost:9091/transmission/rpc executed on the server show connection failures between 9001 port and arbitrary high ports.

Sunil · September 25, 2025, 3:26pm

Do you see any other errors network calls with errors? What is the response code? What is the response data and headers for the /rpc call? Did the calls to get static HTML/CSS/JS data succeed? Can you post screenshots?

What’s the error? Try:

root@freedombox:~# mkdir -p /etc/systemd/system/transmission-daemon.service.d/

As expected.

root@freedombox:~# ls -la /etc/transmission-daemon/settings.json 
rw-r--r-- 1 debian-transmission debian-transmission 3051 Sep 24 14:06 /etc/transmission-daemon/settings.json

curl http://localhost:9091/transmission/rpc should give you an “invalid session-id header” message in HTML.

problema · September 25, 2025, 7:56pm

Details: I have modified /etc/hosts on my client machine to access the server from the local network by its global domain name.

Transmission works if I access the server’s local IP address, although the web browser reports some errors:

When I access the server by its global domain name from the local network, the errors multiply and the Transmission interface becomes unusable:

There was no error: I could only create the file as root. Some messages of journalctl -fu transmission-daemon.service:

[2025-09-25T16:06:54.213-0300] WRN rpc-server.cc:579 Rejected request from 127.0.0.1 (Host not whitelisted) (rpc-server.cc:579)
sep 25 16:06:55 hostname transmission-daemon[13350]: [2025-09-25T16:06:54.213-0300] WRN rpc-server.cc:579 Too many messages like this! I won't log this message anymore this session. (rpc-server.cc:579)
sep 25 16:06:56 hostname transmission-daemon[13350]: [2025-09-25T16:06:56.030-0300] dbg ip-cache.cc:283 Couldn't obtain source IPv6 address (ip-cache.cc:283)
sep 25 16:07:01 hostname transmission-daemon[13350]: [2025-09-25T16:07:00.399-0300] dbg ip-cache.cc:273 Successfully updated source IPv4 address to 192.168.0.12 (ip-cache.cc:273)
sep 25 16:07:02 hostname transmission-daemon[13350]: [2025-09-25T16:07:01.126-0300] dbg ip-cache.cc:330 Couldn't obtain global IPv4 address (ip-cache.cc:330)

That command returns (executed from the server):

* Host localhost:9091 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:9091...
*   Trying 127.0.0.1:9091...
* connect to 127.0.0.1 port 9091 from 127.0.0.1 port 38112 failed: Conexión rehusada
* connect to ::1 port 9091 from ::1 port 58430 failed: Conexión rehusada
* Failed to connect to localhost port 9091 after 1014 ms: Could not connect to server
* closing connection #0
curl: (7) Failed to connect to localhost port 9091 after 1014 ms: Could not connect to server

Sunil · September 26, 2025, 3:56pm

This seems to be the problem. Let’s see the settings file: cat /etc/transmission-daemon/settings.json. Does rerunning setup from FreedomBox UI fix the issue?

problema · September 26, 2025, 5:48pm

Rerunning the configuration and restarting the service from Plinth does not fix the problem. When reconfigured, the ownership of settings.json changes from root:root to debian-transmission:debian-transmission.

Contents of /etc/transmission-daemon/settings.json:

{
    "alt-speed-down": 50,
    "alt-speed-enabled": false,
    "alt-speed-time-begin": 540,
    "alt-speed-time-day": 127,
    "alt-speed-time-enabled": false,
    "alt-speed-time-end": 1020,
    "alt-speed-up": 50,
    "announce-ip": "",
    "announce-ip-enabled": false,
    "anti-brute-force-enabled": false,
    "anti-brute-force-threshold": 100,
    "bind-address-ipv4": "",
    "bind-address-ipv6": "",
    "blocklist-enabled": false,
    "blocklist-url": "http://www.example.com/blocklist",
    "cache-size-mb": 4,
    "default-trackers": "",
    "dht-enabled": true,
    "download-dir": "/var/lib/freedombox/shares/group_share",
    "download-limit": 100,
    "download-limit-enabled": 0,
    "download-queue-enabled": true,
    "download-queue-size": 5,
    "encryption": 1,
    "idle-seeding-limit": 30,
    "idle-seeding-limit-enabled": false,
    "incomplete-dir": "/var/lib/transmission-daemon/Downloads",
    "incomplete-dir-enabled": false,
    "lpd-enabled": true,
    "max-peers-global": 200,
    "message-level": 5,
    "peer-congestion-algorithm": "",
    "peer-limit-global": 200,
    "peer-limit-per-torrent": 50,
    "peer-port": 51413,
    "peer-port-random-high": 65535,
    "peer-port-random-low": 49152,
    "peer-port-random-on-start": false,
    "peer-socket-tos": "le",
    "pex-enabled": true,
    "pidfile": "",
    "port-forwarding-enabled": false,
    "preallocation": 1,
    "preferred_transport": "utp",
    "proxy_url": "",
    "queue-stalled-enabled": true,
    "queue-stalled-minutes": 30,
    "ratio-limit": 2.0,
    "ratio-limit-enabled": false,
    "rename-partial-files": true,
    "reqq": 2000,
    "rpc-authentication-required": false,
    "rpc-bind-address": "0.0.0.0",
    "rpc-enabled": true,
    "rpc-host-whitelist": "",
    "rpc-host-whitelist-enabled": true,
    "rpc-password": "{MYL4R9357R1N9",
    "rpc-port": 9091,
    "rpc-socket-mode": "0750",
    "rpc-url": "/transmission/",
    "rpc-username": "transmission",
    "rpc-whitelist": "127.0.0.1",
    "rpc-whitelist-enabled": false,
    "scrape-paused-torrents-enabled": true,
    "script-torrent-added-enabled": false,
    "script-torrent-added-filename": "",
    "script-torrent-done-enabled": false,
    "script-torrent-done-filename": "",
    "script-torrent-done-seeding-enabled": false,
    "script-torrent-done-seeding-filename": "",
    "seed-queue-enabled": false,
    "seed-queue-size": 10,
    "sequential_download": false,
    "sleep-per-seconds-during-verify": 100,
    "speed-limit-down": 100,
    "speed-limit-down-enabled": false,
    "speed-limit-up": 100,
    "speed-limit-up-enabled": false,
    "start-added-torrents": true,
    "start_paused": false,
    "tcp-enabled": true,
    "torrent-added-verify-mode": "fast",
    "trash-original-torrent-files": false,
    "umask": "022",
    "upload-limit": 100,
    "upload-limit-enabled": 0,
    "upload-slots-per-torrent": 8,
    "utp-enabled": true,
    "watch-dir": "",
    "watch-dir-enabled": false,
    "watch-dir-force-generic": false
}

Just in case: the original value of “rpc-password” (the only data I modified here) starts with { but does not end with }.
In the other hand: a remote (Fragments) on a client computer was linked to Transmission on the server using credentials. It is now unlinked.

Sunil · September 26, 2025, 8:14pm

Thanks for the information so far.

Your RPC configuration looks similar to mine. So incorrect configuration is not the problem.
Looking at transmission source code, this error is raised when the incoming ‘Host:’ header to transmission is not what is expected. Error is not raised if:
- “localhost” is passed in Host header (FreedomBox does this, because it does not pass ProxyPreserveHost, default false).
- IP address values are passed in Host header.
- If the host header is preset in the whitelist (this is empty for you and typical FreedomBox setup).
Host: header typically comes from the hostname used in the URL. What does your URL look like (you can anonymize the domain name when posting this information).
What changes did you do on /etc/hosts of a client machine?
Did you make any changes to FreedomBox’s Apache configuration meant for transmission or in general any other Apache configuration?
When accessing transmission from an machine outside your network (without your /etc/hosts changes), with the same domain name, do things work?
If you change the line ProxyPass ``http://localhost:9091/transmission to ProxyPass ``http://127.0.0.1:9091/transmission in file /etc/apache2/conf-available/transmission-plinth.conf, and then systemctl reload apache2 does it solve the problem.

problema · September 27, 2025, 7:33pm

From my browser, my URLs look like this: https://domain.fbx.one/

Just in case: other services, such as Matrix, Nextcloud, MediaWiki, TiddlyWiki, and Gitweb, are working. But I am now seeing an error in Syncthing: when accessing via both URL and IP, only this message appears on its interface: Host check error. Synchronization, however, was working. I mention this only to consider the possibility that this problem extends beyond Transmission.

/etc/hosts on the client and server:

# client configuration:
127.0.0.1       localhost
127.0.1.1       client-hostname
192.168.0.12    domain.fbx.one # I just added this line.

# server configuration:
127.0.0.1       localhost
192.168.0.12    domain.fbx.one # I suppose this line is correct.

I installed Apaxy. After some trial and error because the theme wasn’t applying, I created a directive for Apache. Apaxy was installed in both /var/lib/www/html and /var/lib/freedombox/shares.

General directives in /etc/apache2/apache2.conf:

<Directory />
        Options FollowSymLinks
        AllowOverride None
        Require all denied
</Directory>

<Directory /usr/share>
        AllowOverride None
        Require all granted
</Directory>

# I may have modified the following directive:
<Directory /var/www/>
        Options FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

# I have added the following directive:
<Directory /var/lib/freedombox/shares>
        AllowOverride Options FileInfo Indexes
</Directory>

Specific directive in /etc/apache2/conf-available/sharing-freedombox.conf

Alias /share/data "/var/lib/freedombox/shares/group_share"
<Location /share/data>
Include includes/freedombox-sharing.conf
Include includes/freedombox-single-sign-on.conf
<IfModule mod_auth_pubtkt.c>
TKTAuthToken admin freedombox-share
</IfModule>
</Location>

I also changed some owners and groups in those directories (from root:root to www-data:www-data) assuming that this would improve security:

ls -la /var/www/html returns:

drwxr-xr-x 3 www-data www-data  4096 sep 24 00:07 .
drwxr-xr-x 4 root     root      4096 sep 22 20:18 ..
-rw-r--r-- 1 www-data www-data 15020 sep 23 23:37 .htaccess
-rw-r--r-- 1 www-data www-data 10703 sep 23 23:37 index.html
drwxr-xr-x 3 www-data www-data  4096 sep 24 01:08 theme

ls -la /var/lib/freedombox/shares returns:

total 40
drwxr-xr-x  6 root     root              4096 sep 23 23:55 .
drwxr-xr-x  4 root     root              4096 sep 27 03:59 ..
drwxrwsr-x+ 6 root     freedombox-share  4096 sep 25 15:17 group_share
drwxrwxr-x  2 root     users             4096 sep  5 06:06 homes
-rw-r--r--  1 www-data www-data         15020 sep 23 23:41 .htaccess
drwxrwsr-x+ 2 root     freedombox-share  4096 ago 24 22:31 open_share
drwxr-xr-x  3 www-data www-data          4096 sep 24 01:10 theme

Transmission cannot be accessed via its URL from inside or outside the local network. It can only be accessed via its public or private IP address.

I tried it and it doesn’t work.

In one of my modifications, I must have messed up the server. Is there anything more drastic than reinstalling to restore the Transmissión configuration (and perhaps Syncthing, if the problem is related)? I will try to recover backups.

If we leave this issue for now, it is understandable. After all, it is most likely not a problem related to the default configuration of FreedomBox.

problema · October 14, 2025, 5:42am

It seems that the cause of this error, which affects at least Transmission and Syncthing, is directly related to the snac2 package (which maintains, I believe, @jvalleroy).

I can reproduce it on a fresh system with the backported version of snac2 (v2.83). When this error was published, I had the stable version (v2.75). It happens just by installing it. During installation, snac configures net and web settings. The affected apps works again just by uninstalling it.

My current system: FreedomBox 25.13 on Debian 13 on x86-64.

jvalleroy · October 24, 2025, 7:57pm

@problema I think I found a solution. If possible, let me know if this works for you also:

Modify /etc/apache2/conf-available/snac2.conf to have the following content:

# apache2 configuration example for snac2
# requires modules: proxy, proxy_http

# Main web access point
<Location /social>
    ProxyPreserveHost On
    ProxyPass http://127.0.0.1:8001/social
</Location>

# WebFinger
<Location /.well-known/webfinger>
    ProxyPreserveHost On
    ProxyPass http://127.0.0.1:8001/.well-known/webfinger
</Location>

# NodeInfo (optional)
<Location /.well-known/nodeinfo>
    ProxyPreserveHost On
    ProxyPass http://127.0.0.1:8001/.well-known/nodeinfo
</Location>

# Mastodon API (entry points)
<Location /api/v1/>
    ProxyPreserveHost On
    ProxyPass http://127.0.0.1:8001/api/v1/
</Location>

<Location /api/v2/>
    ProxyPreserveHost On
    ProxyPass http://127.0.0.1:8001/api/v2/
</Location>

# Mastodon API (OAuth support)
<Location /oauth>
    ProxyPreserveHost On
    ProxyPass http://127.0.0.1:8001/oauth
</Location>

# host-meta (optional, needed for some Mastodon API clients)
<Location /.well-known/host-meta>
    ProxyPreserveHost On
    ProxyPass http://127.0.0.1:8001/.well-known/host-meta
</Location>

(I moved the “ProxyPreserveHost On” line into each Location, and removed it from the top of the file.)

Run sudo systemctl reload apache2.

I was able to confirm that this gets Syncthing working again. (I wasn’t able to reproduce the issue with Transmission.)

If this works for you, I can also make the change in the snac2 package.

problema · October 25, 2025, 9:30am

@jvalleroy It works. Both Syncthing and Transmission. Thanks. Now to explore snac. This issue should be marked as solved.

I would like to mention that I have posted a thread to try to resolve some snac settings on FreedomBox.