· Yesterday, I migrated my Roon Core from QNAP OS to a Docker container. Since then, Roon no longer detects when I add new albums or move folders within the watched directories.
Interestingly, if I restart the Roon container, it detects the changes. However, it’s not practical to restart the container every time I add music.
What could be wrong with the automatic monitoring?
This is a common hurdle when moving from a native OS installation to a containerized environment. When Roon is running natively on QNAP, it has direct access to the kernel’s filesystem notification system. In a Docker container, that communication link is often restricted or broken.
The issue almost certainly lies with inotify, the Linux kernel subsystem that notices when files are changed. Here is why your automatic monitoring has likely stopped working and how to fix it.
The most frequent cause is that the host (your QNAP) has a limit on how many directories it can “watch” at once. Every folder in your music library requires one “watch.” If your library is large, you may have exceeded the default QNAP limit.
Because Docker shares the host’s kernel, it hits this wall immediately. You can check and increase this limit by SSHing into your QNAP and running:
To check the current limit:cat /proc/sys/fs/inotify/max_user_watches
To increase it (e.g., to 524288):sysctl -w fs.inotify.max_user_watches=524288
If this works, you'll need to make the change persistent by adding fs.inotify.max_user_watches=524288 to your /etc/sysctl.conf file on the QNAP host, otherwise it will reset on the next reboot.
With that, how are the folders mounted to the Docker container?
If you mapped a local QNAP path (e.g., /share/CACHEDEV1_DATA/Music) directly to a path inside the container (e.g., /music), inotifyshould work, provided the watch limits mentioned above are high enough.
If the Docker container is accessing the music via an SMB or NFS share (even if that share is hosted on the same QNAP), inotify will not work. Network protocols do not pass filesystem change notifications to the client in a way that Roon can use for real-time monitoring.
Ensure your Docker Compose or run command uses direct volume bind mounts rather than mounting network shares inside the container.
Also, sometimes the Docker daemon restricts the container from “subscribing” to kernel events for security reasons.
Try running the Roon container in Privileged Mode. In QNAP Container Station, this is usually a toggle in the advanced settings of the container.
Ensure the User ID (UID) and Group ID (GID) passed to the container have full read/write permissions to the music folders. If the container can't "see" deep into the subfolders, it can't register watches for them.
Let me know if any of the above help, thank you! 🙏
Thanks for your advice.
To be honest, it’s a bit over my head right now, so I’ll need to do some studying.
I actually followed the instructions in this link, but…
Numbers of folders is 151310 on my QNAP. (find . -type d | wc -l)
The result of ”cat /proc/sys/fs/inotify/max_user_watches” is 262144.
Trially I have done “sysctl -w fs.inotify.max_user_watches=524288” but detection still does not work.
Thank you for providing those details. Since your library contains over 150,000 folders, but your music is currently added as a network share, the automatic monitoring will not function. Network protocols like SMB or NFS do not pass the necessary filesystem notifications to Roon for real-time tracking.
To fix this, you must change how the container accesses your music:
Use Direct Bind Mounts: Instead of adding the folder as a network share within the Roon settings, you must map the local QNAP path (e.g., /share/CACHEDEV1_DATA/Music) directly to a path inside the container (e.g., /music) using your container configuration YAML file.
Permissions: Confirm that the User ID (UID) and Group ID (GID) assigned to the container have full read/write permissions for your music folders so it can successfully register watches for every subfolder.
Would you kindly share your Docker Compose yaml file, which was used to create application on step 4
Embarrassingly enough, I wasn’t following the procedure correctly and it ended up as a network share. Once I retried with the correct YAML file I downloaded, the direct reference worked perfectly.
