What is the operating system of your Roon Server host machine?
· Roon on a NAS (Synology, QNAP, ASUSTOR)
What kind of device are you using to perform the login?
· iOS
Where are you trying to login?
· I can't log into Roon
Please try to restart your Roon Server by closing the Roon Server app in the taskbar (MacOS), task manager (Windows) or rebooting your Roon Server machine.
· No, the issue remains the same
Different device
· I am able to switch to the diffrent device
Are you still facing the issue on the different device
· No, the issue remains the same
Record the timestamp
· 3:07 PM MT
Describe the issue
My roon server appears to be online, but when I tap "connect" i get a window with an animated roon logo and that is the end of the journey. I get stuck there. Tried it on mac, pc, and iphone. Same result. This seems to have started after the latest roon server update
Describe your network setup
Centurylink fiber modem c4000xg connected to Eero 6+ mesh network. I have not made a single change or adjustment to the system since roon was working a few days (or week) ago
Thank you for reaching out. I completely understand how confusing it is when your system suddenly hangs on the loading screen right after an update.
A big thank you to @DDPS for jumping in with the correct explanation!
Recent updates to the Roon architecture introduced new underlying system and software library requirements. Unfortunately, native NAS operating systems can no longer support these modern libraries directly. Because of this, the traditional Roon app package for NAS devices will fail to fully initialize in the background, which is why your remotes are getting stuck spinning on the animated logo.
To get your Roon Server running smoothly again, you will need to transition your setup to run Roon via Docker. Running Roon inside a container safely isolates it from the NAS OS limitations and provides it with all the necessary libraries to run optimally.
@DDPS provided the link for the QNAP migration guide above. Please let us know if you have any other questions or concerns regarding this matter.
My apologies for the oversight! Looking closely at your screenshot, I see you are actually running Unraid, not QNAP.
Since our backend shows your server hasn’t successfully checked in for about 5 days, and your remotes are stuck spinning on the logo, it’s highly likely the container’s internal database has become corrupted and is stuck in a boot loop.
Let’s try a true “clean slate” reset to isolate the issue:
1. Check the Unraid Logs
Before we delete anything, let’s see what the container is choking on.
In your Unraid Docker tab, click the Roon container icon and select Logs.
Look for any repeating error messages, tracebacks, or database corruption warnings. Please copy/paste the last few lines here for us.
2. The “Clean Slate” Reset
To break the loop, we need to completely wipe the current environment and start fresh, bypassing any backups for the moment.
Remove the Container: In the Unraid Docker tab, click the Roon container and select Remove.
Wipe the Appdata: This is the most critical step. Open the Unraid terminal or use your file manager to navigate to your Roon appdata share (usually /mnt/user/appdata/RoonServer or whatever you mapped your database to). Completely delete or rename this folder. If the corrupted data remains, the new container will just get stuck on it again.
3. Test a Fresh Start
Go to your Unraid Apps tab and reinstall the container, or go to the Docker tab > Add Container > select your previous Roon template from the User Templates dropdown.
Open the Roon Remote app on your iPhone or Mac.
Crucial Step: When prompted, choose to set it up as a new server. Do not restore a backup at this stage.
Please share your Docker Compose YAML file here before starting a new installation
We need to verify if your remotes can successfully connect to a completely blank, freshly initialized server. Let us know how the fresh install behaves and what you find in those logs!
Thank you for the response. To be prcise, I am running Unraid on a QNAP NAS, so we’re both right
I copied bac far enough on the log to see the error message:
100 107M 100 107M 0 0 41.3M 0 0:00:02 0:00:02 --:–:-- 41.3M
aac_fixed decoder found, checking libavcodec version…
has mp3float: 1, aac_fixed: 1
Running
System.Net.Sockets.SocketException (104): Connection reset by peer
at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16 token)
at System.Threading.Tasks.ValueTask1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state) --- End of stack trace from previous location --- at System.Threading.Tasks.TaskToApm.End[TResult](IAsyncResult asyncResult) at Sooloos.RnetJsonClient.<>c__DisplayClass65_0.<_BeginRead>b__0(IAsyncResult ar) 00:00:00.002 Info: get lock file path: /tmp/.rnsgem0- 00:00:00.012 Info: GetLockFile, fd: 58 00:00:00.013 Info: GetLockFile, res: 0 00:00:00.014 Trace: Nope, we are the only one running Initializing Started [Sentry] Initialized for RoonServer (appliance), release: roonserver@206401646+production Not responding Running System.Net.Sockets.SocketException (104): Connection reset by peer at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken) at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16 token) at System.Threading.Tasks.ValueTask1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
— End of stack trace from previous location —
at System.Threading.Tasks.TaskToApm.End[TResult](IAsyncResult asyncResult)
at Sooloos.RnetJsonClient.<>c__DisplayClass65_0.<_BeginRead>b__0(IAsyncResult ar)
00:00:00.003 Info: get lock file path: /tmp/.rnsgem0-
00:00:00.014 Info: GetLockFile, fd: 74
00:00:00.014 Info: GetLockFile, res: 0
00:00:00.015 Trace: Nope, we are the only one running
Initializing
Started
[Sentry] Initialized for RoonServer (appliance), release: roonserver@206501653+production
Not responding
Running
00:00:00.003 Info: get lock file path: /tmp/.rnsgem0-
00:00:00.014 Info: GetLockFile, fd: 74
00:00:00.015 Info: GetLockFile, res: 0
00:00:00.016 Trace: Nope, we are the only one running
Initializing
Started
[Sentry] Initialized for RoonServer (appliance), release: roonserver@206601658+production
Not responding
Error
Initializing
Started
[Sentry] Initialized for RoonServer (appliance), release: roonserver@206601658+production
Not responding
Running
00:00:00.003 Info: get lock file path: /tmp/.rnsgem0-
00:00:00.014 Info: GetLockFile, fd: 74
00:00:00.015 Info: GetLockFile, res: 0
00:00:00.016 Trace: Nope, we are the only one running
Initializing
Started
[Sentry] Initialized for RoonServer (appliance), release: roonserver@206601658+production
Not responding
Running
00:00:00.003 Info: get lock file path: /tmp/.rnsgem0-
00:00:00.020 Info: GetLockFile, fd: 74
00:00:00.021 Info: GetLockFile, res: 0
00:00:00.022 Trace: Nope, we are the only one running
Initializing
Started
[Sentry] Initialized for RoonServer (appliance), release: roonserver@206601658+production
Not responding
Running
Thanks for the reply! From what we can see, it appears to be a pattern similar to: Initializing → Started → Not responding → Running → crash → repeat.
The SocketException (104): Connection reset by peer on RnetJsonClient means Roon Server is starting up, trying to connect back to Roon’s cloud/licensing infrastructure, and getting its connection forcibly dropped. It then crashes and restarts in a loop.
This doesn’t seem like local database corruption, but more so a network/connectivity issue between the container and Roon’s servers.
A few areas this could relate to:
Docker network mode: If your container is running in bridge mode, it may not have proper outbound internet access. Roon needs to phone home to activate/verify.
Port conflict or firewall: QNAP’s own firewall or the Unraid bridge could be blocking/resetting outbound TCP connections on the ports Roon uses (9003, 9100–9200 range).
DNS resolution failure inside the container: The container may not be resolving Roon’s cloud hostnames, causing immediate connection resets.
Let’s see if any of the below help:
Switch Docker network to host mode. This is the most common fix for this exact symptom on Unraid. In your container template, change the network type from bridge to host. This gives Roon direct network access without NAT.
Check outbound connectivity from inside the container. From the Unraid terminal:
docker exec -it curl -v https://push.roonlabs.com
If this fails or resets, the container has no outbound internet.
Check for a QNAP firewall rule that might be blocking Docker bridge traffic. QNAP's Security Counselor or built-in firewall can interfere with Unraid's Docker networking.
Share your Docker template/Compose YAML in the thread. The mapping of /tmp is sometimes the culprit, if /tmp inside the container is mapped to a slow NAS share rather than RAM/local disk, the lock file operations can misbehave.
Finally got it to work by setting it to bridge mode, restarting, then set it back to host mode and it worked. Not satisfying, but it did work. Remember, everything was working until I updated the software, so something in that process broke the server. My settings on unraid never changed.
Anyway, thank you so much for the help. I was about to quit roon
I also want to reiterate that even though I am on a QNAP piece of hardware, I am not running QTS OS. It is 100% Unraid so none of the QNAP firewalls apply to this situation. Thank you again for your help!
Got it—that makes perfect sense regarding Unraid acting as the sole OS on that QNAP hardware. Thank you for the clarification!
I am thrilled to hear you are back up and running, though I completely understand why the fix feels unsatisfying. Sometimes during a container update, Docker’s internal networking or the host’s routing tables can get temporarily “stuck.” By toggling from Host to Bridge and back to Host, you essentially forced Unraid to tear down and completely rebuild the network bindings for the Roon container, clearing out whatever got tangled during the update.
We appreciate you sticking with it and sharing your solution! This is incredibly helpful for other Unraid users who might run into a similar post-update networking quirk.
Since everything is working again, I will go ahead and close this thread. Please don’t hesitate to open a new topic if you ever run into any other issues.
