To troubleshoot the connection hang on your Unraid Docker deployment, perform the following steps:
Verify that the Docker container’s Network Type is set specifically to Host in the Unraid template. Bridge or custom networks will block required multicast and TCP traffic between the Remote and the Server.
Restart the Roon Server container in Unraid 2-3 times to ensure all background network services initialize correctly.
In your Roon Remote app, click the Select a different Roon Server button, select the server instance, and log in. If this is a new container deployment with a new Machine ID, you must confirm the prompt to unauthorize the previous installation to release the license.
Provide a screenshot of your Unraid Docker template settings for the Roon container if the issue persists.
Thanks for the reply. This is my first roon installation. The server was working very well initially and I could connect via windows and android devices. Today however, I can’t access anything and all remote apps are stuck on the roon logo screen. I can’t select an alternate server as you suggest.
Update: I was able to select “choose a different server” and start the process on a windows PC, unauthorized the original server, retried login and unauthorized the windows PC. Now the original server has connected. If you could explain why this has happened and how to avoid in the future it would be much appreciated.
The scenario you described is a classic case of a session token mismatch or what’s often called a “zombie” authentication state. It’s frustrating when it happens, but the logic behind why your “musical chairs” with the Windows PC worked is actually quite sound from a networking perspective.
Why This Happened
When your server connects to a central account (like Plex, Emby, or a similar service), it doesn’t use your password every single time. Instead, it uses a Session Token—a unique digital “key” generated when you first log in.
Sometimes, the server’s local token becomes “stale” or out of sync with the master database. Your server thinks it’s logged in, but the central account server sees the key as expired or invalid. Because the server thinks it already has a key, it doesn’t always ask for a new one; it just keeps trying to use the broken one, leading to a connection loop.
By logging in on a different device (the Windows PC) and unauthorizing the original server, you effectively “killed” the old, broken key in the master database. This forced the original server to realize it was no longer “trusted,” finally triggering a fresh login handshake and generating a brand-new, valid token.
How to Avoid This in the Future
While these glitches can be random, you can minimize the chances of your “keys” getting out of sync by following these steps:
Static IP or DHCP Reservation: If your server’s internal IP address changes (which happens often with standard routers), the authentication token might freak out because the "location" of the device changed. Setting a Static IP for your server keeps its identity consistent.
Graceful Shutdowns: If the server loses power or the app crashes, the session token file can become corrupted. Always try to shut down the server software properly before restarting your hardware.
Keep "Ghost" Devices Clean: Periodically check your "Authorized Devices" list in your account settings. If you see multiple entries for the same PC or old browsers you no longer use, remove them. A cluttered device list can sometimes cause the database to struggle with new authentication requests.
Update Discipline: Ensure the server software and the client (the app you use to view it) are on compatible versions. An outdated server trying to talk to a modern authentication API is a recipe for a "token rejected" error.
