The Docker package has been updated to 8.4.0

[SpudmanWP]

If anyone has been trying to get Triber working in a headless, containerized Docker environment and has been looking for a more recent package, they just published 8.4.0 as a package.

I am new to Docker and am trying to get it working in either Dockage, Protainer, or TrueNAS's native Docker schema.

https://github.com/Tribler/tribler/pkgs/container/tribler

Here is the sample command given:

docker pull ghcr.io/tribler/tribler:sha256-e2fbcda7ab89e7d7db68dbf8bd695dc91b94d14da5015ed5b88d4c511029e27f

[SpudmanWP]

Please update the Package to 8.4.1

Thanks in advance.

[qstokkink]

It seems our automatic build failed: https://github.com/Tribler/tribler/actions/runs/23143984470 🤔 I'll have a look.

[qstokkink]

Ok, after a lengthy investigation, I fixed the build by doing nothing.

I verified this:

1. When we create a new release, our GitHub Action springs into life and automatically creates a Docker build.
2. The Docker file downloads the .deb from the correct release URL and installs it.

So far so good.

However:

• The release doesn't have a .deb build attached to it yet when it is made. So, the Docker file uses curl to download and install a 404 HTML page, not an actual .deb package. Oops.

We'll have to remake that GitHub Action.

[SpudmanWP]

I was working on a YAML file today and on a hunch check the Docker Hub page for Tribler.
https://hub.docker.com/r/tribler/tribler
It was updated 13 days ago when the 8.4.0 Package was updated on GitHub.
I am assuming that it did not get updated to 8.4.1 for the same reason that the GitHub Package did not get created.

I messed up my notes, give me sec

[SpudmanWP]

I tried with a direct link, but that fails.

Here is the error:
[2026/03/16 19:27:00] (ERROR) app_lifecycle.compose_action():58 - Failed 'up' action for 'tribler20260315v5' app: tribler Pulling \nunsupported media type application/vnd.oci.empty.v1+json\n

I am getting this same error in both Portainer and natively in TrueNAS

Here is the line
image: ghcr.io/tribler/tribler:sha256-e2fbcda7ab89e7d7db68dbf8bd695dc91b94d14da5015ed5b88d4c511029e27f

[SpudmanWP]

ok, screenshot here
It is downloading 8.1.3 when using "lastest" from either ghcr.io or docker hub.
This will likely explain the problems I have been having running it.

[SpudmanWP]

Last observation for the night.
I am assuming that Tribler will be installed in the same location in the Container as it is in a standalone Linux environment.
I checked home/ubuntu and found a hidden ".Tribler" folder as I do in Linux.
However, it's empty.

Do you want me to continue this thread here or create a separate "How to get Tribler working on a NAS in Docker" thread?

[SpudmanWP]

For archival purposes, here is my YAML.

There are a lot of stuff commented out as I've tried every way I can think of to get it to come up.

#version: "3.8"      #TruNAS ignores this
services:
  tribler:
    image: ghcr.io/tribler/tribler:latest
    #image: tribler/tribler:latest
    #image: tribler/tribler:v8.4.0
    #image: ghcr.io/tribler/tribler:sha256-e2fbcda7ab89e7d7db68dbf8bd695dc91b94d14da5015ed5b88d4c511029e27f    # or tribler/tribler:latest from Docker Hub
    container_name: tribler20260315   # optional, but helps identify
    restart: unless-stopped
    #network_mode: host      #it's a frequent failure point in SCALE custom apps
    ports:
      # Remove ports: block entirely (API binds directly to host's 64700)
      - mode: ingress
        protocol: tcp
        published: 64700
        target: 64700
      #- "64700:64700"                    # Web UI / API
      #- "6881-6900:6881-6900"          # Common libtorrent / DHT / torrent traffic range (adjust if needed)
      #- "6881-6900:6881-6900/udp"      # UDP too for better connectivity
    environment:
      - CORE_API_PORT=64700           #Change this as need for your Port
      - CORE_API_KEY=MyTribler9900   # CHANGE THIS!!
      #- CORE_API_BIND_ADDRESS=0.0.0.0
      - CORE_API_BIND_ADDRESS=10.0.0.250
      - LANG=C.UTF-8
      #Tried these two but it did not stop IPV6 traffic
      - TRIBLER_ENABLE_IPV6=0   # undocumented, but reported to help in some issues
      - TRIBLER_DISABLE_IPV6=1  # or similar; undocumented but helps some
      - TRIBLER_LOG_LEVEL=DEBUG #(might give more startup info in stdout).
    volumes:
      - /mnt/NAS-Prime/SharedMedia/Working/Tribler/Config:/home/ubuntu/.Tribler   # CHANGE to your actual dataset path
      - /mnt/NAS-Prime/SharedMedia/Working/Tribler/Downloads:/home/ubuntu/Downloads     # CHANGE to your download dataset
      #- /MyTribler:/home/ubuntu/.Tribler
      #- /MyDownloads/TriblerDownloads:/home/ubuntu/Downloads
    command: -s   #headless mode might not be needed or could conflictcd..
    
    #URL to Connect = http://10.0.0.250:64700/ui/#/downloads/all?key=MyTribler9900
    cap_add:        #Added for Debug Purposes
      - NET_RAW     #
      - NET_ADMIN   # Often needed together for socket tweaks/DHT
      #sha256-e2fbcda7ab89e7d7db68dbf8bd695dc91b94d14da5015ed5b88d4c511029e27f  (From Package)
      #tribler_8.1.3_x64.deb   

[SpudmanWP]

I see that you just posted the Package to 8.4.1.
No changes to the issues above.

I can confirm that the newest deb is in the package.

Looks like Tribler was installed in the Root

[SpudmanWP]

DOCKER WORKS IN TRUENAS!!!!!!

It's 3am in California and I'm too tired to put the process here now.
Long story short:
1, I had to use the "network_mode: host" method
2. I then accessed the configuration.json file from the share (volume)

[SpudmanWP]

ok, not sure if this needs to be a bug report or not.
Per the 8.0.0 Docker documentation, Tribler is supposed to be installed in the /home/ubuntu directory, along with the Downloads folder.

-v ~/.Tribler:/home/ubuntu/.Tribler
-v ~/downloads/TriblerDownloads:/home/ubuntu/Downloads \

https://tribler.readthedocs.io/en/latest/basics/docker.html

The problem is that they are both being installed in /root/ instead of /home/ubuntu/.

[qstokkink]

Interesting. I just ran both commands listed in the docs (with a fresh pull - both the command with and without GUI) and it is using /home/ubuntu for me. Did you change anything in the config or images themselves?

[SpudmanWP]

No changes to the image and the only thing I can think of is maybe TrueNAS?

Attached is my YAML

Tribler_20260315.yaml

[SpudmanWP]

Grok did mention this:

$HOME is wrong inside some context
There are known cases (especially with older snap-installed Docker or certain container entrypoints) where $HOME evaluates to /root instead of the expected user home. This leads to config / credential files landing in the wrong place.

More from Grok

Common Causes (in Order of Likelihood)

1. Running commands / install scripts / docker login inside a root shell or with plain sudo without preserving $HOME
   This is by far the most frequent trigger for ~/.docker/config.json (or similar dotfiles) landing in /root/.docker instead of your user home.
   --When you do sudo docker login, sudo -i then run docker commands, or sudo su - first → the effective $HOME becomes /root.
   --Many people on cloud Ubuntu images (or TrueNAS shell) start sessions as root, so everything writes there.

2. Docker commands run via sudo without -E or proper env preservation
   sudo strips many environment variables by default (including $HOME) unless configured otherwise or you use sudo -E.

3.Inside the container itself (less likely what you're seeing)
Many Docker images default to running as UID 0 (root), so inside the container $HOME is /root. This only affects files created inside the container—not host-side user config like ~/.docker.

Rare edge cases
--Snap-installed Docker (weird $HOME behavior in some older versions).
--Custom entrypoints/scripts in images that don't set $HOME correctly.
--Build-time bugs (e.g., older Ubuntu docker.io packages mishandling useradd/home ownership during multi-stage builds—but fixed years ago in recent versions).

[qstokkink]

I'm not sure, but it might be related to your third point: we set user in our compose file:

tribler/build/docker/compose.yml

Line 29 in 463552e

user: $(id -u):$(id -g)