· None of the above quite fits
· None of these quite match
· Since I updated my Roon server to using Docker Roon no longer scans my library during the designated time like it used to to.
· I use a ubiquiti router
I will also add that everything else works and when I manually scan the library it works. The automated scan use to work at 2 am. It’s not the worst problem in the world. Any help would be appreciated.
Hi @Mike_Falcon,
Thanks for the details. Since the manual scan still works and everything else is behaving normally, the main question is whether the automated scan is not running at all now or whether it is running at a different time.
Some systems use UTC for scheduled tasks, so it would be worth checking whether it is still running at your desired time, but in UTC instead.
Please let us know what you find there, and we can take it from there.
So I double checked my docker compose file
environment:
**-** ROON_INSTALL_BRANCH=production
**-** TZ=America/Chicago
Which is correct if I’m not mistaken.
So I do this:
docker exec -it roonserver bash
#timedatectl status
bash: timedatectl: command not found
Which was a little surprising.
Also I want to clarify, that it doesn’t not add to the library at the scheduled time (2 am). It doesn’t do it at all. I added files and waited a few days and they were never added to my Roon, until I manually said rescan library.
Hello @Mike_Falcon,
Thank you for the update and for providing those details.
Since the container is not performing the scheduled library scan at all, it suggests that the Roon process either lacks the necessary “watch” permissions on your library path or there is a mismatch in how the container is reading the underlying storage.
Given that you are using an NFS-mounted path (/Music), the issue might be that the Docker container environment cannot reliably detect filesystem changes (inotify events) on that specific remote mount, which effectively prevents the “automatic” scan from triggering.
To get to the bottom of this, could you please:
docker-compose.yml file: Please copy and paste the entire content of your compose file here (be sure to redact any sensitive passwords/keys). I want to see exactly how your volumes are mapped and if there are any environmental flags that might be suppressing the background scan.Once you share the YAML file, I can see if we need to adjust your volume mount parameters to better support real-time library monitoring.
services:
roonserver:
image: ghcr.io/roonlabs/roonserver:latest
container_name: roonserver
network_mode: host
environment:
**-** ROON_INSTALL_BRANCH=production
**-** TZ=America/Chicago
volumes:
**-** /opt/stacks/roon:/Roon
**-** /home/xxxxxx/Music/Music:/Music
**-** /home/xxxxxx/backups/roon:/RoonBackups
restart: unless-stopped
logging:
driver: local
I x’d out the directory but that is a copy/paste
Hey @Mike_Falcon,
Thanks for sending that over! Looking at the actual compose file you posted, the Music volume is:
/home/xxxxxx/Music/Music:/MusicThis looks like a local path (/home/…), not an NFS mount.
Let’s next Verify TZ is actually being applied inside the container:
docker exec -it roonserver dateThis will show what time the container thinks it is, confirming if TZ=America/Chicago took effect. Then, Check if inotify limits are the culprit on the host:
cat /proc/sys/fs/inotify/max_user_watchesDefault is often 8192, which can be exhausted. Bump it:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
sudo sysctl -pDoes the container restart at any point between setup and 2am?
Thank you! 
So that path is because the nfs is mounted on the host and that is path to the mount point. Is that bad practice?
Here is out of the date as you ask and just the date on the host.
:~$ docker exec -it roonserver date
Fri May 29 18:19:42 CDT 2026
:~$ date
Fri May 29 06:19:51 PM CDT 2026
So these were accurate times with the main difference being one is 24 hour time and one is 12 hour.
~$ cat /proc/sys/fs/inotify/max_user_watches
249039
Looks like a lot.
The container does not restart and if it did I would see where the library was updated. It doesn’t (unless I manually update)
Thanks
Hi @Mike_Falcon,
Thank you for those details — timezone and inotify limits both check out fine.
To answer your question: mounting NFS on the host and passing the mount point into Docker as a local path is not bad practice, but it does explain your issue. NFS mounts do not generate inotify filesystem events, which is what Roon relies on to automatically detect new or changed files. This is a Linux kernel limitation — inotify simply does not work over NFS, regardless of how the path is presented to the container.
This means Roon’s “watch for changes” mechanism will never trigger on an NFS-backed path. Manual rescans work because they don’t rely on inotify — they actively walk the directory.
Please try adding the network storage directly in the Roon application
\\your-nas-ip\Music)I believe this will solve it for me and you found my problem but I want to be clear.
Do I need to mount it on my host (in the fstab file) to a mount point and a put that in docker
Or
Do I just access it in Roon like I’m running it directly on my host and I don’t need to put it in my docker compose or mount it to my host at all?
Hi @Mike_Falcon,
Great question! The second option — you do not need to mount it on the host or add it to docker-compose at all.
Just add it directly in Roon as a network share (SMB path). Roon handles the connection itself from inside the container, polls the share on its own schedule, and detects new files without relying on inotify. You can remove the Music volume from your docker-compose.yml entirely.
So your setup becomes:
Remove -v /home/xxxxxx/Music/Music:/Music from docker-compose.yml
In Roon → Settings → Storage → Add folder → Network share → enter \192.168.1.200\shared\Music\Music
This is now working. Thanks for helping with this. I never would have guessed that NFS shares were the problem.