RoonServer on Synology Virtual DSM cannot add Music folder [Under investigation - "Open vSwitch"]

I was recommended by Synology support to install RoonServer on Virtual DSM instead on the host machine. (That’s another story, they found that RoonServer package use inotify watches over 8192 limit and cause some system demon fail to run.)

I success to install and run the RoonServer on vDSM, however I cannot add any music path to it, it always shown “UnexpectedError”, want to know if it can be fixed?

same result using smb share path:

my host NAS: Synology DS3617xs, DSM 6.1.4-15217 Update2, default 16Gb RAM
created virtual DSM by image file “DSM_VirtualDSM_15217.pat”

The music files are stored in the host, since the virtual DSM act as a individual NAS and storage space is separated with the host too, it cannot add music from host like local path.

But I’m sure the vDSM can communicate with the host, I can ping the host in vDSM SSH shell and also can setup backup task with host’s share folder by rsync service.

What are the IP dresses of your DSM and virtual DSM?
I guess your main DSM is, right?

Unfortunately I have no capable Synology machine here to test/reproduce the virtual DSM behavior…

Your’re right, the main DSM IP is, the virtual DSM is;

Do you think if it may help if I give you the vDSM admin password and let you connect it to test?

As there are more factors involved than just the vDSM, it would not be of any help.

I am trying to rule out some criteria:
Is it possible to test if you can connect to your music share, when the core is installed on a different device?

If this is also not possible, I assume it has something to do with the smb settings on your Synology.
Can you post screenshots of your smb settings on your main DSM?

I have installed Roon core on my iMac, MacBookPro and SurfacePro4 pervious, all can connect and play music with the file stored in the main DSM as well as RoonServer on NAS.

Recently my Devialet ExpertPro has sent back to factory for upgrade OS Board so in this mean time I use AppleTV as output device. Pity that RoonServer on main NAS cannot detect my AppleTV but Roon core on iMac and vDSM can, seems strange to me (it would be great if this problem being fixed, should I open another topic for this?)

So in my situation, each way has it’s own problem, I’m using iMac as core that can connect AirPlay, cons is I need to power on my imac each time when I want to just play music.

Here is the screenshots of my smb settings in main DSM: (sorry that I’m using Chinese interface)

and the path on iMac: ( “nick” is my main DSM’s name, IP:

I have another information see if that help.

When I test the main DSM inotify watches usage, it can shown raise from 13 to max 8192 immediately when I startup the roon server:
watches on main

However when I do the same in vDSM, it shown nothing.
watches on vdsm

I don’t know if the virtual DSM do not have inotify for implement so that cause the unexpected error when adding path in Roon?

what do both DSM output when you execute (via ssh)

both shown “unlimited”

Is it possible to mount the share via ssh in your home directory of the virtual DSM?
(enter these command line by line…)

mkdir test
mount -t cifs -o username=$smbuser,password=$smbpass // test
ls test

if this worked you can unmount the share again by typing
umount test

This seems also weird to me. How is the synology connected to your LAN? Is there anything special about it (e.g. Link Aggregation, multiple IPs, Jumbo packets… etc).
What other network gear is involved?

seems it don’t let me mount it this way:

mount not support

Firstly I bond the main DSM network port 1-2 in SLB mode and manual MTU 2000, after I found that the vDSM can see my AppleTV then I try to unbond it and use identical setting between two DSM except the IP itself, network port 1 assign, MTU default, same gateway and subnet mask.

But they got the same result: main DSM not see airplay but vDSM can, very weird.

I even try to uninstall the main DSM’s roon server and deleted all files in RoonServer folder then re-install again to prevent any old stuff cause the problem, but same result.

The vDSM use my main DSM’s physical network port3 as it’s virtual network port, and all the cable connected to the same network switch without special setting.

Nick - You are not the only one having this issue; some others including me are having the same issue. I have a media server which was working fine and suddenly lost the link to Roon. Now when I try and map the shared folder, I keep getting the same error message that you are getting. Roon support is aware of it and is running diagnostics.

Back to the first cause, Synology support told me they will try to contact Roonlabs or you to discuss the inotify issue, may be suggest some method to replace the use of inotify watches, if this can be change then I don’t need to take care the vDSM issue.

That would be good news to me since I’m not the only one and Roon support aware of it that means we may have solution later.

I checked the notify_inode_mark on my Synology. It is the same as with your NAS.
I asked the Roonlabs devs and they told me this is expected and normal.
Is there any indication that makes you believe this is causing your trouble and the described issue?

I help Synology beta test the Virtual Machine Manager last few weeks and got some system unstable issue with the new virtual DSM, the Synology devs study my case and a bunch debug logs they concluded that RoonServer package used up all inotify resources of main DSM which caused some system demon fail to start and bring the system hang and unstable. So they recommend me to uninstall the RoonServer package; they don’t agree to increase the limit of inotify watches as a good solution because it may still being exhausted afterward. Or I can install the RoonServer in the virtual DSM which will not affect the main DSM even when the resource of vDSM exhausted.

When the inotify reach limit 8192, I try to add one watch by:

tail -f /var/log/messages

The shell will prompt error telling that inotify resource exhausted and cannot be used. That means any other process need inotify will fail too.

inotify exhausted

This issue not only affect Synology but also Qnap and Linux system.
Seems some discussions between Roon users who have folder update issue also caused by this resource exhausted? I’m not sure.

But at least causing the main system unstable should not be treated as “expected and normal” as Roonlabs devs said. Most of our NAS system is not dedicated for only RoonServer to run. Hope either Roonlabs or Synology devs could co-work and found out a better solution.

As a end user, I only need the system stable and function well, pity that my main DSM cannot see my AppleTV and the vDSM cannot see my music folder, both of them not function well.

Roon watches your file folders to see if any files changed or any directories changed. If you point it at a lot of files it’s going to use an inotifywaithandle per file.

We usually set the kernal limit of inotifywaithandles to somewhere around 1 million.

I understand the problem at hand I just as just a resource issue. Upping this value on Linux is harmless and easy. The entire point of inotifywaithandles is that they are much lighter weight then file descriptors.

Thanks Danny, then I’m relieved to raise the inotify watches max value.

Besides, may I have your recommendation or hints to fix the titled problem, that I cannot add music folder to vDSM, nor cannot see airplay for the RoonServer on main NAS?

I already tried increasing the fs.inotify.max_user_watches by putting it in the sysctl.conf yesterday and it solved the issue with insufficient inotify-inode handlers.

Regarding the AppleTV/Airplay issue: I still think it is a networking issue. As you were using interface bonding before, I assume there is a managed switch involved. If true and possible, could you try to simplify the setup, by just using a simple unmanaged ethernet switch with default ethernet settings on the synology (like in your previous test). Then restart RoonServer after these changes were performed. This should only be temporary and could help identifying the cause.