Roon running server not as a real daemon on macOS is a bad solution

I don’t know if this topic is already discussed, but I’d like to emphasize the importance of having Roon server running as a daemon, which is not the case at least on my preferred platform macOS. Imagine, that any other daemon running on any system would need to have a log in as a dedicated user, how would the permissions of the user look like? So any server running with this credentials needed to share the same access rights and credentials which is really a big security issue. To have a user logged in, and running just a background task is not the purpose of a user being auto logged in. I think this is really a big, big disadvantage and technically not correct. Are there any plans to correct this false behavior?

Sorry for my bad English, but I’m German.



I don’t see how running the Roon server as a daemon makes it more secure. On MacOS, most daemonized services run as root, giving them more permissions than they would get by running as a standard user. There are daemonized services which run in their own user space, which is more secure. (CoreAudio is an example of this.) However, you can replicate this benefit by just creating a dedicated Roon user and running the software there. The separation of permissions is important; being daemonized is not.

I might be overlooking something here, so please correct me if I’m wrong.


How would a database server would run? Or a mail server or any other of those? It‘s common sense that a server needs a dedicated configuration independent from any user configuration.

1 Like

Stefan, which version of the Roon app did you download? Combined, or Roon Server?

It’s been a few years since I worked with macOS, but back then there were special permission bits that had to be set to allow a program to communicate with the console. They were set at the top of the application bundle, and the execution machinery had to consult them to see how to sandbox the app. In particular, true daemons were not allowed access to the console. So the combined app couldn’t be a daemon. Roon Server, perhaps.

It depends on the operating system. I run a mail server on the OpenBSD operating system, and the mail server’s software runs as its own user. If you were looking to replicate this same sort of segmentation, you could create a MacOS user called “roon” and run the server as that user. Other users would not be able to interfere with the software that way. Daemonization merely makes it so that you don’t have to be logged in to run the software. I agree, this would be nice if Roon worked this way, but the security that would be gained by running it this way would be negligible.

There are a lot more rules about daemons on macOS than on BSD or SysV or Solaris. Due to Mach/NeXT architecture it’s based on, I suppose.


I asked this question almost one year ago, and now the new Roon Server is out. There comes immediately that question back in my mind. Do we still need a dedicated user to run Roon Server? Or is Roon Server now able to run just in the background without any user logged in like the database server does on my macMini?


If you are running Roon Server, build 1353, you will have seen that there is no change. Roon Server does not run as a MacOS daemon or Windows Service.