Running 1.23.4-29 from SynoCommunity. If I should post there instead of here please tell me so.
Running on a DS216j with DSM Version: 7.1.1-42962 Update 8
Read in forum of commands to try in Task Scheduler and tried them all. Most generated errors. Last tried
sh -c ‘(sleep 90 && echo 204800> /proc/sys/fs/inotify/max_user_watches=204800)&’
Which resulted in:
Task Scheduler has completed a triggered task.
Task: higher inotify limit
Start time: Sat, 23 Mar 2025 09:00:24 GMT
Stop time: Sat, 23 Mar 2025 09:00:24 GMT
Current status: 0 (Normal)
Standard output/error:
None of the commands fixed the problem. I’ve dropped down levels to reduce the complexity of the folders I’m syncing and I still have the problem. I can’t drop any lowerl
Part of what is perplexing me is that the folders that inotify failes on are not the largest or most complex folders that I’m syncing. It fails on four folders:
Other folders with the inotify handler working properly:
(1) 534 folders, 4787 files, 101 GB
(2) 519 folders, 23248 files, 53.5 GB
I know that my Synology box is old; if I need a newer one to have Syncthing work properly I’m willing to upgrade to the DS223j, but I’d rather not spend the money.
The Syncthing filesystem watcher consumes inotify handlers, and your device (like most or all Linux devices, AFAIK) has limits on that. I would recommend that you increase the inotify limit on the device and carefully watch for memory or other performance bottlenecks. See https://docs.syncthing.net/users/faq.html#inotify-limits to get started, but definitely consult your Synology device’s documentation for this.
The reason DSM Task Scheduler is often recommended is because lower-level changes – e.g. modifying /etc/sysctl.conf – will be undone during a firmware upgrade.
However, since the DS216j is around 9 years old (the last two digits of the model number is the year of release), it’s probably not a pressing issue.
If that line above is verbatim, it definitely would’ve generated an error.
Breaking down each part of the command-line above:
sh -c runs the command string that follows.
sleep 90 waits 90 seconds before continuing.
echo 204800 spits out the string “204800” to standard output.
> redirects standard output into the target (most often a file).
The last segment is incorrect.
/proc/sys/fs/inotify/max_user_watches=204800 is an invalid path because there’s no file named “max_user_watches=204800” under /proc/sys/fs/inotify/
The correct path is:
/proc/sys/fs/inotify/max_user_watches
To see the current limit, output its contents:
cat /proc/sys/fs/inotify/max_user_watches
Maybe it’s DSM Task Scheduler, but the 90-second time delay, sh -c and ()& (the latter spawns a subshell) seem to be overkill. Just the simple version below is all that’s usually required:
Spaces/tabs before and after the greater-than sign (>) are optional, but I included them for clarity.
204800 means the Linux kernel will allow up to 204,800 slots in its inotify queue – one slot per file being watched. Each occupied slot requires 1,080 bytes of RAM.
As an alternative to DSM’s Task Scheduler…
Both of the following commands temporarily achieve the same result, with the Synology reverting back to its default setting after a reboot:
(Personally, I’d recommend against using DSM Task Scheduler and/or changing the system configuration until you’ve verified that the temporary change works – and that the limit set is sufficient.)
For a persistent change, edit /etc/sysctl.conf, adding the following line:
fs.inotify.max_user_watches=123456
Or keep the line above in your own text file on the storage array (so it survives firmware upgrades) and have DSM Task Scheduler load it for you:
sysctl --load=/path/to/config/file.conf
There should’ve been something in the standard output/error…
It’s not which folder is the largest and/or most complex, it’s the sum of all of the files being watched for a user.
From the inotify manual page, the /proc/sys/fs/inotify/max_user_watches kernel interface…
[…] specifies an upper limit on the number of watches that can be created per real user ID.
So for example, if the limit is 1,000 files, and the first folder added to the watch list contains 999 files, while the second folder contains 2 files, the tiny second folder will trigger the inotify warning.
But if it’s reversed with the 2-file folder added first, followed by the 999-file folder, the larger folder will trigger the warning instead.
Think of it like a line of customers waiting to get into a restaurant. The restaurant has a maximum seating capacity. Which party gets turned away depends on how much space is left on the greeter’s waiting list at the moment that a new group of customers walk in.
With only 512MB of RAM in the DS216j, there’s a practical limit to how many files can be watched. After subtracting memory used by DSM and Syncthing itself, the limit could be less than 100,000 files.
If you want to avoid spending the money on an upgrade, you’ll likely have to do a deep dive thru several earlier forum threads about running Syncthing on older Synology NAS units and Syncthing’s tuning guide.
That is a wonderfully clear and (I expect) complete answer. I will chew on it tomorrow and see if I can fix it within my hardware limitations. If not, I’ll bite the bullet.
As I have so little memory I decided to try a more conservative number than previously: 16384
I tried all of the syntax that you provided (using 16384) and was always told “permission denied on key”. Just to be certain that the number wasn’t too large I also tried 8190; same result.
Your note that my hardware is 9 years old makes me more willing to upgrade, particularly as I’ve already replaced the disks twice.
I’m also willing to user puTTY; while I haven’t used it with synology, I successfully used it with pfsense.