Clients on a server

What a client on a server actually is

A client on a server is the same client with its interface detached. Three daemons cover almost all of it: qbittorrent-nox, which serves its own web interface; transmission-daemon, which answers a JSON remote procedure call API that its web interface and command line tool both speak; and deluged, driven by a separate web interface or console client. The engine is unchanged, so the transfer proceeds as How a transfer works describes and the client remains the one the qBittorrent page covers.

Two things follow. The machine stays on, so a transfer that would have paused when a laptop slept continues, and seeding with it, which is the only setting in which a share ratio climbs without anybody watching. And more than one device can drive the same client, because the interface is a web page rather than a window on one screen.

What a server and a container do to a transfer

A server does three things to a transfer, and a container adds three more. The server removes every prompt: any decision that would raise a dialog has to be set in the configuration first. It removes sleep, which is why this is the one platform where a transfer is continuous. And it puts the client behind a login, since a web interface with a default password on a machine reachable from outside is the worst mistake available here.

The container adds paths, identity and network. Paths inside a container are not paths on the host, and a bind mount connects them, so the save path the client shows may not be the folder you see; keeping the incomplete and complete folders inside one mount makes completion a rename rather than a copy of the whole payload. Identity is the numeric user and group the process runs as, which community images expose as environment variables and which decides who owns finished files. Network is the container's own namespace: the listening port has to be published to the host, or peers cannot start a connection and the client sits firewalled in the sense The swarm gives that word, downloading but never reached.

Where a server build comes from

A server build comes from one of three publishers, and which one matters more here than on a desktop, because a container image is a whole file system rather than a program. The distribution's package repository is the first, and installing the daemon package directly is still a normal choice. The project itself is the second: some clients publish an image built by the people who write the code. Community maintainers are the third, and images from that category exist for all three clients, published by people with no connection to the projects.

The check is the same in each case. Read who publishes the image, and prefer one whose build recipe is public so the contents trace back to the project's own release. A compose file found in a forum thread is a starting point and not a provenance; the image reference inside it is the part to verify.

What goes wrong first on a server

• The mounted folder is owned by a different user than the client runs as, and every write fails while the client looks healthy.
• The listening port was never published, so the client downloads and is never reached, which shows as firewalled rather than an error.
• The configuration directory was not put on a volume, and every setting and transfer disappears when the container is recreated.
• The web interface was published to the internet with default credentials, which is a security failure and not a preference.

What a server cannot do

A server cannot ask you anything. There is no dialog and nobody at the screen, so a client that would normally prompt refuses or stalls, and the reason sits in a log. It cannot see a folder that was never mounted. It cannot open the port on the router for itself, the same limit every other platform has, and the reason a container that publishes its port to the host is only halfway there.

One pattern deserves stating plainly, because it is common and fails in a specific way. A client container can be given no network stack of its own and made to share another container's, so everything it sends leaves through the tunnel that container holds. It changes which address peers see and nothing else: the protocol, the pieces and the verification are identical, and the client is still firewalled unless the port is forwarded through that path too. If the network container restarts, the client loses its route, every transfer stalls, and the web interface goes with it, because the port was published on the container that went away.

Finally, being always on does not make a transfer fast. It makes seeding continuous and removes sleep from the list of causes, but a swarm with no seeders stays one.

The three daemons a server runs

A server runs one of three daemons, and which one matters less here than it looks, because all three speak the same protocol and reach the same peers. What differs is the name of the headless build and the interface you drive it through.

Syncthing is often run the same way and is named here only to say that it is a different job: it keeps folders on machines you own in step, with no swarm and no ratio.