When QTS 5 first came out, I immediately discovered a problem that was major to me, had extensive exchanges with support, and gave up and rolled back to QTS 4
Just had a go at QTS 5 again (5.1.7) now some months down the tract, again the same issue, same response from QNAP support, so again rolled back to QTS 4 (4.5.4.2790)
I maintain the issue is in the implementation of SMB in QTS 5 but can't get any interest from support, who just want to blame a third party product instead of looking at their own. My assertion is that if something works under QTS 4, it damm well should work under QTS 5.
The problem stems from the performance of a syncing program running on a windows PC, was w10 for years and everything worked, has been for months a w11 platform, also worked well till I upgraded to QTS 5
The Syncing program is GoodSync, and syncs FROM the NAS TO the windows PC, specifically to that PCs OneDrive folder. Having had so many troubles with HBS and QBAPs OneDrive api as a destination, the strategy is to collect everyones data as well as multimedia and other NAS based stores, onto a master PC and let that PCs OneDrive upload it (OneDrives Free up space on the PC means you are not really storing the data twice).
GoodSync also has very good micro level filtering so I can limit what gets presented to OneDrive saving bandwidth from large files that don't need backing up
This is all on a local network, and I have NO interest in passing my data through any other cloud servers other than the final upload under Microsofts control, so GoodSync connects to the NAS shared folders via SMB links, i.e. mapped drives, but using the network format for the links in GoodSync folder specifications, e.g. //NAS/Folder etc.
SO HERE IS THE REAL CRUNCH. Because the NAS supports access to accounting databases, the software of which keeps multiple files to make up a single accounts database, I use GoodSync to sync changed files with it's auto setting 'On File Change', so changed files only are synced and immediately uploaded by the PC to OneDrive, thus facilitating rolling back an accounts database if necessary to any time over the last 30 days (OneDrives Version retention period)
Has been working really well for years, until (twice) I upgraded QTS to V5, and GoodSync stopped getting alerts of multiple file changed on the NAS as multiple accounts were worked on, and therefore required a resource hungry scheduled full scan to find and sync changed files, thus loosing the advantages of immediate versions and recovery at any time as opposed to the scheduled sync times, let alone the resource usage.
So if anyone who is an expert at the engineering level of SMB has read this far and had a light bulb moment, would really appreciate any info that might throw a light on why a client monitoring for ALL file changes over an SMB link from Windows to QTS works under QTS 4 and not QTS 5, and then maybe I can take that to QNAP support because they have just wiped me on this, twice, once when reported under QTS 5.0.1 I think it was, and again just now under QTS 5.1.7
Just had a go at QTS 5 again (5.1.7) now some months down the tract, again the same issue, same response from QNAP support, so again rolled back to QTS 4 (4.5.4.2790)
I maintain the issue is in the implementation of SMB in QTS 5 but can't get any interest from support, who just want to blame a third party product instead of looking at their own. My assertion is that if something works under QTS 4, it damm well should work under QTS 5.
The problem stems from the performance of a syncing program running on a windows PC, was w10 for years and everything worked, has been for months a w11 platform, also worked well till I upgraded to QTS 5
The Syncing program is GoodSync, and syncs FROM the NAS TO the windows PC, specifically to that PCs OneDrive folder. Having had so many troubles with HBS and QBAPs OneDrive api as a destination, the strategy is to collect everyones data as well as multimedia and other NAS based stores, onto a master PC and let that PCs OneDrive upload it (OneDrives Free up space on the PC means you are not really storing the data twice).
GoodSync also has very good micro level filtering so I can limit what gets presented to OneDrive saving bandwidth from large files that don't need backing up
This is all on a local network, and I have NO interest in passing my data through any other cloud servers other than the final upload under Microsofts control, so GoodSync connects to the NAS shared folders via SMB links, i.e. mapped drives, but using the network format for the links in GoodSync folder specifications, e.g. //NAS/Folder etc.
SO HERE IS THE REAL CRUNCH. Because the NAS supports access to accounting databases, the software of which keeps multiple files to make up a single accounts database, I use GoodSync to sync changed files with it's auto setting 'On File Change', so changed files only are synced and immediately uploaded by the PC to OneDrive, thus facilitating rolling back an accounts database if necessary to any time over the last 30 days (OneDrives Version retention period)
Has been working really well for years, until (twice) I upgraded QTS to V5, and GoodSync stopped getting alerts of multiple file changed on the NAS as multiple accounts were worked on, and therefore required a resource hungry scheduled full scan to find and sync changed files, thus loosing the advantages of immediate versions and recovery at any time as opposed to the scheduled sync times, let alone the resource usage.
So if anyone who is an expert at the engineering level of SMB has read this far and had a light bulb moment, would really appreciate any info that might throw a light on why a client monitoring for ALL file changes over an SMB link from Windows to QTS works under QTS 4 and not QTS 5, and then maybe I can take that to QNAP support because they have just wiped me on this, twice, once when reported under QTS 5.0.1 I think it was, and again just now under QTS 5.1.7
