@Stephen - I am not sure you realize, but Container Manager only runs on Synology DSM 7.2 and later, which have all the dependencies required to run Roon on NAS, making this documentation a bit moot. To support earlier DSM, you need to reference their “Docker” package, rather than Container Manager…
Hey guys, we are delaying the release, and we also need your help and feedback, please read this post. Thanks
UPD, I will actually add the post here for simplicity:
====================
Hi everyone,
Quick update on 2.65: the release itself is ready, but we’re going to hold it for another week.
2.65 raises the system requirements, which means some hardware won’t be able to run Roon natively anymore. For those users, Docker is the path forward - and while the image works, it’s new, and we want it to get more reliable before we ship 2.65.
Docker can run across a huge range of systems, OS versions, and configurations - far more permutations than we can exercise in-house. We’ve written up install steps for the environments we know about in our KB article, and we need the community’s help to validate them on real hardware before 2.65 ships.
If Docker is going to be your path moving forward, here’s how you can help:
- Follow the steps in the KB article for your setup and let us know if they worked
- If something didn’t work and you figured out a fix, share what you did - screenshots are especially helpful, and we can fold them back into the article
- Include your hardware, OS, and any relevant version/firmware details
- Post feedback in the thread below
Links
- KB article: https://help.roonlabs.com/portal/en/kb/articles/installing-the-roon-server-via-docker
- Feedback thread: https://community.roonlabs.com/t/earlyaccess-roonserver-docker-image-feedback
We’ll iterate quickly on the image and the KB based on what comes in, with the goal of making the Docker path land cleanly when 2.65 goes out.
One note on branches: if you don’t set ROON_INSTALL_BRANCH, it will install production (v2.64), not early access. That’s fine - what we’re testing here is the Docker image, not the release itself.
3 Likes
@vova 2 remarks / info from my QNAP side:
the docker configuration tool is super cool: but I specify the paths as follows:
/share/CACHEDEVx_DATA/xxxx
I specify this CACHEDEVx_DATA path in between to make sure I’m actually using the real mount points which won’t break if some share gets renamed in the QNAP UI….
I also do not use the QNAP container station, because I never got it to work with 1 stack of multiple containers inside 1 app stack.
The description in the KB will not create a stack, but just 1 separate container.
I can make a stack of multiple containers within 1 app without problems manually with docker compose via SSH - so I use this atm 
or with portainer (haven’t checked this dockhand thing yet)
Roon removed the stop_grace_period from their generated compose. It’s not harming anything to leave it.
You might want to look at the generator for their recommendations for Music and Backup folders, too. Yours works fine but they refer to using the /Music folder as the default destination for drag and drop, which makes me think Roon has some sort of feature that allows you to drag and drop files onto a client somehow. Your mapping won’t work with that, if you care, because you’re mapping to /music instead of /Music and you’re specifying ro.
This works in principle:
However, the new Docker KB states:
Optionally add a second path mapping: Container path
/Music, Host path pointing to your music library, set to read-only.
So I’m not sure here.
I’m a bit hesitant to change my music folder mapping
I don’t really want drag and drop to Roon 
I use my main windows workstation as source of the truth for my music files - they get ripped / tagged / renamed / put into correct folders there – the most important part of it gets synched cloud backup.
Then I want manual control when I’m ready to synch to the NAS (after ripping / tagging / renaming etc is done) then I just trigger my robocopy mirror job to replicate the truth folder from windows to the NAS ensuring I have 2 identical copies in my local network and the important part also to the cloud.
My backup folder is indeed something I have to double check: this is the old roon backup share where I was doing my backups from Rock and Roon on Nas before
Is this a new requirement? In the how-to guide its stated;
”Note: Roon’s database must be on an SSD. On Synology, this typically means placing the /Roon volume on your system volume rather than on spinning disk expansion storage.”
AFAIK it is not a strict requirement, roon in theory used to run on a spinning disc. It is just not recommended, as glitches and delays can always occur, and user experience is really not great. Not sure about impact on HDD either, as they really have to write and move the head a lot.
Yeah, I know it’s recommended to use SSD, but I’m a bit unsure when they use the word «must» - in my mind must describes a requirement and not a recommendation.
I used to use spinning discs just fine, but my collection was half the size back then. Who knows what sort of difference it might make today.
Hi, providing feedback on early access v2.65 (build 1654).
Installed on a QNAP TS-464 w/16GB RAM using the Docker compose route. Performance appears to be excellent. My server was previously on a 13th gen i5 Windows box and everything feels just as snappy browsing a 100k track/7750 album library. I use Squeezebox endpoints and don’t do any DSP.
Only wish it was possible to run this in bridged mode but I understand why not.
It’s a recommendation and a confusing one at that. If your database lived on spinning media before, it can and should live on spinning media now. It’s unlikely to perform worse than it did. Putting the database on SSD (or using a caching strategy) is a very good idea, though.
If you don’t want to run bridged, there are ways to set things up so that you can assign a container a unique IP. On most platforms, you ssh in and use docker network commands to create a macvlan. On QNAP, you may be able to do it in their GUI - I recall they have some custom Q network thing. I’m not sure how it works. “Host” is the simplest thing for most people and will work just fine for all scenarios including endpoint discovery and ARC. If you want a unique IP, though, it’s possible.
I run Roon on Synology today using spinning discs and the performance is good. I know it would be better with SSD.
Would be good if they change the wording to «should», instead of «must» to avoid confusion.
Now it seems Synology can’t run Roon in docker if the NAS don’t have SSD.
Yep thanks, done that before with other dockers. I may well go down that road once it hits release and everything is stable.
Some feedback on the documentation (KB article, Docker documentation on GitHub and RoonServer Configuration Generator) with regards to the volume mapping for /Music:
Read-only
Several areas in the KB article instruct the user to setup a read-only volume mapping to the /Music folder. This is contradicted by the documentation of the container on GitHub, where it is claimed that music imported into Roon via drag and drop will land in that location. Also the configuration generation does not map the volume as read-only.
Multiple locations & subfolders
The documentation of the container on GitHub states:
If your music is spread across multiple locations on the host, mount each additional location at a named subpath under
/Music
When doing this, the subfolders are automatically included in the default Music Folder in Roon, without the possibility of individually enabling / disabling the folder. While this is not necessarily an issue, I do know some users deliberately have subfolders to be able to easily add/remove certain music to/from Roon (e.g. enable seasonal music only around the holidays).
I see 2 ways to resolve this:
-
Map the additional locations to a different subfolder (e.g. /Music2). This was it is not included in the default music folder and can be added and controlled individually
-
Map the additional folders as a subfolder under music as instructed, but include the subfolders under the Ignored paths
Personally, I prefer mapping to a different folder as this is less complex, but I am curious about your thoughts on this.
Any news on that QNAP-specific alternative solution?
Running it on Ugreen DXP4800PLUS with 64GB RAM. Everything seems to work but backup. It is mapped but when it runs or I tried to run it manually, I always get this:
I can restore and old backup from the same location, but backing up to it does not work!
To get ROON running again without a useless restore, all I have to do is to go to Docker on Ugreen and restart Roon project or container.
Backup is mapped in docker compose as - /volume1/docker/RoonBackups:/RoonBackups
Any suggestions from anybody would be very welcome
Hello everyone,
Thank you for all the feedback and questions! I want to jump in and clarify a few points that have been raised regarding the new Docker deployment, specifically around storage and folder mappings.
1. SSD Requirement (“Must” vs. “Recommended”) @Moonshiner and @Arindal, We recently updated the documentation to state that an SSD must be used for the Roon database. From a strict software perspective, Roon will still technically launch and run on a spinning hard drive—it is not a hard block.
However, we changed the wording because an SSD is now our absolute maximum recommendation. As libraries grow and database operations become more demanding, the mechanical read/write heads of spinning disks simply cannot keep up with the constant database churn, which leads to slow performance, UI lag, and a generally degraded experience. So, while you can use a spinning disk, we strongly insist on an SSD for the database volume to ensure stability.
2. Music Folder Workflow @gTunes,
Just to add one more detail regarding your specific workflow and your desire for manual control:
Even with the default /music folder mounted in Docker, you do not have to let Roon automatically scan and import everything inside it all at once.
If you go to Settings > Storage in Roon, you can actually disable the default /music directory. Then, you can use the “Add folder” button to manually select and activate only the specific sub-folders (for example, /music/Newly_Ripped_Albums) that you are ready to add to your library.
This setup allows you to keep your automated robocopy mirror job running exactly as it is, while still giving you the exact manual control you want over what Roon actively watches and imports!
3. Read-Only (ro) Permissions Update @s73nm, regarding the read-only folder mapping: we have officially updated the documentation and removed the “Read-Only” (ro) flag. You need to ensure that your /music folder in Docker is mounted with the default permission levels. Roon requires these default permissions so that the local directory watcher can properly detect file changes when you add or sync new music.
Based on your recent post, it looks like you might be dealing with a corrupted database.
Because database issues require individualized troubleshooting and looking into your specific logs and backups, could you please open a new, separate topic in the Support category? This will allow our team to focus entirely on your issue and gather the necessary diagnostics without getting mixed in with the general Docker feedback here.
We will be on the lookout for your new thread so we can help you get this sorted out as quickly as possible!
Thank you again for testing and sharing your experiences!
Hi @vadim,
This help page (linked below) is contradictory and should be updated …
- Storage: An SSD is strictly required for the Roon database. Your music files can remain on spinning disks.
it is highly recommended that the Roon database be on an SSD instead of a spinning disk.