When I push the One Touch Button, the defined operation (synchronize, from TS264 to external drive) works perfectly.
However, I can’t get the external drive to automatically unmount after the job is completed.
Also, even though I’ve checked the box for “Enable the alarm buzzer” … the alarm does not beep after the job is completed.
The “background task” indicator shows that the job is Finished
TS-264 - QuTShero - HBS3 - Services - USB One Touch Copy - copying from RAID 1 folder to external drive (exFAT) plugged into front-side USB port.
What am I doing wrong?
Everything seems good.
The “external device” indicator shows the drive properly attached, as a full USB 3.2 Gen2 Device.
Settings seem right:
Back up to connected USB drive
Synchronize
Yes Efficiently handle sparse files
correct folders (BACKUPS/Home → FrontUSB1/Home)
Yes and No for Manually unmount USB drive (tried both settings)
Yes Enable the alarm buzzer
Apply, Apply
Push the “One Touch Copy button” (push and hold for three seconds) no beep and no flashing until I let the button go, then one beep.
I can hear it running, blue light is blinking, the background task indicator shows the job running, and its percent complete.
When the noise stops, the blue light goes solid and the task indicator says that it’s finished, nothing happens.
No unmount, no beeps … BUT I can check the files on the external drive … yup all the files were properly copied. So the job is done.
Just no unmount and no job-finished beeps.
Regarding the audible alert (beeper) function for backups, it’s designed to emit a short beep only when the backup starts. It won’t beep when the backup finishes.
As for automatic unmounting, we currently don’t have this feature because we’re unsure if users will continue to use the device after a backup.
However, I’ll definitely report both of these points to our product department for new feature evaluation. Thanks for your valuable feedback!
As for automatic unmounting, to me this is a HUGE deal. Synology has this feature. It’s a key part of protecting against ransomware. The whole point is to copy your backups to an external hard drive AND THEN UNMOUNT the external drive. If you leave it mounted, then your external hard drive is open to attack.
Without this feature, then it means I have to MANUALLY unmount the external drive. Every time. This is not a sustainable strategy.
Holy cow. What a huge difference between Qnap and Synology. I thought Synology’s primary benefit was dumbing down the user interface to make it easy. I thought Qnap’s primary benefit was that it could do anything Synology could do, and more, but it just took some digging to make it work.
THIS, however, is a basic protect-against-ransomware feature that Qnap doesn’t have.
In this case, then I don’t understand the point of having the mount checkbox in the One Touch Copy settings. What does that checkbox even do?
Also, if the Ransomware has a zero day feature, it could have been on your machine for a long time and backed-up files would still have the ransomware lying dormant waiting to be restored.
To me having a USB drive unmounted automatically is not a serious prevention of ransomeware. Frankly, if you really want to protect yourself, unmount the drive and physically remove the USB device after backup.
The other protection against ransomeware is don’t expose the NAS to the internet, use proper passwords, etc. I had a ransomeware attack on one of my Windows laptops earlier this year. The attacker came in through a remote support software I was using that had some vulnerabilities. Fortunately, I did not have my NAS actively connected to that laptop. They tried to access the NAS multiple times but they were unsuccessful. Without going into a lot of unecessary detail, let’s just say that the entire ransomeware attack could have been stopped with a password. PM me if you want to know more about what happened.
If you really want to protect critical files - use a NAS with QuTS Hero. Put your critical files into WORM folders. Back those up to your USB drive and physically remove the drive when done (which is what Dolbyman said to do). Don’t rely on Linux based unmount methods. As OneCD said, the ransomeware could easily scan the USB bus and remount the drives and infect everything.
Another good option - get something like QnapCloud or iDrive backup storage. Back your data up offsite. iDrive is pretty reasonably priced. I think I pay something like $200 for 20GB (don’t use their “NAS Backup” feature that works with HBS - that’s way more expensive - use their app available in App Center).
Following our internal discussion, we’ve decided to incorporate the auto-unmount and backup completion notification features into our future product development roadmap. We plan to release these in upcoming versions. Thanks for your suggestion!
However, as we discussed previously (and thank you all for the valuable additional insights), we still don’t recommend using auto-unmount as a primary method to protect against ransomware.
Thank you SteveKo. To me at least, your responsiveness and making the change to add auto-unmount is really important, and I appreciate what you did.
As for protecting against ransomware, auto-unmount is not my primary method for ransomware protection. Not at all. But I do consider it part of an overall strategy, which includes WORM, physically-removed offsites, QuTS Hero, passwords, and not using the admin account to do those primary backups to the NAS.
And while I understand the notion that a skilled ransomware attacker could re-mount an unmounted external drive, I think that assumes the attacker knows that the unmounted external drive exists. And is still attached. Not an easy guess. Still … even if the attacker makes that guess … that level of hidden is a million times better than “Oh look, here’s a still-mounted external drive to look at.”
SteveKo, AGAIN, thank you. This is a big deal (for me at least) and I really appreciate it.
Firstly, by all accounts, ransomware attacks are completely automated. There’s no hacker sitting in front of a bunch of computer monitors like in the movies, deciding what his/her next move will be. Automating the attack process allows many things to happen very quickly, which is important as the attack could be noticed and terminated without warning at any time. The attack has a much greater chance of success if it can be carried-out quickly.
Which leads to my second point. It’s a trivial matter to check for attached but unmounted block devices (with the df utility, for example). Anyone can do it. It’s also day-one coding level easy to mount those devices again if they’re not mounted.
With a couple of code lines, unmounted devices can be mounted again as part of the ransomware programming.
Don’t assume a device is “hidden” just because it’s not mounted. Unmounting a backup device isn’t enough. It must be detached from the host too. Either electrically or physically.
Good point. So would it help if the “automatically unmount” function was turned into “automatically unmount and eject”? If I recall correctly, a drive that is unmounted and ejected no longer appears in either df -h or lsblk. (Even if the usb cord hasn’t actually been pulled.)
