I’ve recently written about an issue that I have been experiencing with Synology Drive on macOS for many months.
These days when you are running into an issue with some app or any paid(!) or unpaid service of a big tech company you are usually already prepared to just find another solution as support is generally non existant. If you are blessed with a response they will usually just feed you basic throubleshooting steps like "Have you tried to wipe your NAS and re-install everything?" or telling you to go away with some variation of "Thanks for the feedback, we’ll take that into consideration for future product updates".
With that in mind I was opening a support request through Synology’s website…
I’ve recently written about an issue that I have been experiencing with Synology Drive on macOS for many months.
These days when you are running into an issue with some app or any paid(!) or unpaid service of a big tech company you are usually already prepared to just find another solution as support is generally non existant. If you are blessed with a response they will usually just feed you basic throubleshooting steps like "Have you tried to wipe your NAS and re-install everything?" or telling you to go away with some variation of "Thanks for the feedback, we’ll take that into consideration for future product updates".
With that in mind I was opening a support request through Synology’s website and provided some debug information I have collected, fully prepared to never hear from them again. Especially as my NAS is already many years old and I’m not paying for any current services of Synology.
Timeline
On the next day I’ve already heard back from them with some instructions on how to submit standardized debug logs from the Synology Drive client and server. I chalked this up to the usual automated process and didn’t think much of it. I submitted the logs and a few days later, to my surprise, the ticket got escalated to a developer.
In the next ticket I was asked to give them access to my NAS through some temporary support account that you can easily create right through the interface. Through that they were hoping to reproduce this specific issue with my NAS and their lab setup directly.
I’ve then provided detailed timestamps and graphs of connection counts on my machine after starting Synology Drive with the following commands:
~ ❯❯❯ watch -n 5 'echo "$(date +%s),$(netstat -an | grep TIME_WAIT | wc -l)" >> time_wait_2025-12-31.csv'
~ ❯❯❯ gnuplot -e "
set terminal pngcairo size 1200,600;
set output 'time_wait_2025-12-31.png';
set datafile separator ',';
set xdata time;
set timefmt '%s';
set format x '%H:%M';
set title 'TIME_WAIT sockets over time';
set xlabel 'Time';
set ylabel 'Count';
plot 'time_wait_2025-12-31.csv' using 1:2 with lines title 'TIME_WAIT';
"
To my surprise I received a message from Synology a few days later. They were able to identify the issue and even prepared a patched version that I was asked to run.
We found that during a reindex process, the Drive Client may trigger a large number of file change notifications at once. In this scenario, those notifications were sent in a single burst, which can result in a very high number of short-lived TCP connections in some scenarios.
To address this, our team has prepared a patch that changes this behavior so that notifications are sent in batches instead of all at once, reducing the number of concurrent connections created during reindexing.
Please install the attached(on the left side of this ticket) Synology Drive Client patch on your Mac and observe whether the TIME_WAIT connection count and network behavior improve.
This version fixes the issue and it will be released for all customers soon. I’ll be watching the changelog closely to know when I can switch back to the main update path and not running a patched version.