· After today’s update, I am unable to restart my Roon Server. My Mac downloaded and installed the update, and I tried to restart the server but it came up with an error that it could not find my Roon Server. I turned off the locations (local and network) and turned it back on. It still would not find my server.
I rebooted my Mac, and tried again. It got a little further and it came up with a screen that said connect to the Roon Server, I clicked connect and the connection icon came up and just hung there for more than 30 minutes before I closed the program.
Im running a Mac mini with the latest MAC OS with 16MB of ram. It’s a great clean machine. I have run into problems with updates in the past, but they always seem to fix themselves. This one seems stuck. If there are files (cache) that I need to delete, please advise. I’m not sure a reinstall would be helpful as my library has over 140,000 tracks to it and it would take a good chuck of time to start over.
Any assistance anyone can offer would be greatly appreciated.
It sounds like you’ve already tried retoggling Roon’s local network permissions in System Settings → Privacy & Security → Local Network.
We want to take a look at server logs, but the machine appears to be currently offline. At your convenience, please use the directions found here and send over a set of RoonServer logs to our File Uploader.
We’ll check for the source of the error and follow up.
We haven’t seen a response here, but our diagnostic servers do indicate some activity on the affected Roon Server since you first posted.
Are we correct in assuming that you’ve resolved this issue behind the scenes? Please reach out if we can assist further. This thread will eventually auto-close without any new responses.
Yes, I was able to get the server up and running, but it isn’t exactly stable.
This issue seems to creep in every time there is a Roon update, and although thankful for the updates it takes a good 20 mins to a half hour to get the Roon Server to be “discovered” and working again.
I have to reboot the Mac machine the Roon server software is on … which begs the question, why cant Roon find the Server OS that its literally on the same machine?
As well as having to reboot my entire network to even see it trying to make progress in finding the Roon software?
I submitted the log files to the devs for diagnostics.
The fact that I was able to get the Roon Server up and running again should not designate the topic or thread being closed. I would like the devs to get back to me with their findings.
This is not a one off issue, it’s literally every time Roon has an update. Many have pointed to turning the local network discovery on and off as a fix, which only works sometimes.
I would like to see this issue resolved so that when Roon does do an update my entire listening experience isn’t down for hours at a time.
Any further assistance that the devs could offer please have them reach out to me for testing or any additional information they need. Thx!
I completely understand the frustration. Thank you for taking the time to upload the logs; I have escalated them to our R&D team so they can review the exact sequence of events on your machine.
To be completely candid about what is happening under the hood: this repetitive issue is inherently a macOS security behavior, rather than a Roon-specific bug.
When the Roon application installs an update and changes its underlying files, the macOS security layer often silently panics and corrupts the internal “Local Network” permissions for the new version. It essentially blocks the newly updated app from talking to its own network stack. This is exactly why the Roon interface suddenly can’t find the Roon Server, even though they are literally running on the exact same piece of hardware, because it still uses the network stack to find even the local server.
Our developers are continuously looking for ways to force Apple’s network layer to handle these update transitions more gracefully. However, because this is an OS-level block, you absolutely do not need to reboot your entire home network when this happens. The blockage is entirely contained within the Mac mini.
For future updates, here is the most direct way to clear the macOS network block without touching your router:
Go to your Mac’s System Settings > Privacy & Security > Local Network and toggle both Roon and RoonServer OFF, then immediately back ON.
Click the small Roon icon in your Mac’s top menu bar (near the clock) and select Quit Roon Server, then launch it again.
If it still hangs, perform a standard reboot of the Mac itself.
A Permanent Alternative
If wrestling with macOS permissions after every update is becoming a dealbreaker, the most bulletproof solution is moving your Core to a dedicated Roon OS environment. Running a Roon Nucleus or installing our free ROCK (Roon Optimized Core Kit) on a dedicated Intel NUC removes desktop operating systems from the equation entirely. Because Roon OS is built exclusively to run Roon, these OS-level network firewalls and permission prompts simply do not exist, and updates install seamlessly.
Thanks for the reply and info Vadim. It’s not really frustration, although it may have appear as such in my reply, I apologize, but more of a “Roon is a premium service, this should be a focal point of devs to get it resolved”. That being said, I totally get the MAC OS level network block. Ive been on Macs for many years, beta test a lot of their eco system. It’s always a fancy dance to get things working on their platform. The reason they are so popular and in most cases “just work” with their implementation of products is because they are for the most part a closed eco system. Great if it works, but also a lot of work if it doesn’t.
I will, if it should hang on the next Roon update, refer to your suggestions here, and report back of what goes on. Again, thank you for the insight as well as the suggestions.
I still have not heard anything from Roon dev about their findings in my log files. Im willing to test things for them and even beta test aspects of Roon updates, but they would have to contact me for that to happen, and I haven’t heard anything.
As stated previously, this seems to be an ongoing problem. But I will let them know if anything goes on with the next Roon update.
Thanks for your continued willingness to help us troubleshoot and test!
I wanted to follow up on why you haven’t heard back from the dev team regarding your logs. Unfortunately, the diagnostic report we received did not cover the exact timeframe of the upgrade process itself. Because the “event” had already passed by the time the logs were generated, they didn’t capture the specific macOS security block in action, leaving our team without the data they need to trace the exact point of failure.
If this permission hang happens again during the next Roon update, we would love your help catching it red-handed. Please immediately grab a manual set of Roon logs, and ideally, save a copy of your Mac’s System Console logs covering the time of the update. Uploading both of those will give our engineers the exact Apple security flags they need to investigate how macOS is handling the transition.
Since you are highly technical and familiar with navigating different OS ecosystems and beta testing, have you ever considered moving your Roon Server to a Linux environment? Installing our free ROCK (Roon Optimized Core Kit) on a dedicated machine completely removes Apple’s aggressive network security layer from the equation. Updates on ROCK are entirely seamless because the OS is built exclusively to run Roon, avoiding the “macOS dance” entirely.
I am actually in the process of doing some docker work on a NAS that Im testing for a company and was going to install several versions of Linux in some containers. If you have any suggestions about which flavor of Linux distro you want me to possibly install ROCK on, let me know. It will be several weeks till software installs are installed on the NAS, but Im at the stage where Im starting to think about which ones I want to test for the company. Again, let me know if you have a particular distro your prefer to have ROCK tested on and when I get to that phase I will surely consider it.
We generally don’t recommend installing Roon in a container/docker environment because it can interfere with RAAT session stability and device discovery with your Zones. ROCK is technically a standalone custom Linux OS, and it doesn’t behave like a containerized app.
Here’s a list of supported NAS hardware:
That said, plenty of users successfully run Roon on Linux in a docker without issue. While not technically officially supported, many of these implementations are detailed in Tinkering. Let us know how we can help.
