aio_talk preventing messages to send

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can. :heart:

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 34.0.2
  • Operating system and version (e.g., Ubuntu 24.04):
    • Ubuntu 24.04.4 LTS
  • Web server and version (e.g, Apache 2.4.25):
    • image: nextcloud:34-apache
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • container nginx proxy
  • PHP version (e.g, 8.3):
    • image: nextcloud:34-apache
  • Is this the first time you’ve seen this error? (Yes / No):
    • no
  • When did this problem seem to first start?
    • When using aio talk
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • aio-talk, docker
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • no

Summary of the issue you are facing:

Using my docker compose file, I have tried to configure the high performance backend in junction with nextcloud.

Whenever I try to write something in a chatroom or I try to create one, it fails.

Except when I write, what I’ve written stays in the chat at some unknown point after the failure messages displays.

Nextcloud shows that both high performance backend and the turn server should work.

grafik

Log entries

Nextcloud

Please provide the log entries from your Nextcloud log that are generated during the time of problem (via the Copy raw option from Administration settings->Logging screen or from your nextcloud.log located in your data directory). Feel free to use a pastebin/gist service if necessary.

[spreed] Warnung: Client error: `POST https://<signalDomain>/api/v1/room/9dtjkyde` resulted in a `403 Forbidden` response:
Authentication check failed


	POST /ocs/v2.php/apps/spreed/api/v1/chat/9dtjkyde
	von <ip Address> von <admin> um 12.08.2026, 23:47:17
[spreed] Warnung: Client error: POST https://<signalDomain>/api/v1/room/9dtjkyde resulted in a 403 Forbidden response:Authentication check failed

POST /ocs/v2.php/apps/spreed/api/v1/chat/9dtjkyde
von <ip Address> von <admin> um 12.08.2026, 23:47:17

Web Browser

If the problem is related to the Web interface, open your browser inspector Console and Network tabs while refreshing (reloading) and reproducing the problem. Provide any relevant output/errors here that appear.

setVisualLastReadMessageId token=9dtjkyde id=53 talk-main.js:210:1240258
XHR POST
https://<domain>/ocs/v2.php/apps/spreed/api/v1/chat/9dtjkyde
[HTTP/2 400  482ms]
Scrolling to a focused message programmatically talk-main.js:210:1243078
error while submitting message AxiosError: Request failed with status code 400 talk-main.js:20:259156
AxiosError: Request failed with status code 400
    tY AxiosError.js:102
    t$ settle.js:19
    ir xhr.js:62
    t1 xhr.js:78
    t1 xhr.js:16
    tZ dispatchRequest.js:46
    promise callback*_request Axios.js:196
    request Axios.js:41
    tW Axios.js:257
    tH bind.js:12
    xi messagesService.ts:172
    request CancelableRequest.ts:34
    postNewMessage messagesStore.js:1310
    ET vuex.esm-bundler.js:322
    dispatch vuex.esm-bundler.js:1055
    dispatch vuex.esm-bundler.js:937
    postMessage NewMessage.vue:1089
    handleSubmit NewMessage.vue:1081
    ir runtime-core.esm-bundler.js:199
    is runtime-core.esm-bundler.js:206
    n6 runtime-core.esm-bundler.js:4494
    onEnter NcRichContenteditable-Qw614bJ5.mjs:793
    59762/_B/tW[5]< NcRichContenteditable-Qw614bJ5.mjs:956
    tH runtime-dom.esm-bundler.js:1856
    tH runtime-dom.esm-bundler.js:1879
    ir runtime-core.esm-bundler.js:199
    is runtime-core.esm-bundler.js:206
    tq runtime-dom.esm-bundler.js:759
talk-main.js:210:562475
Conversations were saved to BrowserStorage. Estimated object size: 7.71 kB talk-main.js:20:204411

Web server / Reverse Proxy

The output of your Apache/nginx/system log in /var/log/____:

PASTE HERE

Configuration

YML File

services:

  ddclient:

    image: lscr.io/linuxserver/ddclient:latest

    container_name: ddclient

    environment:

      - PUID=1000            # Your user ID

      - PGID=1000            # Your group ID

      - TZ=Europe/Berlin    # Set your timezone

    volumes:

      - ./config:/config    # ddclient.conf goes here

    restart: unless-stopped

    network_mode: "host"




  db:

    container_name: db

    image: mariadb:10.11

    command: --transaction-isolation=READ-COMMITTED

    restart: unless-stopped

    volumes:

      - ./mysql:/var/lib/mysql:Z

    environment:

      - MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}

      - MARIADB_AUTO_UPGRADE=1

      - MARIADB_DISABLE_UPGRADE_BACKUP=1

      - MYSQL_PASSWORD=${MYSQL_PASSWORD}

      - MYSQL_DATABASE=nextcloud

      - MYSQL_USER=nextcloud

    networks:

      - net-internal-nextcloud




  redis:

    container_name: redis

    image: redis:alpine

    restart: unless-stopped

    networks:

      - net-internal-nextcloud




  app:

    container_name: app

    # pin to version 33.x to reduce potential impact after automatic

    # container updates

    image: nextcloud:34-apache

    restart: unless-stopped

    volumes:

      # NOTE: The `volumes` config of the `cron` and `app` containers must match

      - ./nextcloud/html:/var/www/html:z

      - ./php-config/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini

    expose:

      - 80

    environment:

      - VIRTUAL_HOST=${domain}

      - LETSENCRYPT_HOST=${domain}

      - NEXTCLOUD_TALK_INTERNAL_SECRET=${ncInternalSecret}

      - INTERNAL_SECRET=${ncInternalSecret}

      - REDIS_HOST=redis

      - MYSQL_HOST=db

      - MYSQL_PASSWORD=${MYSQL_PASSWORD}

      - MYSQL_DATABASE=nextcloud

      - MYSQL_USER=nextcloud

      - TURN_SECRET=${ncTurnSecret}

      - SIGNALING_SECRET=${ncSignalingSecret}

    depends_on:

      - db

      - redis

      # Added proxy container dependency below.

      # It is unclear on when or why it happens, but sometimes NC manages to start before the proxy

      # and it breaks for whatever weird reason resulting in the need of manual proxy container res>

      - proxy

    labels:

      com.centurylinklabs.watchtower.depends-on: db,redis,proxy

    networks:

      - net-internal-nextcloud

      - default



  talk_hpb:

    container_name: talk_hpb

    image: 


    init: true

    ports:

      - 3478:3478/tcp

      - 3478:3478/udp

      - 8081:8081/tcp

    expose:

      - 8081

      - 3478

    environment:

      - NC_DOMAIN=${domain}

      - TALK_HOST=${signalDomain}

      - TALK_PORT=3478

      - VIRTUAL_HOST=${signalDomain}

      - VIRTUAL_PORT=8081

      - TURN_SECRET=${ncTurnSecret}

      - SIGNALING_SECRET=${ncSignalingSecret}

      - TZ=Europe/Berlin

      - INTERNAL_SECRET=${ncInternalSecret}

      - LETSENCRYPT_HOST=${signalDomain}

      - REDIS_HOST=redis

    restart: unless-stopped

    networks:

      - net-internal-nextcloud

      - default




  cron:

    container_name: cron

    # pin to version 30.x to reduce potential impact after automatic

    # container updates

    image: nextcloud:34-apache

    restart: unless-stopped

    volumes:

      # NOTE: The `volumes` config of the `cron` and `app` containers must match

      - ./nextcloud/html:/var/www/html:z

    entrypoint: /cron.sh

    depends_on:

      - db

      - redis

    labels:

      com.centurylinklabs.watchtower.depends-on: db,redis,proxy




  proxy:

    container_name: nginx

    image: nginxproxy/nginx-proxy:alpine

    restart: unless-stopped

    ports:

      - 80:80

      - 443:443

    #  - 3478:3478

    #  - 8081:8081

    environment:

      - ACME_HTTP_CHALLENGE_LOCATION=true

    volumes:

      - ./nginx/certs:/etc/nginx/certs:ro,z

      - ./nginx/html:/usr/share/nginx/html:z

      - ./nginx/dhparam:/etc/nginx/dhparam:z

      - ./nginx/vhost.d:/etc/nginx/vhost.d:z

      - ./nginx/uploadsize.conf:/etc/nginx/conf.d/uploadsize.conf:ro

      - /var/run/docker.sock:/tmp/docker.sock:z,ro

      - ./nginx/conf.d:/etc/nginx/conf.d

    networks:

      net-internal-nextcloud:

        aliases:

          - ${domain}

          - ${signalDomain}

      default:





  acme:

    image: nginxproxy/acme-companion:latest

    container_name: nginx-acme

    restart: unless-stopped

    depends_on:

      - proxy

      - ddclient

    environment:

      - DEFAULT_EMAIL=${letsencryptEmail}

    volumes:

      - ./nginx/certs:/etc/nginx/certs:rw

      - ./nginx/vhost.d:/etc/nginx/vhost.d

      - ./nginx/html:/usr/share/nginx/html

      - /var/run/docker.sock:/var/run/docker.sock:ro

      - ./acme:/etc/acme.sh

    volumes_from:

      - proxy

    networks:

      - default


  # 


  watchtower:

    container_name: watchtower

    image: containrrr/watchtower:latest

    restart: unless-stopped

    volumes:

        - /var/run/docker.sock:/var/run/docker.sock

    # commands:

    # --cleanup      - remove old images

    # --schedule     - update schedule in seconds, minute, hour, day of month, month, day of week

    # --stop-timeout - wait more than 10s to shut down the container

    #                  there is plenty of time middle in the night

    command: --cleanup --schedule "0 30 20 * * *" --stop-timeout 180s

    networks:

      - net-watchtower

    environment:

      - DOCKER_API_VERSION=1.44




networks:

  # separate network for Watchtower communication

  net-watchtower:

  # internal communication of all Nextcloud containers

  net-internal-nextcloud:

    internal: true

    enable_ipv6: false

    ipam:

      config:

        - subnet: 10.10.10.0/24

  # separate network for static webserber

  # net-web:

  # separate network for Pi-hole

  net-pihole:

  web:

    driver: bridge

    external: true

    enable_ipv6: true

    ipam:

      config:

        - subnet: 192.18.0.0/16

        - subnet: 2001:db8:1::/64

Apps

The output of occ app:list (if possible).

Hey @Phill44 welcome to the Nextcloud community :waving_hand:

TIP: create secretpasswordkey

Make sure you create a long secretpasswordkey (min. 24 chars, better 32 chars) for each service! Note down the secretpasswordkeys as you will need them for creating the Docker stack and for configuring HPB in Nextcloud talk.

  • issue command in host shell and repeat for each service:
openssl rand -hex 32

grafik

1. TURN_SECRET
  • create a long random secretpasswordkey, issue command in host shell:
openssl rand -hex 32
2. SIGNALING_SECRET
  • create a long random secretpasswordkey, issue command in host shell:
openssl rand -hex 32
3. INTERNAL_SECRET
  • create a long random secretpasswordkey, issue command in host shell:
openssl rand -hex 32

connection errors

403 forbidden

TIP

make sure you have a long secretpasswordkey (min. 24 chars, better 32 chars) for each service!


hello @Phill44 and welcome to the community forum of Nextcloud.

I was wonderung which setup you finally do feature… did you install AIO or did you install docker?
Sure AIO runs using docker as well but the shipped versions of AIO and of docker are really different from each other. so it might be important to get to know which version you really have installed.
And afaik AIO installs a HPB itself. No need to tinker around with that one.

Sorry, haven’t properly specified: I use Nextcloud as a container and have the talk-aio as a container. I don’t use Nextcloud AIO.

Yep, I’ve done that.

      - INTERNAL_SECRET=${ncInternalSecret}
      - TURN_SECRET=${ncTurnSecret}
      - SIGNALING_SECRET=${ncSignalingSecret}

So, it seems I can’t connect to the high performance backend anymore after having commented out

grafik

So it must be something to do with the routing of the hpb

excep
curl -i https://<signalDomain>/api/v1/welcome
returns HTTP/2 200 and {"nextcloud-spreed-signaling":"Welcome","version":"2.1.1~docker"}

So it would seem it might have something to do with Websocket?

you have a very special setup, don’t you think so… using docker AND talk-aio.

I bet the answer to everything is in the code for AIO. why not looking there how HBP is connected to AIO-Talk?

I would assume that the whole point of having made a docker image for talk-aio is the whole point for using it with docker. tbf, I would assume that the comparatively special use case is nginx with docker and talk-aio.

I just tried and have realised as a result: I don’t know enough overall to understand much of anything.

In addition, the whole point of this post is that I don’t know exactly what I need to do. I don’t know what is necessary, so I don’t know how to manage this.

So, For instance, if you knew where exactly I should look for this, that would be very appreciated because I could then also try to learn that for the future.

I’d say the main reason the AIO developers created an AIO Docker image for the Talk HPB is to integrate the Talk HPB into AIO. :wink:

But yes, you can also use their image with a bare-metal installation or the community Docker images, and it generally works well with those setups. So the problem is most likely in your Docker stack, reverse proxy or network configuration.

Since I don’t use community Docker images myself, but run a “bare-metal” LAMP setup, I can’t help you troubleshoot this. However, if you want someone here to be able to help, it would probably be useful to post your complete setup and configuration.

that’s the main reason.
which means: it’s NOT intended to run with other docker setups. at least not out of the box.

So here’s another question for you: imho the AIO-branch is pretty well-maintained. why do YOU prefer normal docker over AIO? I mean you must have thought about it in advance.

I have actually tried it, but it, for some reason, didn’t work. I could definitely try again, but given that I know for certain that this nextcloud instance works perfectly, just not the HPB, I thought I would give it a try again.

Also, assuming that Nextcloud Talk High Performance Backend with Docker | Arno Welzel had worked (otherwise the person wouldn’t have uploaded it) doing HPB and NC seperately should’ve been fine. The problem overall is also that just not any guide seems to want you to work with nginx-proxy. The upside of it in my opinion, though, is that I already know how it works and would like to improve my knowledge of it instead of learning of a new proxy server.

The whole part of my setup (the docker compose file) is in my very first post (Or the origin of this discussion, whatever you want to call it)

Pretty much the only other thing that, as far as I remember, I might’ve configured outside of the compose file, would be the ddclient and I know for a fact that the domain works.

I think it’s possible to run aio-talk outside of AIO as scubamuc mentioned.. but like the whole AIO product customisation and integration into custom setup is not very easy. Look at his manual guide - maybe it it helps to understand the architecture - mechanics are always the same with each installation flavor

Nextcloud Talk High Performance Backend (HPB) - Multi-Domain Setup Guide

Please review your config

  talk_hpb:
    container_name: talk_hpb
    image: 
    init: true
    ports:
      - 3478:3478/tcp
      - 3478:3478/udp
      - 8081:8081/tcp
    expose:
      - 8081
      - 3478

ports: and expose: are AFAIK mutually exclusive, you want to use ports for TURN. don’t forget to allow this port in all firewalls and add port forwarding.. image: is also missing - but might you edited too much..

It’s definitely possible. As a matter of fact, you can even mix and match AIO containers and third-party containers with “bare-metal” Nextcloud setups.

Personally, I use the AIO Imaginary container with a bare-metal setup (and by “bare metal” I actually mean a LAMP setup in a VM), as well as the (non-AIO) Collabora CODE container behind a “bare-metal, non-Docker” Caddy instance, for which I pretty much “stole” the Caddyfile from AIO. That same Caddy instance also serves a few other public services I host.

I don’t personally use the AIO Talk HPB container, but I have tested it with the same kind of setup described above, and it worked.

@Phill44 I can’t really speak for the community Docker images, and especially not the Apache image, but I’m pretty sure it is possible if you create an environment that makes it possible.

That said, making this work does require at least a basic understanding of Linux, Docker, Docker networking, and networking in general. Looking at the “manual compose.yaml” of the AIO project or the containers folder in their GitHub repository will certainly help with that. Depending on your specific setup, though, you probably won’t find a 1:1 copy-and-paste solution.

So again, please post your exact configuration — your docker run commands or compose.yaml files for Nextcloud and the Talk HPB container. Otherwise, nobody will really be able to help you troubleshoot your particular setup.

Maybe there is a bug or something, but can you not see the yml in my original post?

if you click the link at the top, it should be viewable.

Oh, okay, my bad. :see_no_evil_monkey:

Now I’m trying to copy it into an editor, but I get this when I try to click the copy button… :face_with_diagonal_mouth:

Anyhow, it’s late. I might have a look at it tomorrow, and I might see something obvious, or maybe not.

For now, I can only tell you this much, which you might already know. It’s not enough to just start the container and enter the port and secret in Nextcloud. You also need to make it accessible through your web server/reverse proxy. Basically, you need to adapt what AIO does here to NGINX, Apache, or whatever you’re using.

In Apache, it would look something like this:

ProxyPass /standalone-signaling http://127.0.0.1:8081 upgrade=websocket

At least I can paste it directly into notepad and it doesn’t lose its format. I use nginx-proxy as my reverse proxy.

I will be trying some more tomorrow too, because I currently get an “unrecognized name alert”

Yeah, I could do it now too. uBlock Origin was interfering with it, which I normally have disabled for this site. :wink:

Anyway, I looked into it in the meantime, and I couldn’t find anything obvious. I should also point out that I don’t use the Nextcloud Docker images myself, so it’s quite possible I’m simply overlooking something.

Based on the error messages, though, there are two things you could check:

  1. Shared secret mismatch or insufficient secrets: As @scubamuc already mentioned, make sure you’re using long, random secrets. I’d generate them all with openssl rand -hex 32 and then check that the corresponding secrets match everywhere. Also check whether the problem started after an update, container recreation, restore, or configuration change. Maybe one side got a new secret while the other side is still using the old one.

  2. Reverse proxy: Make sure it passes all the necessary headers. It might be stripping or modifying the authentication headers required by the signaling server. Also check the URL/path configured in Nextcloud corresponds exactly to whats configured in the reverese proxy. I can’t really help with an exact Nginx configuration snippet off the top of my head, though.