Unable to join TALK on fresh install

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 33.0.3
  • Operating system and version (e.g., Ubuntu 24.04):
    • Ubuntu 24.04
  • Web server and version (e.g, Apache 2.4.25):
    • shipped with AIO
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • shipped with AIO
  • PHP version (e.g, 8.3):
    • shipped with AIO
  • Is this the first time you’ve seen this error? (Yes / No):
    • Y
  • When did this problem seem to first start?
    • fresh install
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • AIO
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • no

Summary of the issue you are facing:

Can’t join TALK-Calls. Can send and receive text messages, but unable to join Video/voice chat.

I’m planning to migrate away from a Hetzner storage share to a dedicated VPS for Nextcloud and a storage box. I really love the TALK feature, and I don’t get it to work stable in the storage share setup.

I set up a clean Hetzner VPS, deployed a fresh Ubuntu 24.04, installed docker mounted my storage box at /mnt/storagebox, used this as DATADIR in --env and compose’d a clean AIO instance.

Not setting any custom settings, just going with the defaults I can’t seem to get TALK running reliably. I do not have a firewall in place for testing purposes, so it can’t be a blocked port.

In the TALK-Settings page, if I click the ping-button next to the TURN-server, I get a red exclamation mark, so I think somewhere there might be a problem?

Steps to replicate it (hint: details matter!):

  1. Install NC-AIO with dedicated DATADIR

  2. login, start a TALK Meeting

  3. can see users joining but never see video/hear voice

Log entries

#### nextcloud-aio-talk

Thanks in advance :slight_smile:

Since this instance is running on a Hetzner VPS, I would focus first on the Hetzner Cloud Firewall and direct reachability of the AIO Talk/TURN port.

There is no home router port forwarding involved here. The AIO Talk container needs to be reachable directly on the public IP of the VPS on both:

3478/tcp

3478/udp

The log shows that the Talk backend, NATS and Janus are starting. The signaling part seems to connect, but the call fails later with ICE errors:

ICE failed for component 1 in stream 1
Could not send MCU message … context deadline exceeded

Could not send MCU message … not connected

Together with the red TURN test in the Talk admin settings, this looks like a TURN/STUN reachability problem rather than a broken Talk app.

On Hetzner, check the Cloud Firewall assigned to the server. If the firewall only allows 22/tcp, 80/tcp and 443/tcp, Talk calls will fail.

Add inbound rules for:

TCP 3478 from 0.0.0.0/0 and ::/0ďżź

UDP 3478 from 0.0.0.0/0 and ::/0

Also check whether the domain has an AAAA record. If IPv6 is enabled in DNS, port 3478 must be reachable over IPv6 as well. Otherwise, temporarily remove the AAAA record and test IPv4 only.

On the VPS itself, verify that Docker is publishing the Talk port:

sudo docker ps --format “table {{.Names}}\t{{.Ports}}” | grep -E “talk|NAMES”

sudo ss -tulpen | grep ‘:3478’

The expected result should include 3478/tcp and 3478/udp for the nextcloud-aio-talk container.

If ufw or another OS firewall is active, also allow:

sudo ufw allow 3478/tcp

sudo ufw allow 3478/udp

The important point is that port 3478 is not handled by the normal HTTPS reverse proxy path. It must be reachable directly by the AIO Talk/TURN container.

Hi and thanks for the quick reply!

So for testing purposes I deactivated the Hetzner firewall completely, so it should not block anything anyway. I can ping the domain from my local computer on port 3478UDP and get a reply:

tim@MacStudio-von-Tim-2 ~ % nc -vzu domain.tld 3478
Connection to domain.tld port 3478 [udp/nat-stun-port] succeeded!

So it should be reachable by the talk app itself? I don’t have a AAAA in place, only the A record for IPv4.

If I interpret the output of docker ps correct, the container should be publishing the correct ports:

99f209371d8b   ghcr.io/nextcloud-releases/aio-talk:latest          "/start.sh superviso…"   38 seconds ago   Up 37 seconds (healthy)            0.0.0.0:3478->3478/tcp, 0.0.0.0:3478->3478/udp, [::]:3478->3478/tcp, [::]:3478->3478/udp                                                  nextcloud-aio-talk

The sudo ss command doesn’t output anything though. (?)

I didnt configure any ufw rules manually, but even after ufw allow, I don’t get a green tick in the ping options..

I think there is some communication problem between the containers, but I don’t know why, as I didn’t change any relevant default settings?

Thanks in advance :))

The Docker port mapping for the Talk container looks correct.

I would not focus on the empty ss output for now, because Docker may publish the port through NAT/iptables/nftables instead of a normal listening process on the host.

Could you share the docker-compose.yml you use for the AIO mastercontainer, with private values anonymized?

I would like to check the mastercontainer image/tag, published ports, Docker socket mount, AIO volume name and any custom environment variables. The issue may be related to the AIO setup/configuration rather than the Talk container port mapping itself.

It is just the default compose.yaml with the only addition of a separate DATADIR:

name: nextcloud-aio # Add the container to the same compose project to which all the sibling containers are added automatically
services:
  nextcloud-aio-mastercontainer:
    image: ghcr.io/nextcloud-releases/all-in-one:latest # This is the container image used. You can switch to ghcr.io/nextcloud-releases/all-in-one:beta if you want to help testing new releases. See https://github.com/nextcloud/all-in-one#how-to-switch-the-channel
    init: true # This setting makes sure that signals from main process inside the container are correctly forwarded to children. See https://docs.docker.com/reference/compose-file/services/#init
    restart: always # This makes sure that the container starts always together with the host OS. See https://docs.docker.com/reference/compose-file/services/#restart
    container_name: nextcloud-aio-mastercontainer # This line is not allowed to be changed as otherwise AIO will not work correctly
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config # This line is not allowed to be changed as otherwise the built-in backup solution will not work
      - /var/run/docker.sock:/var/run/docker.sock:ro # May be changed on macOS, Windows or docker rootless. See the applicable documentation. If adjusting, don't forget to also set 'WATCHTOWER_DOCKER_SOCKET_PATH'!
    # devices: ["/dev/dri"] # Uncomment to enable hardware acceleration. ⚠️⚠️⚠️ Warning: this only works if the '/dev/dri' device is present on the host! If it should not exist on your host, don't add this as otherwise the mastercontainer will fail to start! See https://github.com/nextcloud/all-in-one#how-to-enable-hardware-acceleration-for-nextcloud
    network_mode: bridge # This adds the container to the same network as docker run would do. Comment this line and uncomment the line below and the networks section at the end of the file if you want to define a custom MTU size for the docker network
    # networks: ["nextcloud-aio"]
    ports:
      - "80:80" # Can be removed when running behind a web server or reverse proxy (like Apache, Nginx, Caddy, Cloudflare Tunnel and else). See https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
      - "8080:8080" # This is the AIO interface, served via https and self-signed certificate. See https://github.com/nextcloud/all-in-one#explanation-of-used-ports
      - "8443:8443" # Can be removed when running behind a web server or reverse proxy (like Apache, Nginx, Caddy, Cloudflare Tunnel and else). See https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
    # security_opt: ["label:disable"] # Needed when using SELinux. See https://github.com/nextcloud/all-in-one#are-there-known-problems-when-selinux-is-enabled
    environment: # This line is needed (has to be uncommented) when using any of the options below
      # AIO_DISABLE_BACKUP_SECTION: false # Setting this to true allows to hide the backup section in the AIO interface. See https://github.com/nextcloud/all-in-one#how-to-disable-the-backup-section
      # APACHE_PORT: 11000 # Needed when running behind a web server or reverse proxy (like Apache, Nginx, Caddy, Cloudflare Tunnel and else). See https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
      # APACHE_IP_BINDING: 127.0.0.1 # Should be set when running behind a web server or reverse proxy (like Apache, Nginx, Caddy, Cloudflare Tunnel and else) that is running on the same host. See https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
      # APACHE_ADDITIONAL_NETWORK: frontend_net # (Optional) Connect the apache container to an additional docker network. Needed when behind a web server or reverse proxy (like Apache, Nginx, Caddy, Cloudflare Tunnel and else) running in a different docker network on same server. See https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
      # BORG_RETENTION_POLICY: --keep-within=7d --keep-weekly=4 --keep-monthly=6 # Allows to adjust borgs retention policy. See https://github.com/nextcloud/all-in-one#how-to-adjust-borgs-retention-policy
      # AIO_LOG_LEVEL: warn # Allows to globally adjust the log level of the included AIO components. Supported values: debug, info, warn, error. See https://github.com/nextcloud/all-in-one#how-to-adjust-the-log-level-for-aio-components
      # COLLABORA_SECCOMP_DISABLED: false # Setting this to true allows to disable Collabora's Seccomp feature. See https://github.com/nextcloud/all-in-one#how-to-disable-collaboras-seccomp-feature
      # DOCKER_API_VERSION: 1.44 # You can adjust the internally used docker api version with this variable. ⚠️⚠️⚠️ Warning: please note that only the default api version (unset this variable) is supported and tested by the maintainers of Nextcloud AIO. So use this on your own risk and things might break without warning. See https://github.com/nextcloud/all-in-one#how-to-adjust-the-internally-used-docker-api-version
      # FULLTEXTSEARCH_JAVA_OPTIONS: "-Xms1024M -Xmx1024M" # Allows to adjust the fulltextsearch java options. See https://github.com/nextcloud/all-in-one#how-to-adjust-the-fulltextsearch-java-options
      NEXTCLOUD_DATADIR: /mnt/storagebox/ncdata # Allows to set the host directory for Nextcloud's datadir. ⚠️⚠️⚠️ Warning: do not set or adjust this value after the initial Nextcloud installation is done! See https://github.com/nextcloud/all-in-one#how-to-change-the-default-location-of-nextclouds-datadir
      # NEXTCLOUD_MOUNT: /mnt/ # Allows the Nextcloud container to access the chosen directory on the host. See https://github.com/nextcloud/all-in-one#how-to-allow-the-nextcloud-container-to-access-directories-on-the-host
      # NEXTCLOUD_UPLOAD_LIMIT: 16G # Can be adjusted if you need more. See https://github.com/nextcloud/all-in-one#how-to-adjust-the-upload-limit-for-nextcloud
      # NEXTCLOUD_MAX_TIME: 3600 # Can be adjusted if you need more. See https://github.com/nextcloud/all-in-one#how-to-adjust-the-max-execution-time-for-nextcloud
      # NEXTCLOUD_MEMORY_LIMIT: 512M # Can be adjusted if you need more. See https://github.com/nextcloud/all-in-one#how-to-adjust-the-php-memory-limit-for-nextcloud
      # NEXTCLOUD_TRUSTED_CACERTS_DIR: /path/to/my/cacerts # CA certificates in this directory will be trusted by the OS of the nextcloud container (Useful e.g. for LDAPS) See https://github.com/nextcloud/all-in-one#how-to-trust-user-defined-certification-authorities-ca
      # NEXTCLOUD_STARTUP_APPS: deck twofactor_totp tasks calendar contacts notes # Allows to modify the Nextcloud apps that are installed on starting AIO the first time. See https://github.com/nextcloud/all-in-one#how-to-change-the-nextcloud-apps-that-are-installed-on-the-first-startup
      # NEXTCLOUD_ADDITIONAL_APKS: imagemagick # This allows to add additional packages to the Nextcloud container permanently. Default is imagemagick but can be overwritten by modifying this value. See https://github.com/nextcloud/all-in-one#how-to-add-os-packages-permanently-to-the-nextcloud-container
      # NEXTCLOUD_ADDITIONAL_PHP_EXTENSIONS: imagick # This allows to add additional php extensions to the Nextcloud container permanently. Default is imagick but can be overwritten by modifying this value. See https://github.com/nextcloud/all-in-one#how-to-add-php-extensions-permanently-to-the-nextcloud-container
      # NEXTCLOUD_ENABLE_NVIDIA_GPU: true # This allows to enable the NVIDIA runtime and GPU access for containers that profit from it. ⚠️⚠️⚠️ Warning: this only works if an NVIDIA gpu is installed on the server. See https://github.com/nextcloud/all-in-one#how-to-enable-hardware-acceleration-for-nextcloud.
      # NEXTCLOUD_KEEP_DISABLED_APPS: false # Setting this to true will keep Nextcloud apps that are disabled in the AIO interface and not uninstall them if they should be installed. See https://github.com/nextcloud/all-in-one#how-to-keep-disabled-apps
      # SKIP_DOMAIN_VALIDATION: false # This should only be set to true if things are correctly configured. See https://github.com/nextcloud/all-in-one#how-to-skip-the-domain-validation
      # TALK_PORT: 3478 # This allows to adjust the port that the talk container is using which is exposed on the host. See https://github.com/nextcloud/all-in-one#how-to-adjust-the-talk-port
      # WATCHTOWER_DOCKER_SOCKET_PATH: /var/run/docker.sock # Needs to be specified if the docker socket on the host is not located in the default '/var/run/docker.sock'. Otherwise mastercontainer updates will fail. For macos it needs to be '/var/run/docker.sock'

#   # Optional: Caddy reverse proxy. See https://github.com/nextcloud/all-in-one/discussions/575
#   # Alternatively, use Tailscale if you don't have a domain yet. See https://github.com/nextcloud/all-in-one/discussions/6817
#   # Hint: You need to uncomment APACHE_PORT: 11000 above, adjust cloud.example.com to your domain and uncomment the necessary docker volumes at the bottom of this file in order to make it work
#   # You can find further examples here: https://github.com/nextcloud/all-in-one/discussions/588
#   caddy:
#     image: caddy:alpine
#     restart: always
#     container_name: caddy
#     volumes:
#       - caddy_certs:/certs
#       - caddy_config:/config
#       - caddy_data:/data
#       - caddy_sites:/srv
#     network_mode: "host"
#     configs:
#       - source: Caddyfile
#         target: /etc/caddy/Caddyfile
# configs:
#   Caddyfile:
#     content: |
#       # Adjust cloud.example.com to your domain below
#       https://cloud.example.com:443 {
#         reverse_proxy localhost:11000
#       }

volumes: # If you want to store the data on a different drive, see https://github.com/nextcloud/all-in-one#how-to-store-the-filesinstallation-on-a-separate-drive
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer # This line is not allowed to be changed as otherwise the built-in backup solution will not work
  # caddy_certs:
  # caddy_config:
  # caddy_data:
  # caddy_sites:

# # Adjust the MTU size of the docker network. See https://github.com/nextcloud/all-in-one#how-to-adjust-the-mtu-size-of-the-docker-network
# networks:
#   nextcloud-aio:
#     name: nextcloud-aio
#     driver_opts:
#       com.docker.network.driver.mtu: 1440

Glad for sharing the compose file.

The compose file itself looks mostly default, but one thing stands out:

NEXTCLOUD_DATADIR: /mnt/storagebox/ncdata

Is this /mnt/storagebox a Hetzner Storage Box mounted via SMB/CIFS, SSHFS, WebDAV or something similar?

If yes, I would strongly recommend not using a Hetzner Storage Box as the primary Nextcloud datadir.

It may technically work, but it is not a good place for live Nextcloud data. Nextcloud’s datadir is not just “large file storage”. It also has many small reads/writes, metadata operations, file locking, previews, appdata, cache-related files and app-specific data. A remote network mount can introduce latency, locking issues or slow I/O, which may cause strange behaviour and timeouts.

I would use:

local VPS disk / Hetzner Volume / dedicated local block storage → Nextcloud datadir
Hetzner Storage Box → backups only, for example Borg/AIO backups

So for testing, I would suggest setting up a clean AIO instance with the datadir on the local VPS disk or on a Hetzner Volume, not on the Storage Box, and then test Talk again.

I am not saying this is definitely the only reason for the Talk issue, but using a Storage Box as the primary Nextcloud datadir is not a setup I would recommend. It is much better suited as a backup target than as live application storage.

So I just spun the VPS back up and installed AIO without the custom DATADIR, and it seems like that solves the problem!

I get why this initial setup might not be the standard use case, but I just followed the steps of the official documentation (which I thought would be testet/working?).

https://github.com/nextcloud/all-in-one#can-i-use-a-cifssmb-share-as-nextclouds-datadir

https://github.com/nextcloud/all-in-one?tab=readme-ov-file#how-to-move-the-appdata-folder-from-the-datadir-to-an-ssd-to-improve-the-performance

For my use case I have to use some cheap form of file storage, as I intend to exchange large amounts of video files (video production company). We don’t need fast SSD storage for that and it would be way too expensive.

At first I tried to mount it as an “external storage” via the Nextcloud GUI, but users would be able to store files on the SSD by default.
How would I set up something like that? Nextcloud including all relevant app data on the SSD and all “payload” data on the slower but way larger smb/cifs/storage box?

Thanks for helping me out :slight_smile:

That test result is quite telling. If Talk works with the default/local datadir but breaks when the Storage Box is used as NEXTCLOUD_DATADIR, I would not use the Storage Box as live Nextcloud storage.

For a reliable production setup I would keep it simple:

Hetzner Volume / local block storage → Nextcloud datadir

Hetzner Storage Box → Borg/AIO backups

A Storage Box is fine as a backup target, but I would not use it as the primary datadir for a company Nextcloud. The datadir is part of the live application workload, not just passive file storage.


For your consideration

If this is for a video production company with large files, I would also consider a dedicated server or an on-premise self-hosted Nextcloud server with proper local storage.

If the server runs inside the company network, local DNS can be configured so the normal Nextcloud domain resolves to the local LAN IP internally, while still resolving to the public IP from outside. That way, users in the office can use the full LAN speed for large video files instead of routing everything through the internet connection. :wink:

Thanks for the clarification!

We do have some high-speed networking solution for production workloads in place already. But German copper-based ISPs are nowhere fast enough for serving files to multiple clients reliably outside the LAN..

Nextcloud is supposed to be a platform for exchanging footage from external contractors, final delivery to clients and basic (=slow) file exchange with people working from other parts in the world.

As well as its supposed to serve all those cool features like TALK, Office, calendars, Mail, etc.

For this purpose I need a cheap, large and slow means of file storage, where the storage box seems to serve perfectly! I tried to mount it as an external storage, but user access controls seem to not be taken into account (all users can see everything), which is a no go..

Is there really no way of using Nextcloud (and all the files that need fast storage) on the VPS SSD volume and putting all payload-files on this slow storage box? I tried local mount, bit it doesn’t care about Users as well..

Thanks in advance :slight_smile:

That makes sense, glad for clarifying.

I understand your point about the office connection:

  • the internal production network may be fast,

  • but the external internet uplink may not be suitable for reliably serving large files,

  • especially when contractors or clients need access from outside the LAN.

So yes, for this use case, hosting Nextcloud in a datacenter can make sense.

However, I would calculate the traffic side very carefully before deciding on the final setup.

With video production workloads, the storage price alone is not the full cost. Large files will still move through the VPS/cloud infrastructure in different directions:

  • contractors uploading footage,

  • clients downloading final deliveries,

  • revisions and repeated downloads,

  • syncing files back to the company,

  • general file exchange with external users.

So I would not only compare the price per TB of storage, but also check:

  • included monthly traffic,

  • traffic overage costs,

  • expected TB transferred per month,

  • whether the traffic costs are predictable enough for production use.

For normal office files this may not matter much, but for large video files it can become one of the main cost factors.

So in short: I would look for a setup where both storage and traffic are predictable, not only where the storage itself looks cheap.

If you are happy with external storage you could simply cut the quota so the can’t store huge files in their personal space and forced to use external storage volumes.

But don’t use 0B - this prevents some functionality like sharing pictures in a talk conversation.

Sorry for asking but its not clear for me wheter you have you tried to move the appdata directory within the /mnt/storagebox/ncdata directory to local disk as described in the link you mentioned (https://github.com/nextcloud/all-in-one?tab=readme-ov-file#how-to-move-the-appdata-folder-from-the-datadir-to-an-ssd-to-improve-the-performance) ? According to the documentation this should solve your problem as user data is on external storage and appdata is on local disk.

I did follow this guide, but it disabled me from using the talk feature correctly.

If mounting the storagebox via SMB fails, I expect very weird things to happen, so for now I have the storagebox mounted as “external storage” via GUI, but using a /$users path so the files stay with their associated accounts.

I couldn’t fully get up to the problem with talk though. It may be a problem just with safari on my main device, as it works in safari on other devices, and in chrome on my main device.

For now, I’m in testing phase with this setup, so thanks for all your suggestions :slight_smile: