Docker images for Roon [Please Note: Using Dockers and VMs isn't supported by Roon]

Hi guys,
I’ve installed Roon via Docker on my Terramaster NAS (F2-423) with a little difficulty but I managed to make it work, (I used this version: Docker) and it worked well for more than 60 days.

This week I needed to restart my NAS and my Docker lost the images that were running (MinimServer and Roon) I managed to get the minimserver to run, the Roon I can install and run but it no longer finds my folder containing my music (media folder) …
It finds a media folder in files, but when I access the folder it is empty, my music is not there.
and when I try to add a network share it also gives an error and cannot find it.

Has anyone ever experienced this? Any ideas that could help me?
thank you very much!!

Did you map your volumes correctly?

The folders you see in your screenshot correspond to the folders in the docker image. These must be mapped to folder on your NAS. In particular this is the case for the “app”, “data”, “music” and “backup” volumes. The “app”, “data”, and “backup” can be mapped to sub folders of a dedicated “Roon” folder on your NAS. The “music” volume should be madden to the folder on your NAS where you music files are stored.

You can do this mapping on the volume tab of the Docker app on your NAS when setting up a new container, or in a docker compose file.

Hi Sven, thank you for your answer!
I think I did it right, but still not working…
The roon server is runing, but I’m unable to set my library.
I’m running this command on Putty:

docker run -d
–net=host
-e TZ=“America/Sao_Paulo”
-v roon-app:/Volume1/Roon/app
-v roon-data:/Volume1/Roon/data
-v roon-backups:/Volume1/Roon/backup
-v roon-music:/Volume1/media/music
steefdebruijn/docker-roonserver:latest

I’he created the folder Roon on my NAS and my music folder is called media…
I still unable to choose my library, Roon creates this specific folders in the roons root folder, it looks like it can’t find the root of NAS, only the roon root folder…

As you can see below, there is a folder called volume1 on the roon root folder, but my files are’nt there…

Any suggestions what I’m doing wrongly?

P.S- Sorry, I don’t know if I managed to make myself understood, I’m not a native english speaker and I’m noob in this docker things…

Hi @Milton_Junior,
It looks like you may have incorrect definitions of your volumes.
Have a look at the following post for an example of a docker compose:

In your case I believe you should have something along the lines of
-v /Volume1/media/music:/music

Now it worked… crazy stuff…
worked with this lines:

docker run -d
–net=host
-e TZ=“America/Sao_Paulo”
-v roon-data:/data
-v roon-music:/music
-v roon-backups:/backup
-v /Volume1/media:/media
steefdebruijn/docker-roonserver:latest

A question for @SvenM and @patrick_mccarthy.

Thanks for sharing what you both did to get Roon onto a dedicated vlan. I might be missing something but I don’t understand how what you describe relates to the rest of your network configuration.

I’ll use Sven’s 192.168.50.x network to explain what I’m asking.

It looks to me that the docker command you used to create the network stands up the network, a DHCP service handing out 192.168.50.x addresses in the range you specified, and assigns 192.168.50.1 to the gateway on the NAS.

I don’t understand how this relates to your existing UniFi setup. In my case, I already have a UniFi vlan stood up (coincidentally) on 192.168.50.x. All of my music related stuff including Roon, endpoints, RoPieeee, etc. are already on that vlan. Is that what you have as well?

I hope this makes sense…I’m just not getting how your UniFi config relates to all of this.

If I can pull this off, it’ll let me decommission my ROCK on NUC, which would great. Thanks!!

Yes. On my Unifi network, I’ve defined a dedicated audio VLAN with subnet 192.168.50.0/24. I typically reserve 192.168.x.2 through 192.168.x.31 for services and keep 192.168.x.32 though 192.168.x.63 for “clients” with a static / manual IP, leaving the rest of the subnet for DHCP. So for this VLAN I have:

  • DHCP range 192.168.50.64 through 192.168.50.254
  • Addresses 192.168.50.2 through 192.168.50.31 are reserved for static / manual IP address

Within the range of fixed IP addressed I’ve defined the MacVLAN for the NAS to allow IP addresses in the range 192.168.50.16 through 192.168.50.31 (192.168.50.16/28). 192.168.50.16 is assigned to the Roon container in my Docker compose. Other addresses in the range are used/available for Roon extensions running in their own container, also assigned manually in their Docker compose.

On my switch, I have a port configured for the audio VLAN, which then connects to the “LAN 6” interface on my NAS. This is one of the two 10Gb port on an add-on network card.

All of this makes perfect sense now. Thank you!

This explains your ethernet specification as well as why it differs from @patrick_mccarthy’s. I’ll use one of the four ports on my RS1221+ … I wish I had a use case for a faster network ports (or even link aggregation) but I just don’t :slight_smile:

I should have time to play around with this over the weekend if not sooner.

It’s a good time to move over to using Docker compose, too. It’s been more than a couple of years since I wrote this: Walkthrough : Roon in a Docker container on Synology DSM 7

Maybe I’ll update it some day.

1 Like

Before implementing the Docker MacVLAN I had link aggregation using the 4 ports of the NAS in a single bond. I got the additional network card to have more flexibility and simplify the transition. I replaced my bond with a single 10Gb connection, used the 2nd 10Gb for Roon, which is overkill, and I’m using the other ports for other services in their own VLAN.

The difference between men and boys is the price of their toys… :wink:

Hope that’s a binary, and not a linear, function. I’m fine being a man but if it’s linear, I’m an old, old man. I like expensive toys :slight_smile:

I’m hitting an issue getting this going. I’ll work on debugging later today or tomorrow but in case either of you have hit something like this, I figured I’d ask.

The short story is that when I attempt to create and start the Roon container, I get an error “failed to create the maclvan port: device or resource busy”

I can’t figure out why. Here’s what I did.

I created the Docker network as:

sudo docker network create -d macvlan -o parent=eth1 --subnet=192.168.50.0/24 --gateway=192.168.50.1 --ip-range=192.168.50.48/28 macvlan_roon

That allots 192.168.50.48 - 192.168.50.63 to Docker. My UniFi DHCP range starts at 192.168.50.64 and I’m not using the Docker range for anything else. So no issues there.

This binds to my LAN2/eth1, which is connected up to a switch and the port on that switch is correctly set to the right vlan - I can see that LAN2 picked up an address in the vlans range (currently a DCHP allocated address but I’ll change that later).

Static route created as advised:

Here’s my compose:

version: "3.3"
services:
    roonserver:
        image: steefdebruijn/docker-roonserver:latest
        container_name: roonserver
        restart: unless-stopped
        hostname: roonserver
        volumes:
            - /volume1/docker/roonserver/app:/app
            - /volume1/docker/roonserver/backup:/backup
            - /volume1/docker/roonserver/data:/data
        networks:
            macvlan_network:
                ipv4_address: 192.168.50.48
        environment:
            - TZ=America/Los_Angeles

networks:
    macvlan_network:
      external:
        name: macvlan_roon

Everything looks correct to me. Any thoughts? Like I said, I’ll play with this later if you guys don’t have ideas.

Thanks again for getting me started on this!

I did not come across this issue. One thing I am noticing is that I also added a static route on the Synology for my “regular” vlan. In my case this is on LAN 5. This to ensure that traffic that is not related to the Roon vlan is sent out via the correct port.

I figured it out.

I had Virtual Machine Manager installed which requires (and enables) Open vSwitch. That was the issue - maybe I could have gotten the Docker network to work by parenting it to the Open vSwitch equivalent of eth1 (which would have been ovs_eth1) but it doesn’t really matter because I’m not using VMs on this device at the moment. Cleaning up and uninstalling Virtual Machine Manager got the Docker network working.

No more time to play now but I’ll play around more later.

I did just add the static route you described for my primary network but I’m not sure it was necessary to do so.

I also made sure the primary network was identified as the default gateway here:

1 Like

I should have added…

This does work. This instance of Roon is up and running on the expected IP and is visible from client devices. Really appreciate the help getting this going!

1 Like

That is awesome gTunes, do take a look at what SvenM is saying regarding the static routing on the NAS - otherwise synology tries to “help you” and will expose everything on your music vlan on the other subnets and visa versa…

regarding the MACVLAN - in my early setup I used portainer’s UI to create the macvlan on my synology - and kept tweaking it as i learned - the problem became i some how corrupted the synology nic stack for docker – the solution was to run an ssh command to reset it all - worked great. Then I used SvenM’s ssh process to create the vlan. BUT NOW, with portainer (and/or the new synology container UI for compose) I use a compose script to manage my macvlans (no more needing to SSH).

below are some helper KB stuff i kept back when i was more of a nubby than now:

====================
fix docker networks in synology -

sudo i

to be able to get to the @docker sub folders

==============================
my compose file to create a macvlan via the UI in synology or portainer - the alpine image never starts

#-sorry the thread here messes up indenting - hopefully on copy/paste it comes back
version: ‘3.3’
services:
dummy:
image: alpine
networks:
mvlan_ent20_eth4_lan5:

networks:
mvlan_ent20_eth4_lan5:
name: mvlan_ent20
driver: macvlan
attachable: true
driver_opts:
parent: eth4
ipam:
driver: default
config:
- subnet: 10.10.20.0/24
ip_range: 10.10.20.208/28
gateway: 10.10.20.5
aux_addresses:
root: 10.10.20.208
shim: 10.10.20.209

image

Thanks, @patrick_mccarthy.

For stuff like setting up the network, I actually prefer ssh. I didn’t try the compose approach to setting up the network - it was much easier for me to just do that via command line.

Thank you for the static route tip. Based on the earlier posts from you and @SvenM, I set that up before standing up the Roon container. I haven’t run into any issues. I wouldn’t have guessed to do this so I appreciate you figuring it out first.

My issue really was the Open vSwitch enablement. Synology enables it automatically when you install their VM package. You can’t turn it off unless you remove that package. It may be possible to set up a Docker network the way we are doing it with that package installed, and Open vSwitch enabled, but I’m not using VMs right now and it’s easier to just leave it off. For what it’s worth, the reason I installed VM manager in the first place was to play around with the idea of running ROCK in a VM.

Thanks again for doing and sharing this work. Based on this, I’m probably going to repeat it all for my IoT subnet and move a few additional containers over. The fewer physical boxes I have, the better!

Hey gTunes,

Yeah, that is exactly what I have done. I use the synology surveillance station (ok, just playing around - us it to watch the dog when we are out) - it has its own subnet and dedicated static route and that network if fully isolated via pfsense and my unifi switch/wifi. Closed circuit with no internet. thus, static routes are paramount on synology so the stupid NAS doesnt expose my subnets on the camera subnets by default.

at the moment, I have three subnets on my synology (main, entertainment, surveillance) and docker has some bridge networks and the macvlan for entertainment… works great UNTIL i tinker - no SLA at this house.

That’s interesting, @patrick_mccarthy. I used to run Surveillance Station with cameras whose firmware I didn’t trust. I wasn’t able to come up with a plan for isolating them. You solved that.

Today, I’ve gone all in on UniFi, including Protect and UniFi-branded cameras, which are the only option. I don’t bother isolating them.

I do, though, have an IoT vlan with all kinds of sketchy and non-sketchy stuff. Aqara, Lutron, Somfy, Rachio, Ecobee, Flair, Meross, Peloton, Tonal, Home Assistant + add ons/extension, etc. I also have a little Ubuntu box running Portainer and a number of containers. Nothing very resource intensive and my Synology could easily host them, I just haven’t figured out how to do that while keeping them on the IoT network. Now I know how! :slight_smile:

In case you live in the Apple ecosystem…one of those containers is hosting Scrypted. Scrypted is a super cool piece of software that allows you to connect up many surveillance cameras to Apple’s ecosystem as if those cameras were HomeKit certified and supported HomeKit secure video. If you use Apple Home/HomeKit at all and you’re interested in connecting your Surveillance Station cameras up to it, you might be able to do that with Scrypted while still maintaining complete Surveillance Station capabilities.

Anyhow…fun conversation. Thanks again for all the pointers! Always fun to talk about the silly stuff we do in our homes!

I reserve the right to be wrong about this but I think I’ve got UDP proxying working such that endpoints (including Macs, phones, etc.) can be on my “main” network instead of my Roon network.

I did this with udp-proxy-2020 running in a Docker container on Synology alongside Roon. You do have to be willing to give this container access to the equivalent of my “main” network. I’m willing to do it.

Here’s the full story and what you need to do. My relevant networks are “roon” and “main”.

  1. If you have a firewall, make sure you allow all traffic from main → roon but not the other way around
  2. On your NAS, define macvlan networks for both networks (main, roon). I didn’t previously have a need for a macvlan for main, but you need it for this
  3. Deploy udp-proxy-2020 as a Docker project using the compose below

Before you deploy this compose, adjust it as follows:

  1. Change the TZ - this helps with viewing logs
  2. Replace the instances of “mavclan_roon” and “macvlan_main” with the names of your virtual networks
  3. Replace the static ip addresses 192.168.50.49 and 192.168.20.48 with available addresses from within your macvlan ranges
  4. Replace eth0,eth1 with the names of the physical ethernet ports on your NAS that correspond to your equivlants of my roon and main network ports

That’s really it.

Hopefully someone finds this useful. I’m super happy to have this working.

version: '3.7'

services:
  udp-proxy:
    environment:
      - TZ=America/Los_Angeles
    image: synfinatic/udp-proxy-2020
    container_name: udp-proxy-2020
    restart: unless-stopped
    networks:
      macvlan_roon:
        ipv4_address: 192.168.50.49
      macvlan_main:
        ipv4_address: 192.168.20.48

    command: udp-proxy-2020 --port 9003 --interface eth0,eth1 --cache-ttl 300

networks:
    macvlan_roon:
      external: true
    macvlan_main:
      external: true
1 Like

@gTunes this is very interesting and I am going to try it…I can do most things via main already…just a few nits that don’t work…thanks for posting this setup

Patrick

1 Like

I had a similar issue, except I noticed on setup rather than months later. Lucky i CHECKED. the /volume1/docker/roon folder was not populating anything when using. I knew this wasn’t right.

The default docker compose file listed here GitHub - steefdebruijn/docker-roonserver: RoonServer downloading Roon on first run

Lists volumes like below

 volumes:
      - roon-app:/app
      - roon-data:/data
      - roon-music:/music
      - roon-backups:/backup

It is easy to mess this up the wrong way around and end up with /app and /data going into synologys /volume1/@docker/volumes instead of into your /volume1/docker/XXXX

The github should probably specify this a little better for people who don’t work with docker everyday. Simply something like the below would have fixed any doubt over mappings.

 volumes:
      - YOUR APPLICATION DATA LOCATION:/app
      - YOUR ROON DATA LOCATION:/data
      - YOUR MUSIC LOCATION:/music
      - YOUR BACKUP LOCATION:/backup

Then it’s obvious which. Its very easy with that doco to accidently do it backwards and end up with something like this below which ***s it up as its backwards

    volumes:
      - /volume1/docker/roon/app:/roon-app
      - /volume1/docker/roon/data:/roon-data
      - /volume1/Media/Music:/roon-music
      - /volume1/Data/Backups/RoonBackups:/roon-backups

This will *** you up and lose you data if your not careful.

To FIX, in my case I changed to

volumes:
- /volume1/docker/roon/app:/app
- /volume1/docker/roon/data:/data
- /volume1/Media/Music:/music
- /volume1/Data/Backups/RoonBackups:/backup