[BUG] Documentation request: Synology DSM / Jellyfin real-time monitoring can exhaust host inotify watches

[Tomiliy]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Hi,

I am running the LinuxServer.io Jellyfin image on Synology DSM:

• Image: lscr.io/linuxserver/jellyfin:latest
• Host: Synology DS925+
• DSM: 7.3.2-86009 Update 3
• RAM: 32 GB
• Runtime: Synology Container Manager / Docker

This is not necessarily a bug in the LinuxServer.io image itself. It may be a Jellyfin/runtime/documentation issue, but I think the LinuxServer.io Jellyfin documentation could use a short note for Docker/NAS/Synology users.

Observed host-level inotify usage:

fs.inotify.max_queued_events = 16384
fs.inotify.max_user_instances = 128
fs.inotify.max_user_watches = 16384

TOTAL processes=20 instances=102 watches=16493

PID     UID     INSTANCES   WATCHES   COMMAND
9807    1027    75          16383     jellyfin

### Expected Behavior

_No response_

### Steps To Reproduce

So Jellyfin consumes almost the entire host fs.inotify.max_user_watches limit by itself.
The Synology host also continues to log:
fsnotify get overflow, max queue size is 16384
On this Synology DSM host, the fsnotify/inotify pressure appears to affect more than Jellyfin's real-time library monitoring. Several DSM services entered a partially broken IPC/socket state while still appearing to run:
Surveillance Station / Monitor Center stopped showing camera images.
Virtual Machine Manager communication services showed IPC / queue related problems.
Home Assistant's Synology DSM integration could no longer connect properly.
/tmp/synosnmpcd.sock was missing or unavailable while synosnmpcd.service still reported active/running.
Restarting the affected DSM services restored functionality without rebooting the NAS.
I understand that inotify limits are host-level kernel settings and need to be changed on the Docker host, not inside the container. Jellyfin's own documentation mentions increasing fs.inotify.max_user_watches, but the LinuxServer.io Jellyfin image documentation does not currently mention this.
Would you consider adding a documentation note for Docker/NAS/Synology users explaining that:
Jellyfin real-time library monitoring can consume a large number of host inotify watches.
Docker containers share the host's inotify limits.
The limit must be adjusted on the host, not inside the container.
On NAS systems such as Synology DSM, disabling Jellyfin real-time monitoring for large libraries and relying on scheduled scans may be safer if host fsnotify pressure affects other services.
Users should also check Jellyfin's upstream issue:
https://github.com/jellyfin/jellyfin/issues/3991
Related Jellyfin comment:
PASTE_YOUR_JELLYFIN_COMMENT_LINK_HERE
Thanks.

### Environment

```markdown
- OS:Synology DS 7.3.2
- How docker service was installed: directly on synology

CPU architecture

x86-64

Docker creation

Container was created via Synology DSM Container Manager GUI.

Image:
lscr.io/linuxserver/jellyfin:latest

Host:
Synology DS925+, DSM 7.3.2-86009 Update 3, x86-64, 32 GB RAM

Runtime:
Synology Container Manager / Docker

Container name:
jellyfin

I do not have a docker-compose file for this container because it was created through the Synology GUI. I can provide docker inspect output if required.

Container logs

No container crash is observed.

The relevant issue is host-level inotify/fsnotify pressure. Jellyfin remains running, but it consumes almost the entire host inotify watch limit:

fs.inotify.max_queued_events = 16384
fs.inotify.max_user_instances = 128
fs.inotify.max_user_watches = 16384

TOTAL processes=20 instances=102 watches=16493

PID     UID     INSTANCES   WATCHES   COMMAND
9807    1027    75          16383     jellyfin

The Synology host continues to log:

fsnotify get overflow, max queue size is 16384

This appears to be a documentation/support question rather than a container startup failure.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[aptalca]

This is not a container issue. Not even a docker system issue.

Your os/kernel implements those limits, which can be adjusted. Google is your friend.

[Tomiliy]

Thanks for the clarification.

I understand that this is not a LinuxServer.io container issue and that the inotify limits are implemented by the host OS/kernel.

For completeness, I did one more test:

• When the Jellyfin container is stopped, total host inotify watches drop to 110.
• When the Jellyfin container is started again, total host watches immediately rise to 16493.
• Jellyfin alone holds 16383 watches in one inotify instance.
• All Jellyfin library options.xml files have EnableRealtimeMonitor=false.
• The Jellyfin logs do not show new LibraryMonitor, Directory watcher, inotify, or watching directory messages.

So the remaining question is not the LinuxServer.io image itself, but why Jellyfin still creates that large number of watches even with real-time monitoring disabled.

I will continue this upstream in the Jellyfin issue tracker:
jellyfin/jellyfin#3991

This issue can be closed from my side.

Thanks.