Autodiscover on mounted network music folder not working

@support @danny

I have Roon core running on a NUC with Debian (8) and music stored on a NAS. Roon mounts the music share fine and playback is stable, but I have to ‘Force rescan’ every time I add albums. There is no automagic

df -i give this output:
root@nuc:~# df -i /mnt/RoonStorage_26c9306a0fbd9d9d62b5678af411ff87cae5bd9f/Music/
Filesystem Inodes IUsed IFree IUse% Mounted on
\\media 0 0 0 - /mnt/RoonStorage_26c9306a0fbd9d9d62b5678af411ff87cae5bd9f

So the cifs mount does not include inode messaging. Is this the reason? The linux based distro on the NAS (readynas Ultra 2) is fairly old, but df -i on the NAS shows normal inode count.

There is a setting that triggers a rescan every 1-2-4-8… hours, but I think ‘Watching…’ is a different mechanism that depends on some sort of real time feedback from the OS.

If I mount the share manually (only with -o guest,rw) inode count shows on the Roon Core NUC. Maybe the lack of inode info on the mount is not relevant? How is this supposed to work?

@ogs: Roon uses Mono’s built in filesystem watcher, which should default to using inotify to watch for changes if it is present in your system. I think the most common reason for missing changes on Linux systems is that your maximum number of inotify watches is set to low, watching a directory tree requires on per file or directory anywhere in the tree.

You can check this by running this command on the NUC:
cat /proc/sys/fs/inotify/max_user_watches
That should print some large number, the max is 524288

Can you be more specific about what you’re seeing here? I’d like to try to fix this if possible. I know that we will skip files/directories if they contain a forbidden character, but having a bad track shouldn’t prevent the rest of the album from coming in.

@ben seems that the watches is set low. I get 8192 here. Very little. Can I edit this file directly? Will it stick through a reboot?
What about the zero inode count over the cifs mount? I can see from logging that Roon mounts the music folder nounix,serverino (and lots of other options…).

I would try the terminal commands for Debian here:

I don’t know enough about your Linux installation specifically to be sure that will work for you. I am confident it is possible to increase the maximum number of watches in a way that will stick through a reboot somehow, I’d try looking for resources from your distribution if the above link doesn’t work.

I don’t think the zero inode count means much, I would at the very least try increasing the inotify limit first.

I’m not shocked that a forward slash or colon would mess things up somehow, some of these limitations are buried really deeply in the OS/filesystem. The forward slash behavior strikes me as a result of our needing to constantly normalize slashes to match the native directory separator, because we operate on so many platforms. I will see if I can reproduce some of these, I’d really like to make our filesystem/storage code as robust as possible. Things should be PITA for us, not for you.

Can you confirm what OS you were running on, any sort of NAS, anything like that?

Thanks @ben I found how to make the change permanent, but I do not think it helped much. How long should I wait for the ‘Watching for new files in real time’ to kick in? Maybe I am being impatient?


I’ve mounted the music folder directly (cifs) and pointed Roon there. Deleted the Roon-mounted location. This mount includes inode messaging. Makes no difference. New files or albums are not discovered. I’ve now re-enabled Roon to mount the music folder. Next I’ll try a few files in a folder on the NUC where Roon core is running. If this works as a ‘watched’ folder in Roon I guess Mono’s built in filesystem watcher does not work with the version of samba running on my NAS. Any thoughts on this?


A local folder on the NUC works for both add and remove. Is there any settings in Mono I can tweak to make it work on the NAS mount?

@ben @support

I tried to mount a share on a windows (7) PC too. It’s not working there either. The only thing that works is a local folder on the Roon Core. This leads me to think that the message “Watching for new files in real time” is wrong. When files are not local the text should change to reflect this. Or maybe a button should appear with the text “Rescan now…” as the watch process does not work when music files are located on a network mount.
This is a known issue with network mounts (NFS too, not just CIFS) so is not a Roon issue as such, but the wording should be corrected.
I have not tried ROCK yet as I doubt my NUC is the right type (it’s probably too old) so I do not know if it works there. @danny?

You may be right. The “Watching for new files in real time” message clearly indicates what Roon wants. The fact that this does not happen points to an error. I also used JRiver and did not see this. Files have been stored on the same NAS for years. I have not tried running Roon Core on Windows. Maybe it works there?

This sounds like a problem I’ve seen before with a Mac system watching a NAS share, in which we only get change detection notifications when a directory is created/deleted. That means that we catch some random fraction of the tracks in the directory, and then don’t notice the rest. That also explains only seeing a couple tracks in the “skipped files” thing, those would be the files that were partially there when the scan cam through from the directory created notification. I had thought this was a Mac only problem, but the symptoms match really well. I have an idea of what I’d like to do to fix it, but there are some details to work out and as always I can’t comment on schedules.

I think the reason your resets fixed the problem is that we rescan everything on startup. You could confirm this by trying the “force rescan” button in settings -> storage -> 3 dots menu for the watched folder.

Roon is supposed to automatically rescan all network watched folders on a timer. It defaults to every 4 hours, but I currently have a ticket to fix a bug where we only seem to scan one network folder instead of all of them.

There aren’t any Mono settings you can change that will do anything here. I’d like to try to replicate your setup and see if I can see this fail on my end. I’d like as much information as possible about your OS on the NUC and the NAS make/model and Samba settings. In particular:

  1. Linux/Debian version on the NUC
  2. The NAS is a ReadyNAS Ultra 2? Can you get me the Samba configuration file? I’m guessing that probably lives at /etc/samba/smb.conf

I am somewhat confused, because I believe I’ve seen change detection work watching network shares from a Linux system, but I am now finding things suggesting that it should just never work. I think you are probably also experiencing our re-scan timer bug, hopefully I can fix that as well.


1.: uname -a: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) x86_64 GNU/Linux. The NUC is a DC53427HYE. mSata for OS, 2x4 Gig ram.

2.: Yes a ReadyNAS Ultra 2. Latest firmware (4.2.27) smb.conf sent by PM.
uname -a: Linux #1 SMP Wed Aug 20 11:41:34 PDT 2014 x86_64 GNU/Linux