Not enough watchers in /etc/sysctl.conf

[randy-personal]

Describe the bug When deploying the container, I mapped a host path to "/vaults". The path had no files in it, but still when trying to open a vault in Obsidian I get the error: ENOSPC: System limit for number of file watchers reached, watch /vaults/default.`

To Reproduce Steps to reproduce the behavior:

1. Go to 'dockerhost:mapped-port'
2. Click on 'Quick Start' or 'Create a new vault' or 'open a vault from folder'
3. See error

Expected behavior Load a vault correctly.

Screenshots

Desktop:

• OS: Windows 10
• Browser Firefox
• Version 107.0.1

Docker Host:

• Platform: ESXi VM, 8x Intel Xeon E5-2667 vCPU, 32 GB RAM
• OS: Ubuntu Server 18.04 LTS
• Storage: 13TB NFS volume, mounted from a different VM, with a specific path in it mapped to '/vaults'
• Docker Runtime: 20.10.21, build baeda1f

Additional context Based on this thread: https://forum.obsidian.md/t/obsidian-starts-with-blank-screen/2427/4 I tried running: echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

in the container, but I get:

root@12f9e2fba777:/# echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p fs.inotify.max_user_watches=524288 sysctl: setting key "fs.inotify.max_user_watches", ignoring: Read-only file system sysctl: setting key "fs.inotify.max_user_watches", ignoring: Read-only file system

It seems I can't modify the file and the setting has to be increased in the image.

[sytone]

Do you have details of where in the image, this is a lightweight overlay to the base image.

[sdugre]

I had the same issue. I was able to solve it by running the same command you tried on the host machine (not the container).

[randy-personal]

Tested and confirmed. Increasing the number of watchers on the host fixes the problem. What I did was:

1. Run the command: echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p on the host.
2. Recreate the Obsidian container, with pulling the latest image.

This problem should only affect systems, where the "vaults" path is mounted on some NAS, that already has a lot of files in it, but now there is a fix. Thanks @sdugre !

Probably worth mentioning this in the readme.