RoonServer Docker Image: Roon ARC cannot connect to RoonServer

[Nickpi]

Arc (android or ios) detects the server, but cannot connect. Docker in a standard trixie proxmox vm (no fw, selinux etc.). The server works, Arc works with standard roon in a lxc.

services:
  roonserver:
    image: ghcr.io/roonlabs/roonserver:latest
    container_name: roonserver
    network_mode: host
    init: true
    environment:
      - TZ=Europe/Berlin
    volumes:
      - /opt/roon:/Roon
      - /mnt/music:/music:ro
      - /var/backup/RoonBackups:/backups
    stop_grace_period: 45s
    restart: unless-stopped
    logging:
      driver: local

[MusicD]

What does the Roon Arc setting page show?

[Nickpi]

Select the only active server, the whorl, “Can’t connect…”
Don’t get to the setup page.

This is on the local network. Tailscale is installed on the docker host, so the container should be reachable through tailscale.

Otherwise don’t see a difference to my other lxc instance, especially in terms of performance (33.500 tracks).

[ivan]

Hi, @Nickpi, thank you for the report. I moved this conversation to a different topic so that we can investigate this deeper.

Could you please share a zip archive with logs from this RoonServer instance? You can upload the archive here

Thanks!

–
Ivan

[Nickpi]

ok, the RoonServer_log and the docker log

[mjw (Father! Father! Resist not! Let us destroy the core! Set us free!)]

@Nickpi

Select the only active server,

If you have two instances of Roon server running on the same machine, i.e., using the same IP address, ARC will not work with one server since ARC on Android is setup to communicate with the LXC version on your public IP address.

[Nickpi]

The lxc is down.

[mjw (Father! Father! Resist not! Let us destroy the core! Set us free!)]

Doesn’t matter. You’ll need to reinstall ARC for it to work with the Docker container.

[ivan]

@Nickpi, thank you for uploading the log files. One more question, could you please share what you see in Roon ARC?

Thanks!

–
Ivan

[gTunes]

@Nickpi - I suspect this is a configuration, caching, or networking issue - not a fundamental issue with the container image.

@mjw

If you have two instances of Roon server running on the same machine, i.e., using the same IP address, ARC will not work with one server since ARC on Android is setup to communicate with the LXC version on your public IP address.

@mjw - Are you sure about this? There’s not networking issue that would prevent two instances on the same machine from working as long as they’re on different ports. But Roon maintains a cloud mapping and I don’t know enough about that mapping to know if it only supports a single instance on the LAN on a given IP. We’d have to understand the definition of the “key” side of the map to know because if it’s a unique id or a combination of IP + port, that would still work. It’s only if the key side is only the LAN IP that it wouldn’t work.

All that said…@Nickpi…some things to try

• Is your new container based version configured to listen for ARC on the same port as your lxc version? If so, add one or pick a different port

• I can see that your old and new instances are both called deb0 and ARC knows about them both by the same name. When I’m running multiple versions of Roon, I give them different names. The setting is in General. After changing it, restart the container though that doesn’t always seem to work immediately

• Sign out of Arc completely and sign back in. ARC isn’t always good at this especially if you’ve restored from a backup. If you have two instances of deb0 and one is from a restored backup of the other, that may be confusing the ARC client

@Nickpi

Otherwise don’t see a difference to my other lxc instance, especially in terms of performance (33.500 tracks).

You wouldn’t expect to, would you? LXC and Docker instances are going to share the host kernel and offer near-native file system performance. Running one versus the other is largely a matter of preference.

[Suedkiez (Just a fellow user like you)]

@gTunes

There’s not networking issue that would prevent two instances on the same machine from working as long as they’re on different ports. But Roon maintains a cloud mapping and I don’t know enough about that mapping to know if it only supports a single instance on the LAN on a given IP.

Wouldn’t the more fundamental issue simply be that one instance of ARC can only be connected to a single Roon Server, and if you change the server, you have to reinstall and resync ARC? That’s currently Alex’s the case, and I imagine the Docker server just counts as a new server like any other

[gTunes]

@Suedkiez

That’s currently Alex’s the case, and I imagine the Docker server just counts as a new server like any other

I’m not sure if this is true if the second instance is a restored backup of the first.

You’re saying “reinstall and resync ARC”, I was suggesting sign out. Same idea - I’m not sure which is better on Android. On iOS, uninstalling and re-installing ARC seems like a superset of sign out, so you’re recommendation is better.

[Suedkiez (Just a fellow user like you)]

@gTunes

I’m not sure if this is true if the second instance is a restored backup of the first.

Yes it is. This is annoying and support explicitly said that they are working on this.

Just the very latest example:

@connor

Have you tried reinstalling? It sounds like the session might have become unauthenticated (this can happen if you restored a Backup or migrated your server). Take note that reinstalling will require you to download any locally saved tracks in ARC to the phone again.

Or this (there are many others)

@connor

We recognize that it’s extraordinarily inconvenient for some users to redownload everything after restoring a Backup or switching to a new RoonServer machine. The team does have work in the pipeline to make server migration more seamless for ARC

[mjw (Father! Father! Resist not! Let us destroy the core! Set us free!)]

@gTunes

Are you sure about this?

This is my experience when running two servers (containers) on the same host. I’m guessing that Roon creates something like a key pair for each server, which means that ARC is tied to a specific server.

IIRC, when I rebuilt my server, and restored a backup, I had to reinstall ARC.

[Nickpi]

1. Install the container
2. Copy the roon backup directory to the docker host
3. Shut down the original lxc
4. Initial login on the new server, the old one is unauthorized.
5. Restore the backup on the new server, rename the roon instance from roon to deb0
6. Uninstalled/reinstalled Arc on android, though this is not necessary. You can simply swap servers in Arc.

Omitting the restore results in the same behaviour.

Should be simple enough to reproduce.

[gTunes]

@Suedkiez

Wouldn’t the more fundamental issue simply be that one instance of ARC can only be connected to a single Roon Server, and if you change the server, you have to reinstall and resync ARC?

I’m sure this is true if you install a new server. I’m less sure what happens when you restore from a backup because that may carry some internal server ID over to the new instance and that may create issues with how Roon’s cloud-based discovery service sees the instances.

I’m sure you absolutely correct about the important point, though - if you shut down the first instance, run the second instance, and uninstall / re-install ARC, you should be at a functioning state.

It sounds like @Nickpi has done this, so I don’t have a guess for what’s going on.

I’ve run multiple instances of Roon in docker containers on the same machine without issues (can sign out / into the other one in ARC) but in my environment I use a macvlan and give each container a unique address and I don’t use Tailscale. @Nickpi is using host networking and Tailscale so something else is going on. I don’t think it’s the container, though - I’ve been doing this with containers for a very long time and there’s nothing special or unique about this new container relative what I’ve been doing (and the rest of the Roon Docker users have been doing). So I do tend to think there’s more going on.

Just in case… @Nickpi - do you do anything with iptables or some other firewall tech?

[Nickpi]

this is either set up by tailscale or docker

root@deb0:~# iptables -L 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ts-input   all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-FORWARD  all  --  anywhere             anywhere            
ts-forward  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (9 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.21.0.2           tcp dpt:3000
ACCEPT     tcp  --  anywhere             pi.hole              tcp dpt:http
ACCEPT     udp  --  anywhere             pi.hole              udp dpt:bootps
ACCEPT     udp  --  anywhere             pi.hole              udp dpt:domain
ACCEPT     tcp  --  anywhere             pi.hole              tcp dpt:domain
ACCEPT     udp  --  anywhere             172.19.0.2           udp dpt:22000
ACCEPT     tcp  --  anywhere             172.19.0.2           tcp dpt:22000
ACCEPT     udp  --  anywhere             172.19.0.2           udp dpt:21027
ACCEPT     tcp  --  anywhere             172.19.0.2           tcp dpt:8384
ACCEPT     tcp  --  anywhere             172.25.0.3           tcp dpt:http-alt
ACCEPT     tcp  --  anywhere             172.18.0.2           tcp dpt:5001
ACCEPT     tcp  --  anywhere             172.20.0.2           tcp dpt:http
ACCEPT     tcp  --  anywhere             172.22.0.2           tcp dpt:9443
ACCEPT     tcp  --  anywhere             172.22.0.2           tcp dpt:8000
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-BRIDGE (1 references)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            

Chain DOCKER-CT (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
target     prot opt source               destination         
DOCKER-CT  all  --  anywhere             anywhere            
DOCKER-INTERNAL  all  --  anywhere             anywhere            
DOCKER-BRIDGE  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain DOCKER-INTERNAL (1 references)
target     prot opt source               destination         

Chain DOCKER-USER (1 references)
target     prot opt source               destination         

Chain ts-forward (1 references)
target     prot opt source               destination         
MARK       all  --  anywhere             anywhere             MARK xset 0x40000/0xff0000
ACCEPT     all  --  anywhere             anywhere             mark match 0x40000/0xff0000
DROP       all  --  100.64.0.0/10        anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain ts-input (1 references)
target     prot opt source               destination         
ACCEPT     all  --  deb0.cyprus-palermo.ts.net  anywhere            
RETURN     all  --  100.115.92.0/23      anywhere            
DROP       all  --  100.64.0.0/10        anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     udp  --  anywhere             anywhere             udp dpt:41641

Also disabled tailscale, also fails.

I think the network setup of the container is not correct, but I am not a network guru, let alone docker networks.