Roon Server has a problem finding music files on smb share from synology

Core Machine (Operating system/System info/Roon build number)

Nuc10i7, Ubuntu 20.04 LTS server no gui, ssh only, RoonServer latest version, new clean install/nuc.

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Cisco SG200-24 port, all ethernet, fixed ip’s, local DNS.

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Sotm SMS-200, dietpi client, audiolinux client
All clients connected via ethernet to SG200, NO wifi used

Description Of Issue

I have my music library on a Synology DS918, it’s a smb share which contains only my music library.
My library is split in 3 folders within this share.
When I do a rescan of my library roon constantly finds new files, even if I don’t add anything new for a week or so. So the number of tracks in my library is alway different, 90995 now, I hit rescan and it goes up to 100000 something. Another rescan 98000… Auto rescan is set to 4 hours.
It’s also really dropping albums out of the library, they’re there on the share for sure.
I did a tail -f on the roonserver log while rescanning and I can see the roonserver finding ‘new’ stuff that’s been there for at least a year or so, and on the same time dropping others. After a rescan there are always a lot of files in library maintenance / clean up deleted files (anywhere between 50 and 2500 at the moment).

Also tried mounting the synology share to /media/music on the nuc and let roon watch that folder, same result.

As a last resort I started with a new database, deleted the old one from the nuc and let roon do a scan overnight, … with the same result.

I’m out of options to fix this issue, anyone from support?


When I used my Synology NAS that way (it’s now a backup only), I did have that problem at some point but it got fixed by tweaking various settings, trying to recall what. My core is like yours, NUC with Ubuntu, currently 20.04 but something earlier when it was using the NAS for music. Just looked at my Synology File Services advanced settings, I have SMB3 as maximum SMB protocol, SMB1 as minimum SMB protocol, enable opportunistic locking checked, and allow symbolic links within shared folders checked. I tested this recently as the music storage for another core NUC I was experimenting with, everything worked.

Well,… put the same settings in my synology, no luck, still the same issue.
In the meantime I’m trying to ‘understand’ what’s in the roon-server logs. Roonserver is connecting via smb v2.1 for sure. I also see a lot of upstream errors and stuff like this line:

08/09 11:44:39 Debug: [broker/filebrowser/volumeattached] found newly mounted drive at /run/user/1000

I for sure didn’t attach a new drive, the disk in the nuc is a lvm disk, is this causing roon to fail??

And a rescan allways throws a lot of these:

08/09 11:48:49 Trace: [analysis] analyzing trackid=53792562 url=/mnt/RoonStorage_f4b66eb416625da3636b6ac77498fd4fe7936409/02 - Download/Norah Jones/Norah Jones - Feels Like Home (24-192 HDtracks)/01-Sunrise.flac
08/09 11:48:55 Trace: [push] restarting connection (Unable to read data from the transport connection: interrupted.)

Overnight I did a copy of my music to a win2016 server, just share’d the folder everything was in with a dedicated new user, swapped the storage location by disabling, edit it and enable it again in roon.
Guess what: the same ‘feature’ is still there, roon is consistently dropping albums which are there for sure (and have been there for a year or longer), and rediscovering them when I do a rescan (and at the same time dropping others). So I have rule’d out the synology.

I’m waiting for someone from support to read this, seems to be something serious.


This afternoon I decided roon-support is a nine to five business apparently, so I took another shot in solving this. Attached my backup music disc to the core via USB, mounted it to see if I could read this disk.
Then did the disable, change, enable storage thing. Also unmounted the old storage on the core which roon doesn’t do by itself when you change the storage location on a linux core. Mounts are still there and functional in /mnt
Same issue happened within 10 minutes, roon dropping albums out of the library during a scan and finding them again with a rescan and at the same time dropping others. This time I was lucky to see it happen in the library overview page.
So I decided to follow a different route, setup Win10 on the old NUCi5 (together with 16Gb Ram and a SSD). Installed roon-server on this old NUC and currently scanning my library on the synology.
Also decided NOT to import the old database to rule out corruption.
Will take another couple of hours to finish, so I decided to take a beer and start listening to some music.

Will add to this thread the result of this core-switch tomorrow.

There’s another source for problems like this, documented somewhere, don’t have the time to search for it now: having two SMB/CIFS mounts for the same share on the core machine. For example, if your core machine is set to mount the share directly on a local mount point, then giving Roon the SMB share as a its music storage will cause problems because Roon will create its own mount point – if this is the case on your system, you’ll be able to see it with df. to get this right, two options:

  1. Do not have a direct mount of the share on your core, and use smb:… when specifying the music storage folder on Roon
  2. Have a direct mount on the ore, but then use the local mount point as music storage folder on Roon

Either way, you’ll end up with just one Linux mount of the smb: share and the problem will be avoided.


Indeed i’ve read the thing with 2 mounts for the same share also a while ago somewhere, can’t find it at the moment. That’s why I checked (and deleted) the obsolete mountpoints in /mnt.
This didn’t solve the problem, even after a restart (or two).

For the moment I’ve installed win10 LTSC 2019 on my core, and guess what, that works. There is also no need for a rescan (or a scheduled one). Roon picks up newly added music immediately.

So my situation is still exactly the same as my openingpost but now the nuc10i7 is running windows10.

I’d like to revert this to just a simple linux box, @support: which flavor of linux do you recommend?
Or is there a another solution for my problem?


I don’t think that’s enough, you’d need to remove the relevant entries on /etc/fstab as well. You can check with df whether those mounts are still active, anyway.

I recently re-created a Roon server from scratch on an older NUC as a backup to my main server. It’s a NUC6i5SYB with an 8GB DIMM and 120GB M.2 SSD. Ubuntu Server 20.04. Installed RoonServer from the standard script after adding ffmpeg and cifs-utils. Music library is on my backup Synology NAS, which I specified on the Roon Settings>Storage page. It works.

Hi @Edwin_Muskee,

Thanks for running the Windows test while your case reached our queue.

So just to clarify here, the issue occurred when using your NUC on Ubuntu, but not on Windows 10?

This sounds like it could be related to the OS in use in that case, if you try to use Ubuntu again, but have locally attached HDD shares, do those also exhibit the same issue?

If you read my post’s above (third one from the top), I tried that one allready. With the same result unfortunately. I agree it could be something with ubuntu 20.04 but what?
Since I’ve installed win 10 on that nuc10 I can’t test this anymore. I was planning to do a ubuntu install on my old nuc. Is it possible to get a temp roon license for this test. I don’t want to mess anymore with my current install/database?

Hi @Edwin_Muskee,

You are free to transfer your Core over as many times as you want between different PCs, the limitation here is that you can only have one active Core at a time.

You can certainly install Ubuntu on the other NUC and test this further with one license if you wish.

This evening I did a quick test.
Installed a NUC8i3 with Ubuntu 20.04 LTS, server no gui, only ssh-server. Fixed IP4, IPv6 DHCP
sudo apt-get update, sudo apt-get upgrade
sudo reboot
sudo apt-get install cifs-utils
sudo apt-get install ffmpeg
After this another reboot to start with a completely upgraded etc system

Then did a roon-server install:
$ curl -O
$ chmod +x
$ sudo ./

Roonsrv starts, connect via roon client on my main pc.

Swap license to test server

Add my music library, and then ‘the fun started’

My original number of tracks library info from my win10 box:

First scan on the ubuntu box after adding my library:

89772 tracks found, that’s 1637 short…

Then I did a rescan via the storage tab:
Now roon manages to find 91409 tracks, which is the correct number from my library?

Then I hit rescan again a couple of times.


And the number of found tracks magically rises to 92271 for instance. I’ve seen it as high as 96000 something. Every time I hit rescan there is a different number of tracks in my library and roon is also displaying album’s as new which it find’s again after rescan number x.

To be clear, this is a clear fresh install by the book, no network mounts made by myself in /mnt or other strange things.

df-h on the ubuntu box displays:

So there is only 1 mountpoint present.

I’m stuck what’s causing this. Will give it another go on ubuntu 19.x somewhere the next days.
Maybe someone from @support can do a similar test also.

kind regards,

Did the same linux install on my NUC8, same update, roon install etc as above with ubuntu 18.04.5 LTS.
THAT WORKS as intended with roon-server.No more different numbers of tracks when rescanning.

Short Conclusion: roon-server does not run properly on ubuntu 20.x at the moment!
Why: no clue, has to be something within the roonserver application or associated libraries. This is something for your development team to figure out I guess?


It works properly for me, so current RoonServer and Roon libraries work correctly with Ubuntu Server 20.04 LTS for some setups, which suggests there’s something else different in your setup.

@support, Would you mind sharing you’re way of installing. Server or desktop version, gui or no gui. LVM disks yes or no.
I did a basic install as usual for a server on a nuc8, nothing fancy and it didn’t work. Ubuntu 18 exactly the same way of installing works.
Did you try it in vmware or any other hypervisor?


(I don’t have access to that box right now so doing this from memory) I installed Ubuntu Server 20.04 LTS from USB stick on an oldish spare i5 NUC with 220GB internal M.2 SSD to serve as a backup in case I bork my main fanless NUC (also Ubuntu Server 20.04, NUC7I5DNHE, 120GB M.2 SATA SSD, 4TB internal Samsung SATA SSD). No GUI, just plugged my HDMI monitor and a USB keyboard for the install. No LVM, just the default partition of the internal SSD. No hypervisor. However, I think I updated the NUC BIOS from the boot screen before making it boot from the USB stick with the Ubuntu Server image.

Hi @Edwin_Muskee,

Which version of the kernel did you use? Your symptoms sound oddly similar to this issue on Audiolinux:

Had to swap the ssd back first…
uname -r tells me 5.4.0-42 generic for ubuntu 20.04 LTS server, minimal install, no gui, only ssh server.

I’m also aware of the audiolinux problem’s. That’s why I went for ubuntu 18 LTS at that time.

It seems there is some kernel related issue going on at the moment. Maybe @noris can create some sort of list which kernels he tested and found ok?

Audiolinux (which is arch linux) kernel 5.6.19-rt11-1-rt solves this issue, see the other thread above.
So there’s definitely an issue with this roon version and the linux kernel. But that’s something for development to have a look at. Didn’t test it on my ubuntu disk in my nuc10 but I reckon this will give the same result.

Hum… I have Roon 610 on Ubuntu Server 20.04.1 LTS, kernel 5.4.0-42-generic,
NUC6i5SYB. It seems to work with a Synology share, although I see the following on the logs several times/day:

CIFS VFS: Close unmatched open

However, this is my backup server, which I don’t use much, so it could be I’m just seeing the worst behavior because of light use. My main server has the same OS, but a local SATA SSD instead of a file share for music files.

TL; DR There may be something besides Roon and Ubuntu version that triggers the problem others are seeing.

Hi @Edwin_Muskee,

It looks like you can find a list of the SMB changes made to kernel versions here:

According to the Audiolinux thread, it sounds like Kernel 5.6.10-rt5-2-rt or higher solves the issue:

Ultimately though, if the issue is solved on newer kernels, it seems like it would be a erroneous hardware interaction introduced in 5.X and updating the kernel version to the latest would be the simplest way to resolve this issue.

I’ll talk to the team to see if we can update our Linux Docs so that users are aware of this issue impacting certain kernel versions before installing.