Thunderbird is extremely slow during writing operations on to a NAS since Windows 10 upgrade (bug 1244456)
The problem: Since the upgrade from Windows 7 Professional to Windows 10 Pro (1511) Thunderbird (38.5.1) becomes extremly slow during writing operations to the store folder onto a NAS device (POP3 accounts).
I alternately use two computers (both Windows 10 Pro 1511), which are connected via WLAN to a router. The NAS (Synology DS115j) is connected to the router via LAN cable. The data transfer rate is about 5 MB/s when copying any files from or to the NAS using the Explorer. Thunderbird writes only at 80 to 120 kB/s (e.g. saving drafts, moving or copying mails to other folders within the Thunderbird folder structure). The data transfer rate with the Explorer is even at 5MB/s, although Thunderbird is writing onto the NAS at the same time!
The Thunderbird user profiles are on the local hard drives of each computer (one profile per computer), the emails of the POP3 accounts are in separate store folders on the NAS. And Thunderbird is running on just one of the computers at the same time at anytime!
What has been attempted:
- Deactivating the Windows firewall and uninstalling the antivirus software has no effect to this. - Even connecting the NAS directly to a computer via LAN cable makes no difference, only the data transfer rate when e.g. copying files from or to the NAS using the Explorer goes up to 11 MB/s. - Also the older version Thunderbird 31.7.0 can't help it. - The NAS has been replaced by a LINUX-Notebook, which takes over the role of the NAS, but the situation stayes the same. + Saving an email as eml-File using "Save As" or saving attachments as single files to the NAS runs much faster at 5MB/s (!)
What helps, but no solution: Thunderbrid becomes unleashed using Windows 7! So Windows 10 is the reason for the slowness, but the Microsoft TechNet doesn't help and recommends its own products.
Has anyone any idea, maybe how the configuration (Windows or maybe Thunderbird) has to be adapted!
Thank You very much and greetings from Germany! Kai
FYI: I already had this question in the german Thunderbird forum, without solution, yet: https://www.thunderbird-mail.de/thread/72504-verbindung-zu-nas-beim-speichern-senden-extrem-langsam/
Wót Wayne Mery změnjony
Wšykne wótegrona (3)
No real isea, but mu guess is there has been a change in the say windows manages remote filling systems.
In the days of Windows 200 is was always op locks. what it could be these days who knows. but I would say you will probably see the same issue with say lbre office if you were to paste a MB of data into it and then tell it to save the file. to the NAS
The process for copying and writing are not the same. So data throughput comparisons are not comparing apples with apples, but I get what you are saying. Note that removing the anti virus will enable Defender. Some users have reported they need to exclude the Thunderbird process from Defenders humble clutches.
For the test without any anti virus (F-Secure) the Defender was deaktivated by "group policy" and also no entry with anything like "defener" was listed" in the taskmanager. So there should actually have been no anti-virus protection.
I have tested Libre Office Writer with a 13 MB document (some text with eight jpegs), saving it to the NAS, it lasts 4 to 5 seconds. Really no comparison to the strangled Thunderbird.
Two more things could be interesting: 1. If the NAS is replaced by a Win10 laptop, leave to do his work, there are no problems with low data throughput (…as I expected) 2. A friend has a very similar problem with a different NAS from QNAP Systems. He can eliminate the problems with an older TS-210 instead of the newer TS-251. Could this be a clue to the cause?
Nor any idea rather than simply accept? Perhaps an attempt to contact the mozilla developers? Even it becomes only an eternal record in the to-do list.
In the meantime, I have reported this issue as a bug on bugzilla.mozilla.org. To my surprise, the problem is already known and in progress: https://bugzilla.mozilla.org/show_bug.cgi?id=1244456