Run Flood (and torrent clients) in containers

[jesec]

Feel free to share your container setup by replying to this thread.

[jesec]

Here is mine:

Specifications:

• config directory: /home/jc/dlconfig
• data directory: /mnt/data0
• owner of files: jc
  • UID: 1000
  • GID: 1001
  • get UID/GID with id {username}, for example id jc
• access Flood via port 3001
  • accessible by localhost (127.0.0.1) only
• rTorrent BitTorrent port is 6881
  • accessible by Internet (0.0.0.0)
• run rTorrent as a daemon

For security purposes, containers are launched with the privileges of specified UID/GID (-u/--user) instead of root. Docker images of this project do NOT run as root first, change permissions for you (and then degrade privileges), because such approach is very insecure due to limitations and vulnerabilities of certain Linux syscalls (and, as you may know, the potential vulnerabilities of sudo-like programs). As a result, you have to make sure that config directory and data directory exist and have right ownerships/permissions before you launch the containers.

Run Flood in a service (or shell):

docker run -it --rm \
--name flood \
--hostname flood \
-e HOME=/config \
-v /home/jc/dlconfig:/config \
-v /mnt/data0:/data \
-u 1000:1001 \
-p 127.0.0.1:3001:3001 \
jesec/flood \
--port 3001 \
--allowedpath /data

Run rTorrent in another service (or shell):

docker run -it --rm \
--name rtorrent \
--hostname rtorrent \
-e HOME=/config \
-v /home/jc/dlconfig:/config \
-v /mnt/data0:/data \
-u 1000:1001 \
-p 0.0.0.0:6881:6881 \
jesec/rtorrent \
-o network.port_range.set=6881-6881,system.daemon.set=true

Note that command arguments are used to change certain configurations of rTorrent. Alternatively, you may place your own configuration file to <config directory>/.rtorrent.rc. The equivalent rtorrent.rc here:

## Import default configurations
import = /etc/rtorrent/rtorrent.rc

## Listening port
network.port_range.set=6881-6881

## Run the rTorrent process as a daemon in the background
system.daemon.set = true

In my case, I can place it to /home/jc/dlconfig/.rtorrent.rc.

Or Docker Compose:

services:
  flood:
    hostname: flood
    image: jesec/flood
    user: 1000:1001
    restart: unless-stopped
    command: --port 3001 --allowedpath /data
    environment:
      HOME: /config
    volumes:
      - /home/jc/dlconfig:/config
      - /mnt/data0:/data
    ports:
      - 127.0.0.1:3001:3001

  rtorrent:
    hostname: rtorrent
    image: jesec/rtorrent
    user: 1000:1001
    restart: unless-stopped
    command: -o network.port_range.set=6881-6881,system.daemon.set=true
    environment:
      HOME: /config
    volumes:
      - /home/jc/dlconfig:/config
      - /mnt/data0:/data
    ports:
      - 0.0.0.0:6881:6881

Finally, access Flood and register a user with /config/.local/share/rtorrent/rtorrent.sock rTorrent socket path.

[jesec]

Alternatively, run Flood and rTorrent in a single container with Flood's managed rTorrent daemon mode and jesec/rtorrent-flood image.

Configuration:

Note that Flood does not pass through arguments to rTorrent at the moment.

As a result, to change rTorrent's configurations, there has to be a .rtorrent.rc config file.

Run Flood and rTorrent:

docker run -it --rm \
--name rtorrent-flood \
--hostname rtorrent-flood \
-e HOME=/config \
-v /home/jc/dlconfig:/config \
-v /mnt/data0:/data \
-u 1000:1001 \
-p 127.0.0.1:3001:3001 \
-p 0.0.0.0:6881:6881 \
jesec/rtorrent-flood \
--port 3001 \
--allowedpath /data

Finally, access Flood and register a user with /config/.local/share/rtorrent/rtorrent.sock rTorrent socket path.

[ghost]

I'm struggling to work out user/group permissions for this approach.

On my host, I have users rtorrent (uid 1007) and flood (uid 1008), both members of the group media (gid 1000).

My downloads are in /share/Torrents owned by rtorrent:media with permissions 770 (recursively).

In Docker Compose I have Flood set up with (irrelevant sections omitted, along with the rTorrent service as I'm using a different image for that):

  flood:
    user: 1008:1000
    command: --allowedpath /data/Torrents
    environment:
      HOME: /config
    volumes:
      - /share/Container/flood:/config
      - /share/Torrents:/data/Torrents

So, although the files are owned by a different user, they're group readable and it should be running under the gid of that group. But when adding a torrent, in the Destination dropdown I get "Flood does not have permission to read this directory", it then fails to add the torrent.

What am I doing wrong?

edit:
I've made a slight edit to the Dockerfile to do this:

RUN adduser -u 1008 -h /home/download -s /sbin/nologin --disabled-password download
RUN adduser download node

Essentially, ensuring that the download user flood runs under by default has the uid of the user from the outside, and belongs to the group with the gid of the group on the outside (which happens to be the node group that I assume comes from a node.js base image). This now works, but why is this necessary in my case and not in others?

[KaKi87]

Alternatively, run Flood and rTorrent in a single container with Flood's managed rTorrent daemon mode and jesec/rtorrent-flood image.

So I did this and the Flood UI loads, except I always get the "Failed to add 1 torrent" 🤔

[Phibonacci]

I have the same "Failed to add 1 torrent" message in Flood and I do not find any error in the logs.

Edit: I made it work by assigning data/ as a destination.

[motoko-kusanagi]

Is this https://github.com/jesec/rtorrent/blob/master/doc/rtorrent.rc the default config used by rtorrent-flood?

[euri10]

I'm using a slightly modified version of #120 (comment) with just traefik labels added 👍

version: "3.7"
services:
  flood:
    image: jesec/flood:4.3.1
    user: 1000:1000
    restart: unless-stopped
    command: --port 3000 --allowedpath /config/.local/share/rtorrent/download
    environment:
      HOME: /config
    volumes:
      - /zfspool/flood/:/config
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.flood.rule=Host(`xxxx`)"
      - "traefik.http.routers.flood.entrypoints=websecure"
      - "traefik.http.routers.flood.tls.certresolver=myhttpchallenge"
      - "traefik.http.services.flood.loadbalancer.server.port=3000"
    networks:
      - default
      - traefik-local
  rtorrent:
    image: jesec/rtorrent
    user: 1000:1000
    restart: unless-stopped
    environment:
      HOME: /config
    volumes:
      - /zfspool/flood/:/config
    ports:
      - 50000:50000
networks:
  traefik-local:
    external: true

Works great, until I have to reboot, it happens rarely but every single time the rtorrent container is locked because the lock file has not been deleted during hte shutdown (well that's what I think is happening but I could be off):
rtorrent: Could not lock session directory: "/config/.local/share/rtorrent/.session/", held by "17a53293dc8f:+1".
I have to manually delete the lock file. I'm not sure where this should happen, the docker daemon shutdowns gracefully it seems, I dont have the issue if I docker-compose down or docker-compose stop and start so if you have an idea ?

[jesec]

rTorrent will remove the lock when it shuts down gracefully. But yeah, if it refuses to start when there is no other rTorrent process, at least its stale lock detection function is broken. I will take a look when I have time.

[FlorentLM]

Hi there,

Dumb question: the /data path is supposed to be where the downloaded data goes, or is it the path for flood's database?

[jesec]

It is the download destination.

[ghost]

Dumb followup question: Why does flood need to know about the download destination? Wouldn't that just be handled by rtorrent (or whatever you're using)? I assumed flood was just acting as a mostly stateless frontend.

[rafipiccolo]

Flood communicate with rtorrent to get files metadata and download progress. If you don't provide the download path flood can only show files in ui. Not downloading them on your computer.

[Thoxy67]

Hi,

I use rtorrent-flood and every time it restart i need to manualy remove the /config/.local/share/rtorrent/.session/rtorrent.lock.

Can you make it delete itself each time the container is restarted ?

[jesec]

It seems that rTorrent failed to handle stale locks. I will take a look at the issue when I have time.

[Thoxy67]

I found a simple way to bypass the problem temporarily, just add this line at the beginning in the file/config/.rtorrent.rc :
session.use_lock.set = no

[jesec]

New revision fixes stale lock handling when PIDs are the same across different runs, which is the case with containers.

Note that you must use a consistent hostname for your container, so rTorrent can be sure that the session directory is not locked by another machine (and safely remove stale locks when necessary). It is recommended to use a consistent container name as well, so you don't accidentally start duplicate containers.

The examples have been updated.

jesec/rtorrent@957f69e

[xZero707]

@jesec Consistent hostnames do not work really well when docker-compose is used. Yes, we can define fixed hostnames and container names, but that's not really a solution.

[anstosa]

As an example of this. I put flood and rtorrent in service network mode so they have to go through my VPN container. You aren't allowed hostnames with network_mode so I'm SOL on stale lock handling

[DumoulinPierre]

Hi, I tried to use flood-rtorrent with docker-compose.

When I tried to run the flood container, I have the error "Failed to access runtime directory", and then the container stoped.
When I tried to run the rtorrent container, I have the error "rtorrent: Error in option file: /etc/rtorrent/rtorrent.rc:22: Permission denied" , and then the container stoped.

If someone have an idea..
Thanks a lot.

[jesec]

You must create those mapped folders and set appropriate permissions BEFORE you launch the container. See #120 (comment).

[viper-adnan]

I am using Caprover and I can't set the user id in command, any alternative way to add UID and GID in environment variables or else ?

[beloso]

I'd like to use flood with a docker named volume, however, I am getting the error Failed to access runtime directory

Using a regular folder works. But since I don't plan to change the files I'd prefer to keep it in a docker volume.
Is this a limitation of the image or am I doing something wrong?

volumes:
  flood_config:

services:
  flood:
    image: jesec/flood:latest
    container_name: flood
    restart: always
    depends_on:
      - qbittorrent
    user: $PUID:$PGID
    volumes:
      - flood_config:/config
      - $LOCAL_DIR/downloads:/data:ro
      - /etc/localtime:/etc/localtime:ro
    networks:
      traefik_proxy:
    command:
      - --auth=none
      - --qburl=http://$ADVERTISE_IP:$QBITTORRENT_PORT
      - --qbuser=$QB_USER
      - --qbpass=$QB_PASS
      - --rundir=/config
    logging:  
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "10"
    labels:
      - "traefik.enable=true"
      ## HTTP Routers
      - "traefik.http.routers.flood-rtr.entrypoints=https"
      - "traefik.http.routers.flood-rtr.rule=Host(`flood.$DOMAINNAME`)"
      ## Middlewares
      - "traefik.http.routers.flood-rtr.middlewares=chain-authelia@file"
      ## HTTP Services
      - "traefik.http.routers.flood-rtr.service=flood-svc"
      - "traefik.http.services.flood-svc.loadbalancer.server.port=3000"
      ## Diun
      - "diun.enable=true"

[luastoned]

Can you share your docker-compose with qbit?

[ghost]

I'm getting the same failed to access runtime directory error but with -v instead of volumes

I'm running rootless with podman but it should still work the same, I own /home/takyon/srv/rtorrent-flood and passing it through to the container via -v /home/takyon/srv/rtorrent-flood:/config

Image: /jesec/rtorrent-flood
Perms:

ls -l ~/
drwxrwx---   1 takyon takyon         44 Oct 13 10:08 srv

id
uid=1000 (takyon) gid=1000 (takyon)

specifying -u 1000:1000 doesnt change anything.

from what I can see my permissions are correct, is there anything else that can cause Failed to access runtime directory?

[ghost]

i'm dumb
just needed to chmod +777 it

[KaKi87]

just needed to chmod +777 it

Although this works, I'm wondering if there's anything safer, like adding a group ?

Thanks

[DimitarY]

an you give more information abouth how you fixed Failed to access runtime directory because i use chmod 777 but i still get Failed to access runtime directory from flood and rtorrent is says rTorrent: started, 0 torrents loaded.

This is my compose file:

services:
  flood:
    hostname: flood
    image: jesec/flood
    container_name: flood
    user: 1000:1001
    restart: unless-stopped
    command: --port 3001 --allowedpath /media/data
    environment:
      HOME: /config
    volumes:
      - /media/FloodUIrTorrent/dlconfig:/config
      - /media/data:/data
    ports:
      - 0.0.0.0:3000:3000

  rtorrent:
    hostname: rtorrent
    image: jesec/rtorrent
    container_name: rtorrent
    user: 1000:1001
    restart: unless-stopped
    command: -o network.port_range.set=6881-6881,system.daemon.set=true
    environment:
      HOME: /config
    volumes:
      - /media/FloodUIrTorrent/dlconfig:/config
      - /media/data:/data
      - /media/FloodUIrTorrent/dlconfig/.rtorrent.rc:/config/.rtorrent.rc
    ports:
      - 0.0.0.0:6881:6881

[whiteout12]

Has anyone else noticed that memory usage is increasing when running flood in docker? Mine goes well above 500mb after a couple of weeks usage. I now sat a limit (128m) to see if it crashes.

[billimek]

Has anyone else noticed that memory usage is increasing when running flood in docker? Mine goes well above 500mb after a couple of weeks usage. I now sat a limit (128m) to see if it crashes.

It's been mostly level for me running it in docker (via kubernetes). Here is a 30-day memory usage graph:

This is with flood running using rtorrent in a sidecar with over 400 active torrents, FWIW.

[whiteout12]

Ok thanks. I'm gonna monitor it now after restart. It's around 50mb now but slowly climbing. Don't understand what's being stockpiled. Is flood building up some kind of history/statistics/log?

[xZero707]

I have noticed this too when I saw OOM event due to the limit I configured for flood container. Before, it worked just fine with just about 128M hard limit.... It seems to utilize a lot during startup and then drop and slowly climb over time. This is on RPI4 mind you, so RAM is precious.

[jonesnc]

Is anyone able to open a shell in the rtorrent container? I keep getting this error:

OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown

I've also tried /bin/ash, /bin/sh, sh, bash and ash, and I always get the same error.

EDIT: nevermind, I see the jesec/rtorrent image is built on scratch, so it looks like a shell of any kind is not be available on that image.

[xZero707]

It's quite easy to download the source and modify Dockerfile to rebase on whatever else.

[NoLooseEnds]

Is it possible to just add coreutils to this docker image? Or do you need more?
I need "mv" to move my completed torrents.

[jonesnc]

It should be doable, but it's probably not as simple as just changing the FROM base image.

[xZero707]

Definitely not as simple as that. Something like COPY --from=jesec/flood:latest in your own image should do the trick, with some adjustments on the new image.

[Sharsie]

There was an issue dealing with this in the rtorrent repo, just commenting to link these discussions together, there is a super simple dockerfile example that could help someone in the future jesec/rtorrent#20 (comment)

[rafipiccolo]

I follow default docker configuration and i have errors adding torrents in web UI.

it seems that rtorrent download directory is generated here : /home/jc/dlconfig/.local/share/rtorrent/download
instead of here : /mnt/data0

then i set --allowedpath /config and now it works.
(is it okay to do so ?)

is this a bug ? or the docker-compose of the documentation needs update ?

[jt196]

Having some issues adding magnets to the UI. Running docker with qbt backend. Get a failed message when I try to add them.

[ghost]

I'm trying to create a Docker Compose setup with rTorrent being forced over an OpenVPN connection and Flood available, prioritising security and performance/low resource usage. My current approach is inspired by transmission-openvpn, using a single Alpine-based container running the jesec fork of rTorrent and OpenVPN, and a separate container for Flood.

Overall, it's pretty much working, the only real issue I'm experiencing now is that rTorrent seems to struggle to shut down gracefully in this setup. This leaves behind the lock file so it fails to start next time - I know there are some suggestions for this above, but it seems like the root issue is it failing to shut down in the first place, rather than handling the stale lock files.

The overall flow is:

1. The container (using dumb-init or Tini, I've tried both and the behaviour seems the same) runs a script which performs some setup and starts OpenVPN
2. OpenVPN is passed another script via the --up option, which is executed by OpenVPN after the tunnel is up and this script starts rTorrent in the background (along the lines of su someuser -c rtorrent &)
3. OpenVPN is also given a script to the --route-pre-down option, so when the container is asked to stop, OpenVPN receives the signal and executes that script before closing the tunnel, and the script essentially does kill $(pidof rtorrent), waits a while to see if the rtorrent process disappears, and sends it a SIGKILL if it's still running after reaching some timeout.

The issue is that although rTorrent seems to receive the initial SIGTERM correctly (it prints rTorrent: quickly shutting down...), it fails to shut down for a long time, it can easily take 20-40 seconds, sometimes longer. This is with 2 torrents. I've extended stop_grace_period for the service in my Compose file, and it now manages to shut down most of the time, but I need something reliable since this will be started and stopped automatically every day.

If I simplify the container image so that dumb-init just calls my rTorrent startup script and remove the & from the line that calls rtorrent so it doesn't exit immediately, then rTorrent shuts down within a couple of seconds when I stop the container, which is what I'd expect.

Any ideas? I know this is probably a complex scenario.

[jesec]

How many torrents do you have?

Are you using a network file system or FUSE (e.g. NTFS-3G, mergerfs)?

What kind of disk do you use for the session directory?

Is the DHT or UDP enabled?

By the way, there is an urgent shutdown mechanism that can be triggered with multiple interrupt signals.

[ghost]

This was happening while testing in Docker Desktop on a 2013 15" MBP, with literally 2 torrents and everything on the local disk which is a PCIe SSD. That'll look different where I intend to actually run it, but it seems like that's not a factor here.

DHT and UDP both disabled as well.

The weird thing is that clearly OpenVPN is receiving the correct signal and calling my rTorrent stop script as expected, and rTorrent is clearly receiving the SIGTERM from the kill command in that script, but then it just... hangs around for a long time. If I remove OpenVPN from the equation though, the issue seems to disappear.

What are the implications of triggering an urgent shutdown every time? I see the comment // Urgent shutdown: disregard unfinished requests and save session but it's not clear to me what stopping those unfinished requests might mean.

[jordanwmcdonald]

@dangerman200k I am trying to do exactly what you are doing here. Is there any chance you would be willing to share a version of your Docker compose(s) without your sensitive data? I would be so grateful! Thank you for considering :)

[ghost]

@afroeagle sure, I'll link to a gist with my compose file below, but I don't know how useful it will be without the context of the rtorrent-openvpn image I've created. I can try to share that too if there's interest, but would need to prepare it a bit to be shareable.

https://gist.github.com/dangerman200k/9707aa4c63b3fa5088af5ceb10c2a5a5

[Wonderfall]

My current container setup is a custom rTorrent image (mostly to handle RAR files) + jesec/flood. I used to maintain a single rtorrent-flood back in the days but I was unsatisfied with a few things.

So for those interested, I'm running a custom distroless container with the necessary tools to automatically unpack RAR releases (that's what I need in my workflow). Flood runs flawlessly in a separate container. Here's a generic version of my docker-compose.yml (I personally use Traefik with static configuration files to avoid giving it access to the Docker socket).

Thanks again for maintaining both Flood and your fork of rTorrent. :)

[NoLooseEnds]

Have you thought about running rar2fs (FUSE) instead? Just mount the directory instead of unpacking. Everything is in one place. Been using it for ages, no problems.

[Wonderfall]

Have you thought about running rar2fs (FUSE) instead? Just mount the directory instead of unpacking. Everything is in one place. Been using it for ages, no problems.

Looks like a compelling solution indeed! I do have concerns due to the fact it may not work with latest versions of unrar though:

The latest supported version of the unrar source tree (by Alexander Roshal) can be found here https://www.rarlab.com/rar/unrarsrc-6.0.3.tar.gz. Later versions, especially minor revision steps, should still be possible to use (should you discover a bug) depending on the level of backward source compatibility it offers.

So for instance it would leave users vulnerable to unpatched unrar vulnerabilities such as CVE-2022-30333.

But overall, very interesting. I'll probably keep using my own setup but it's definitely worth considering.

[SunyiUborka]

Hi, I tried downloading, but when upload the torrent file I get a "Faild to add x torrent".
And cant acces to directory(ShitStorage is 777 fully):

This is my settings:
sudo docker run -d --rm \ --name flood \ --hostname flood \ -e HOME=/config \ -v /var/lib/transmission/.config/transmission-daemon:/config \ -v /mnt/ShitStorage:/data \ -u 1000:1001 \ -p 3001:3001 jesec/flood \ --port 3001 \ --allowedpath /data

[Sharsie]

Inside the docker container, the path /mnt/ShitStorage is mounted as /data, so from Flood perspective, you always have to reference /data, because it does not know about the host path

[yagop]

You can mount the directory as the same path and run with the same user. Something like this:

docker run \
    -d \
    --name flood \
    --restart on-failure \
    -u $(id -u):1001 \
    -p 0.0.0.0:3000:3000 \
    -v /home/yago/.rtorrent/.session/rpc.socket:/var/run/rtorrent/rpc.socket \
    -v /home/yago/downloads:/home/yago/downloads \
    -v /etc/localtime:/etc/localtime:ro \
    -v /home/yago/.rtorrent/flood_config:/config \
    "jesec/flood:master" \
    --port 3000 \
    --rundir=/config \
    --allowedpath /home/yago/downloads \
    --rtsocket /var/run/rtorrent/rpc.socket

[sardaukar]

I'm using the docker-compose method, and it works fine except that my download folder is full of <hexadecimal>.meta files - can I move them by passing some -o option to the rTorrent command line?

[xZero707]

That's an issue with rtorrent itself. Unfortunately, rakshasa/rtorrent project seems to not be maintained anymore. Latest stable release (0.9.8) was over 4 years ago!

[anstosa]

It's not unmaintained, it's just stable.

[carmatana]

can someone share a docker compose example with flood and Qbittorrent docker containers

I am getting a "Request failed with status code 422" in Flood page.

I have in my docker compose:

flood:
    hostname: flood
    container_name: flood
    image: jesec/flood
    user: 1026:100
    restart: unless-stopped
    command: --port 3001 --allowedpath /data
    environment:
        HOME: /config
    volumes:
        - /volume1/docker/qbit-linux/config:/config
        - /volume1/Primero:/data
    ports:
        - 3001:3001
    network_mode: bridge

and

qbit-linux:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbit-linux
    environment:
        - PUID=1026
        - PGID=100
        - TZ=Etc/UTC
        - WEBUI_PORT=8090
    volumes:
        - /volume1/docker/qbit-linux/config:/config
        - /volume1/Primero:/data
        - /volume1/docker/qbit-source:/qbit-source
    #    - /volume1/docker/gluetun:/gluetun
        - /volume1/docker/qbit-scripts:/qbit-scripts
    depends_on:
        - privoxyvpn
    network_mode: service:privoxyvpn
    restart: unless-stopped

qbit-linux is runing throug privoxyvpn that is as following:

privoxyvpn:
    container_name: privoxyvpn
    cap_add:
        - NET_ADMIN
    network_mode: bridge
    ports:
        - 8118:8118 #privoxy
        - 9118:9118 #microsocks
        - 6891:6881         #qbit
        - 6891:6881/udp     #qbit
        - 8090:8090         #qbit
 #       - 9117:9117 # jackett
    volumes:
        - /volume1/docker/privoxyvpn/config:/config
        - /volume1/docker/qbit-scripts:/qbit-scripts  
        - /etc/localtime:/etc/localtime
    environment:
        - VPN_ENABLED=yes
        - VPN_USER=XXXXX
        - VPN_PASS=XXXXX
        - VPN_PROV=pia
        - VPN_CLIENT=openvpn
        - ENABLE_PRIVOXY=yes
        - LAN_NETWORK=192.168.1.0/24
        - NAME_SERVERS=84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1
        - VPN_INPUT_PORTS=8090 #,9117     # qbit y jackett
        - VPN_OUTPUT_PORTS=5678
        - DEBUG=false
        - UMASK=000
        - PUID=1026
        - PGID=100            
    #    - ENABLE_SOCKS=yes
    #    - SOCKS_USER=admin
    #    - SOCKS_PASS=socks
    image: binhex/arch-privoxyvpn
    restart: unless-stopped

qbit-linux is running ok, I can access it through port 8090

Thanks in advance

[sardaukar]

I'm actually using just qBitTorrent with VueTorrent now, it's pretty good and single-container

[carmatana]

but with flood you can choose what interface to use, in my pc I prefer the original qbittorent webui and for mobile I would like to have flood or other responsive webui.

[PrzemekSkw]

Hello, it's possible to use flood with deluge-vpn? Anyone can help with that?
Regards.

[pindaroli]

Feel free to share your container setup by replying to this thread.

Could yoy provide your .rctorrent.rc?
Thanks

[Zburatorul]

The instruction to use .rtorrent.rc conflicts with the container definition which has command: -o network.port_range.set=6881-6881,system.daemon.set=true which overrides the config. It took me a while to figure out why it was ignoring the port range I had in the config file. imo, the command line should be dropped and all settings should be in the .rc file.

[mikabytes]

I've Been trying to get this to work in Kubernetes for the past few hours but it keeps crashing on me. As far as I can see, I'm using the correct configuration based on this thread. Does anyone have an idea?

FATAL internal error. Please open an issue.
Unhandled rejection: Unknown system error -116: Unknown system error -116, write

This is my configuration:

{
   "apiVersion": "apps/v1",
   "kind": "Deployment",
   "metadata": {
      "name": "sofa--flood",
      "namespace": "default"
   },
   "spec": {
      "replicas": 1,
      "selector": {
         "matchLabels": {
            "app": "sofa--flood"
         }
      },
      "template": {
         "metadata": {
            "labels": {
               "app": "sofa--flood"
            }
         },
         "spec": {
            "containers": [
               {
                  "env": [
                     {
                        "name": "FLOOD_OPTION_allowedpath",
                        "value": "/fun"
                     },
                     {
                        "name": "FLOOD_OPTION_auth",
                        "value": "none"
                     },
                     {
                        "name": "FLOOD_OPTION_clientpoll",
                        "value": "1000"
                     },
                     {
                        "name": "FLOOD_OPTION_rundir",
                        "value": "/config"
                     },
                     {
                        "name": "FLOOD_OPTION_trpass",
                        "value": "supersecret"
                     },
                     {
                        "name": "FLOOD_OPTION_trurl",
                        "value": "http://sofa:80/transmission/rpc"
                     },
                     {
                        "name": "FLOOD_OPTION_truser",
                        "value": ""
                     },
                     {
                        "name": "HOME",
                        "value": "/config"
                     },
                     {
                        "name": "TZ",
                        "value": "Europe/Sweden"
                     }
                  ],
                  "image": "jesec/flood:4.7.0",
                  "imagePullPolicy": "IfNotPresent",
                  "name": "sofa--flood",
                  "ports": [
                     {
                        "containerPort": 3000,
                        "name": "http",
                        "protocol": "TCP"
                     }
                  ],
                  "volumeMounts": [
                     {
                        "mountPath": "/fun",
                        "name": "merged-fun"
                     },
                     {
                        "mountPath": "/config",
                        "name": "merged-pvc-sofa-flood"
                     }
                  ]
               }
            ],
            "restartPolicy": "Always",
            "securityContext": {
               "runAsGroup": 1000,
               "runAsUser": 1000
            },
            "volumes": [
               {
                  "name": "merged-fun",
                  "nfs": {
                     "path": "/merged/fun",
                     "server": "supersecret"
                  }
               },
               {
                  "name": "merged-pvc-sofa-flood",
                  "nfs": {
                     "path": "/merged/pvc/sofa/flood",
                     "server": "supersecret"
                  }
               }
            ]
         }
      }
   }
}

[XxAcielxX]

@jesec
The problem with stale rtorrent.lock appears to be causing the issue for me again. After I stop the container, and start it back later, it does this.

2024-07-19T09:22:43.655998387Z GET /api/settings 200 7.396 ms - 1808
2024-07-19T09:22:43.660248722Z GET /api/client/settings 200 19.359 ms - 590
2024-07-19T09:22:43.667982644Z GET /api/client/settings 200 6.534 ms - 590
2024-07-19T09:22:43.674537408Z GET /api/settings 200 3.992 ms - 1808
2024-07-19T09:22:46.227309396Z GET /api/activity-stream 200 34.382 ms - -
2024-07-20T05:41:49.377516537Z rtorrent: Could not lock session directory: "/config/.local/share/rtorrent/.session/", held by "rtorrent-flood:+14".
2024-07-20T05:41:49.567999858Z Killing rTorrent daemon...
2024-07-20T05:45:52.257827899Z rtorrent: Could not lock session directory: "/config/.local/share/rtorrent/.session/", held by "rtorrent-flood:+14".
2024-07-20T05:45:52.432479265Z Killing rTorrent daemon...
2024-07-20T06:19:36.832838645Z rTorrent: loading 3 entries from session directory
2024-07-20T06:19:37.088836791Z Flood server 0.0.0-master.9d2aaf4 starting on http://0.0.0.0:3001
2024-07-20T06:19:37.088856100Z 
2024-07-20T06:19:37.542730160Z rTorrent: started, 3 torrents loaded

[NoLooseEnds]

Just remove it, and it should work. Also you could make a command in your rtorrent.rc that removes it if it's present when starting up.

See: rakshasa/rtorrent#949