Cómo instalar Transmission Daemon en Debian 13 y MX Linux 25

Transmission es una de las opciones más ligeras y eficientes para gestionar torrents en un servidor casero, una Raspberry Pi o un centro de descargas 24/7. Su versión daemon está pensada para ejecutarse en segundo plano y controlarla desde su interfaz web o cualquier cliente remoto.

Esta guía está actualizada para Debian 13 (Trixie) y MX Linux 25, y tiene en cuenta los cambios importantes que han llegado con la versión 4.x de Transmission. Si seguiste la guía Inicia transmission-daemon con systemd en Debian 12, es muy probable que te hayas encontrado con que el servicio no arranca correctamente. Aquí te explico paso a paso cómo hacerlo bien, con las mejores prácticas actuales y dos rutas de instalación según tu sistema operativo.

📦 1. Instalación del paquete (elige tu ruta)

Lo primero es actualizar la lista de paquetes.

sudo apt update

A partir de aquí, el procedimiento cambia según el sistema que uses.

🐧 Ruta A: Debian 13 puro o Raspberry Pi OS (Trixie) → usa backports

Este es el punto más importante y el que más confusiones genera. Debian 13 incluye en sus repositorios principales una versión beta de Transmission, concretamente la 4.1.0~beta2. Si instalas el paquete sin más, apt te dará esa beta, que arrastra errores conocidos y puede provocar cuelgues inesperados o problemas al guardar la configuración.

La solución oficial es instalar la versión estable desde los backports de Debian 13. Allí encontrarás la versión 4.1.3, que corrige los problemas de la beta y añade parches importantes. Además, esta versión evita un problema conocido de las versiones 4.1.0 y 4.1.1 que provocaba que algunos trackers bloquearan al cliente por un flujo excesivo de peticiones.

“Nota para Raspberry Pi OS: aunque los backports de Debian funcionan en la arquitectura arm64, esta combinación no está soportada oficialmente por la Fundación Raspberry Pi. Úsala bajo tu propio riesgo y, si puedes, haz una copia de seguridad antes.”

Paso 1: Añade el repositorio de backports (si no lo tienes ya).

echo "deb http://ftp.de.debian.org/debian trixie-backports main" | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update

Paso 2: Instala el paquete indicando explícitamente que quieres la versión de backports.

sudo apt install -t trixie-backports transmission-daemon

Esta es la opción más recomendada si usas Debian 13 o Raspberry Pi OS.

🐧 Ruta B: MX Linux 25 → instala directamente

Si usas MX Linux 25 (basado en Debian 13), la situación es mucho más sencilla. MX Linux empaqueta su propia versión de Transmission en su repositorio, y la versión actual (4.1.0+dfsg-1~mx25+1) ya es estable, no es una beta. No necesitas añadir los backports de Debian, ya que podrías crear conflictos de paquetes con el sistema de MX.

Simplemente instala el paquete con normalidad:

sudo apt install transmission-daemon

Importante: No mezcles repositorios. Si usas MX Linux, mantente dentro de sus repositorios oficiales. Si usas Debian puro, usa los backports de Debian. Mezclar ambos puede romper dependencias.

🔧 2. El paso crítico: arreglar el servicio systemd

Aquí está el cambio más importante respecto a guías anteriores, y afecta tanto a Debian 13 como a MX Linux 25. La unidad de systemd que viene por defecto usa Type=notify, pero con Transmission 4.x esto ya no funciona bien. El demonio se inicia correctamente, pero no notifica a systemd cuando está listo, por lo que systemd cree que ha fallado y acaba matándolo tras un tiempo de espera (timeout).

La solución es crear un archivo de override (anulación) para cambiar el tipo de servicio a simple, sin tocar el archivo original del sistema. Es un procedimiento limpio y persistente que sobrevive a las actualizaciones del paquete.

Ejecuta:

sudo systemctl edit transmission-daemon.service

Se abrirá un editor. Añade las siguientes líneas:

[Service]
Type=simple

Guarda y cierra. Luego recarga systemd para que aplique el cambio:

sudo systemctl daemon-reload

Con esto, el servicio ya debería arrancar y mantenerse activo sin problemas.

🛡️ 3. Endurecimiento (hardening) del servicio

Transmission 4.x ya incluye algunas opciones de seguridad por defecto, pero podemos añadir más capas de protección. Un demonio que acepta conexiones de red siempre es un objetivo interesante, así que vale la pena blindarlo un poco.

Vuelve a abrir el editor de override:

sudo systemctl edit transmission-daemon.service

Y añade estas directivas de seguridad dentro de la sección [Service], junto al Type=simple que ya pusiste:

# Hardening
NoNewPrivileges=true
PrivateTmp=true
PrivateDevices=true
ProtectSystem=full
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictRealtime=true

¿Qué hace cada directiva?

Cada línea del bloque anterior es una capa de aislamiento que systemd aplica al proceso de Transmission. Ninguna es imprescindible por sí sola, pero juntas reducen drásticamente lo que un atacante podría hacer si encontrara una vulnerabilidad en el demonio.

• NoNewPrivileges=true: Impide que el proceso (o cualquiera de sus hijos) pueda obtener privilegios adicionales a través de execve(), como los bits setuid/setgid o las capabilities del sistema de archivos. Es una de las protecciones más básicas y efectivas.
• PrivateTmp=true: Crea directorios /tmp y /var/tmp privados para el servicio, aislados del resto del sistema. Así, otros procesos no pueden leer ni manipular los archivos temporales que genere Transmission.
• PrivateDevices=true: Proporciona un sistema de archivos /dev mínimo y privado, con solo los dispositivos pseudo-API esenciales (/dev/null, /dev/zero, etc.). El servicio pierde acceso a discos, cámaras, GPUs y cualquier otro dispositivo físico real.
• ProtectSystem=full: Monta /usr, /boot y /efi como solo lectura, y además hace lo mismo con /etc. Esto significa que el proceso no puede modificar los binarios del sistema ni la configuración global, limitando el daño si se ve comprometido.
• ProtectHome=true: Hace que los directorios /home y /run/user sean completamente inaccesibles para el servicio. Es la directiva que ya te advertí que puede chocar con tus rutas de descarga si están dentro de una carpeta personal.
• ProtectKernelTunables=true: Hace que las variables del kernel expuestas en /proc/sys/, /sys/ y rutas similares sean de solo lectura para el proceso. Evita que Transmission pueda alterar parámetros críticos del sistema en tiempo de ejecución.
• ProtectKernelModules=true: Deniega explícitamente la carga y descarga de módulos del kernel. Un cliente de torrents no necesita cargar controladores, así que esto cierra una vía de escalada de privilegios.
• ProtectControlGroups=true: Hace que la jerarquía de cgroups (/sys/fs/cgroup) sea de solo lectura para el servicio. Impide que el proceso manipule los grupos de control del sistema, que son un mecanismo habitual para intentar escapar de un contenedor o de un sandbox.
• RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6: Limita los tipos de sockets que el proceso puede crear. Solo se permiten tres familias: AF_UNIX (comunicación local), AF_INET (IPv4) y AF_INET6 (IPv6). Se bloquean así familias más exóticas como AF_PACKET (acceso a paquetes en crudo), que a menudo se usan en exploits.
• RestrictRealtime=true: Rechaza cualquier intento de activar políticas de planificación en tiempo real (SCHED_FIFO, SCHED_RR, etc.). Un cliente de torrents no necesita prioridad de tiempo real, y permitirla podría usarse para agotar la CPU y afectar al resto del sistema.

Notas:
ProtectSystem=full es un buen equilibrio para Transmission: protege las rutas del sistema pero deja escribibles /var y /srv, donde podrías tener tus descargas. Si prefieres un aislamiento aún mayor y tus descargas están en un disco externo montado aparte, podrías probar ProtectSystem=strict, que monta todo el árbol de archivos como solo lectura salvo /dev, /proc y /sys. Requiere ajustar permisos con ReadWritePaths para las carpetas de descarga.

ProtectHome=true: esta opción impide el acceso a los directorios dentro de /home. Si tus descargas van a una carpeta en tu home, tendrás que ajustar esta opción o usar BindPaths para dar acceso solo a la carpeta concreta. Si tus descargas van a un disco externo montado en /mnt, /srv o similar, no habrá problema.

NoNewPrivileges=true: Impedirá que Transmission ejecute scripts (por ejemplo, para enviar notificaciones) En ese caso, tendrás que ponerlo a false en el override o buscar una alternativa externa.

Guarda, recarga:

sudo systemctl daemon-reload

y luego reinicia:

sudo systemctl restart transmission-daemon

⚙️ 4. Configuración básica (settings.json)

El archivo de configuración principal está en /etc/transmission-daemon/settings.json. Nunca lo edites con el servicio en marcha, porque Transmission sobrescribirá tus cambios al apagarse. Sigue siempre este orden:

Para el servicio con:

sudo systemctl stop transmission-daemon

Edita el servicio con:

sudo nano /etc/transmission-daemon/settings.json

Aquí tienes las opciones más importantes que deberías revisar.

📂 Directorios de descarga

Busca las líneas download-dir y, si quieres, incomplete-dir:

"download-dir": "/ruta/a/tus/descargas",
"incomplete-dir": "/ruta/a/tus/descargas/incompletos",
"incomplete-dir-enabled": true,

Si prefieres que los archivos se descarguen directamente a su destino final, pon "incomplete-dir-enabled": false.

🌐 Interfaz web (RPC)

Para poder controlar Transmission desde el navegador o un cliente remoto, necesitas configurar el RPC. Este es un punto crítico de seguridad: no expongas el RPC sin autenticación.

"rpc-enabled": true,
"rpc-bind-address": "0.0.0.0",
"rpc-port": 9091,
"rpc-whitelist-enabled": true,
"rpc-whitelist": "127.0.0.1,192.168.1.*",
"rpc-authentication-required": true,
"rpc-username": "tu_usuario",
"rpc-password": "tu_contraseña",

¿Qué hace cada directiva de la interfaz web (RPC)?

Estas opciones controlan cómo se accede a Transmission de forma remota, ya sea desde el navegador o mediante herramientas como transmission-remote. Configurarlas bien es clave para no exponer el servicio sin protección.

• "rpc-enabled": true
  Activa o desactiva por completo el servidor RPC (la interfaz de control remoto). Si está en false, nadie podrá conectarse a Transmission desde fuera, aunque el resto de opciones estén configuradas. Es el interruptor maestro.
• "rpc-bind-address": "0.0.0.0"
  Define en qué dirección IP de tu máquina “escucha” el servidor RPC. Con "0.0.0.0" escucha en todas las interfaces de red disponibles. Si solo quieres acceso local, usa "127.0.0.1". Si usas WireGuard, aquí deberías poner la IP de tu interfaz VPN (por ejemplo, "10.0.0.1").
• "rpc-port": 9091
  Es el puerto de red que Transmission usará para el RPC. El valor 9091 es el estándar, pero puedes cambiarlo si tienes conflictos con otro servicio. Si lo cambias, recuerda usar el nuevo puerto al acceder desde el navegador.
• "rpc-whitelist-enabled": true
  Activa o desactiva la “lista blanca” de direcciones IP. Si está en true, solo las IPs que aparezcan en rpc-whitelist podrán conectarse. Es una capa de seguridad importante, incluso si tienes autenticación activada.
• "rpc-whitelist": "127.0.0.1,192.168.1.*"
  Es la lista de IPs o rangos de IP permitidos. Admite comodines con *. En el ejemplo, se permite el acceso desde la propia máquina (127.0.0.1) y desde cualquier dispositivo de la red local 192.168.1.x. Nunca uses "*" si el servicio es accesible desde internet.
• "rpc-authentication-required": true
  Obliga a que los clientes se identifiquen con un usuario y contraseña para poder usar el RPC. Es imprescindible si vas a acceder desde fuera de tu red local o a través de una VPN, porque la whitelist por sí sola no protege contra alguien que ya esté dentro de tu red (o que falsifique una IP).
• "rpc-username": "tu_usuario"
  El nombre de usuario que se pedirá en el formulario de acceso. Elige uno que no sea obvio (evita admin o transmission).
• "rpc-password": "tu_contraseña"
  La contraseña asociada a ese usuario. Importante: puedes escribirla en texto plano en el archivo, pero Transmission la cifrará automáticamente la primera vez que arranque el servicio. A partir de ese momento, en settings.json verás una cadena con un { al principio, no tu contraseña original. Por eso es crucial que hagas los cambios con el servicio detenido: si lo editas mientras corre, al apagarse sobrescribirá el archivo y perderás los cambios.

Un detalle sobre la seguridad: la combinación de rpc-whitelist + rpc-authentication-required es la que te da una protección real. La whitelist filtra por origen, y la autenticación añade una barrera incluso si alguien logra saltarse ese filtro (por ejemplo, desde dentro de tu propia red). Para acceso remoto, la opción más segura sigue siendo WireGuard, como explicamos en la sección 6.b.

Si vas a acceder a través de WireGuard (ver sección 6), es más seguro cambiar rpc-bind-address por la IP de tu interfaz VPN (por ejemplo, "10.0.0.1") en lugar de "0.0.0.0". Lo explico en detalle en el apartado 6.b.

🔄 Otras opciones útiles

"ratio-limit": 2.0,
"ratio-limit-enabled": true,
"idle-seeding-limit": 30,
"idle-seeding-limit-enabled": true,
"speed-limit-up": 1000,
"speed-limit-up-enabled": true,

¿Qué hace cada directiva de límites?

Estas opciones controlan el comportamiento de Transmission una vez que un torrent ha terminado de descargarse, y también cuánto ancho de banda puede usar. Son fundamentales para mantener tu equipo bajo control y no saturar la conexión.

• "ratio-limit": 2.0
  Define la proporción de subida (ratio) a la que se dejará de sembrar un torrent. El ratio se calcula dividiendo los datos subidos entre los datos descargados. Un valor de 2.0 significa que subirás el doble de lo que has descargado. Un ratio de 1.0 es el mínimo para ser un “buen ciudadano” en la red BitTorrent; 2.0 se considera un buen equilibrio. Por defecto, si no se activa, los torrents se siembran indefinidamente.
• "ratio-limit-enabled": true
  Activa o desactiva el límite de ratio. Si está en true, el torrent se pausará automáticamente cuando alcance el valor de ratio-limit. Si está en false, el límite se ignora y el torrent seguirá sembrando sin fin (a menos que actúen otros límites como el de inactividad).
• "idle-seeding-limit": 30
  Establece el tiempo máximo de inactividad (en minutos) que un torrent puede estar sembrando sin subir datos antes de ser pausado. 30 minutos es un valor razonable para liberar recursos de torrents que ya no interesan a nadie.
• "idle-seeding-limit-enabled": true
  Activa o desactiva el límite por inactividad. Si está en true, se aplica el tiempo definido en idle-seeding-limit. Si está en false, el torrent puede estar sembrando sin actividad indefinidamente, sin pausarse por este motivo.
• "speed-limit-up": 1000
  Define la velocidad máxima de subida en kilobytes por segundo (KB/s). El valor 1000 equivale aproximadamente a 1 MB/s. Este límite solo se aplica si speed-limit-up-enabled está activado. Es útil para evitar que Transmission acapare todo el ancho de banda de subida de tu conexión y afecte a otros servicios.
• "speed-limit-up-enabled": true
  Activa o desactiva el límite de velocidad de subida. Si está en true, la velocidad de subida se limitará al valor de speed-limit-up. Si está en false, la subida será ilimitada (hasta el máximo que permita tu conexión y los peers).

Un detalle importante: ratio-limit e idle-seeding-limit pueden entrar en conflicto. Si un torrent alcanza el ratio límite, se pausa por ratio; si deja de subir datos, se pausa por inactividad. El primero en alcanzarse es el que se aplica. Configurar ambos te da un control más fino sobre cuándo deja de sembrar Transmission.

Cuando termines de editar, guarda el archivo y arranca el servicio de nuevo:

sudo systemctl start transmission-daemon

🚀 5. Gestión del servicio

Ahora que todo está configurado, estos son los comandos que usarás habitualmente:

# Ver el estado del servicio
sudo systemctl status transmission-daemon

# Detenerlo
sudo systemctl stop transmission-daemon

# Reiniciarlo (por ejemplo, tras editar settings.json)
sudo systemctl restart transmission-daemon

Si quieres que se inicie automáticamente al arrancar el sistema:

sudo systemctl enable transmission-daemon

🔓 6. Acceso remoto a la interfaz web: router vs. WireGuard

Por defecto, la interfaz web de Transmission (el RPC) solo escucha en 127.0.0.1, lo que significa que solo es accesible desde la propia Raspberry Pi. Para poder controlarlo desde otro dispositivo, tienes dos caminos:

• 6.a. Exponer el puerto a internet, Abrir el puerto 9091 en el router.
• 6.b. Acceder a través de una VPN. Acceder a través de tu VPN WireGuard.
  La diferencia en seguridad entre ambos es enorme.

⚠️ 6.a. Abrir el puerto 9091 en el router (no recomendado)

Esta es la vía rápida y la que usaban muchas guías antiguas. Consiste en hacer que Transmission escuche en todas las interfaces y redirigir el puerto 9091 en tu router para que sea accesible desde fuera de tu red local.

Pasos:

Detén el servicio con:

sudo systemctl stop transmission-daemon

Modifica el archivo settings.json:

sudo nano /etc/transmission-daemon/settings.json

cambia rpc-bind-address para que escuche en todas las interfaces:

"rpc-bind-address": "0.0.0.0",

La rpc-whitelist es tu única barrera si expones el puerto. Si tu IP pública es dinámica, tendrías que añadirla manualmente cada vez, o desactivar la whitelist por completo ("rpc-whitelist-enabled": false), lo cual es muy peligroso. Una alternativa algo más segura es mantener la whitelist activada con los rangos de tu red local y añadir tu IP pública actual, pero no es una solución estable.

Guarda, arranca el servicio

sudo systemctl start transmission-daemon

Ahora redirige el puerto 9091/TCP en tu router hacia la IP local de la Raspberry Pi. La forma exacta depende de cada modelo de router.

Accede desde fuera con

http://tu-dominio.duckdns.org:9091 (o tu IP pública).

¿Por qué no te lo recomiendo?

• Transmission habla HTTP en texto plano por defecto. Tus credenciales de acceso viajan sin cifrar. Cualquiera que intercepte el tráfico (tu operadora, un WiFi público, un atacante en tu misma red) puede leer tu usuario y contraseña.
• Los bots escanean internet constantemente. En cuanto el puerto 9091 esté abierto, empezarás a recibir intentos de login automatizados. Transmission tiene autenticación, pero no está diseñado para estar expuesto directamente a internet.
• Superficie de ataque directa. Cualquier vulnerabilidad que se descubra en el RPC de Transmission quedará expuesta sin ninguna capa intermedia que filtre.

✅ 6.b. Acceder a través de tu VPN WireGuard (recomendado)

Esta es la opción que yo mismo uso y la que te recomiendo sin dudarlo. Si ya tienes montada una VPN WireGuard en tu Raspberry Pi —como expliqué en la entrada WireGuard en Raspberry Pi: VPN casera, segura y gratuita—, ya tienes hecha la mitad del trabajo. La idea es muy sencilla: en lugar de exponer Transmission a internet, te conectas primero a tu VPN y luego accedes a la interfaz web como si estuvieras dentro de tu red local. Todo el tráfico viaja cifrado por el túnel de WireGuard.

Ventajas frente a abrir el puerto:

• Cifrado de extremo a extremo. Todo el tráfico entre tu dispositivo y la Raspberry Pi viaja cifrado por WireGuard.
• No expones ningún servicio a internet. Transmission sigue escuchando únicamente en la interfaz de la VPN. Los bots y escáneres no tienen nada a lo que atacar.
• Una sola puerta de entrada. Ya tienes WireGuard como punto de acceso seguro a tu red doméstica. Aprovecharlo para Transmission es lo lógico.
• Funciona desde cualquier dispositivo: móvil, portátil, tablet… Solo necesitas el cliente WireGuard y tu configuración.

Pasos:

Conéctate a tu VPN desde el dispositivo que vayas a usar.

Detén el servicio con:

sudo systemctl stop transmission-daemon

En settings.json

sudo nano /etc/transmission-daemon/settings.json

Haz que Transmission escuche en la IP de la interfaz de la VPN. Si tu servidor WireGuard usa la IP 10.0.0.1, la configuración sería:

"rpc-bind-address": "10.0.0.1",

Nota: Podrías usar "0.0.0.0" para escuchar en todas las interfaces, pero limitarlo a la IP de la VPN es más seguro, porque la única vía de acceso será el túnel. El inconveniente es que no podrás entrar localmente desde dispositivos que estén fuera de la VPN.

Ajusta la rpc-whitelist para permitir las IPs de tus clientes VPN. Si tu subred de WireGuard es 10.0.0.0/24, puedes usar un comodín:

"rpc-whitelist": "10.0.0.*",

Nota: También puedes incluir 127.0.0.1 por si en algún momento necesitas acceso local: "rpc-whitelist": "127.0.0.1,10.0.0.*",

Guarda el archivo, arranca el servicio:

sudo systemctl start transmission-daemon

Accede desde el navegador, ya conectado a la VPN, con la dirección privada de tu Raspberry Pi:

http://10.0.0.1:9091

Introduce tus credenciales y tendrás acceso completo a la interfaz web de Transmission. Al ir todo por el túnel de WireGuard, la velocidad dependerá de tu conexión, pero para gestionar descargas y añadir torrents es más que suficiente.

🐛 7. Solución de problemas comunes

El servicio no arranca y da un timeout

Ya lo hemos solucionado en el paso 2, pero si te encuentras con esto en otro equipo, la causa casi seguro es el Type=notify. Verifica que tu archivo de override esté correctamente aplicado:

systemctl cat transmission-daemon.service

Deberías ver tu override.conf con Type=simple al final de la salida.

Error de permisos en settings.json

A veces, el usuario debian-transmission no tiene permisos suficientes sobre el archivo. Verifícalo:

ls -la /etc/transmission-daemon/settings.json

El propietario debería ser debian-transmission:debian-transmission. Si no lo es, corrígelo:

sudo chown debian-transmission:debian-transmission /etc/transmission-daemon/settings.json

No puedo acceder a la interfaz web

• Verifica que rpc-enabled esté en true.
• Comprueba que rpc-bind-address sea "0.0.0.0" si accedes desde otra máquina.
• Revisa que tu IP esté en la whitelist. Si instalaste desde backports, es posible que la whitelist esté activada por defecto y tu IP no esté incluida.
• Asegúrate de que el puerto 9091 esté abierto en el firewall.
• Si ves un error 403 Forbidden, casi siempre es la whitelist o la autenticación.

🎯 Conclusión

Transmission sigue siendo una opción excelente para gestionar torrents en un servidor Debian o MX Linux. Los puntos clave para una instalación sin problemas en 2026 son:

1. Elige bien tu ruta de instalación: si usas Debian 13 puro, instala desde trixie-backports para evitar la beta; si usas MX Linux 25, el paquete por defecto ya es estable.
2. Crea un override de systemd para cambiar Type=notify a Type=simple. Esto es imprescindible en ambos sistemas.
3. Añade opciones de hardening para proteger el servicio.
4. Configura bien el RPC si vas a acceder remotamente, con autenticación y whitelist.

Con estos pasos, tendrás un demonio de Transmission funcionando de forma estable y segura. Si te surge alguna duda, ¡déjamela en los comentarios!