Qnap troubles

Hi!

I bought a license in 2017. At first VH worked with no issues on my NAS. But at one point i upgraded the firmware on my QNAP TS-453A to 4.4.x. Ever since then there have been issues.

1. A USB license dongle can only connect one time.
I have a virtual machine with W7 for the VH client where i need the dongle connected. I have to suspend the VM weekly for backup. After resuming the VM i can no longer attach the USB dongle via VH. When i select use device, nothing happens. Only after i unplug the dongle from my NAS and plug it in again i will get an error message from the VH client and after that i can connect the dongle again.
In addition, i noticed that i can not stop the VH server nor restart the NAS before unplugging the dongle. Some digging showed waits on kernel (don't ask for specifics, i dug into it at spring time and have since forgotten).

2. VH server hides my external SSD drive.
Trying to solve issue 1, i added AutoAttachToKernel = 0 to server config. This solved the issue with dongle (I can now connect after VM resume). However this caused a side effect which is at least as annoying. I have also a Samsung SSD drive connected via USB3 for backing up most crucial data from NAS. The backup job is configured to eject the drive after backup completion. The drive stays physically connected all the time. It is made available to NAS a few minutes before scheduled backup by such script:
#!/bin/sh
echo 0 > /sys/bus/usb/devices/usb2/2-2/authorized
sleep 10
echo 1 > /sys/bus/usb/devices/usb2/2-2/authorized
This used to work fine until i changed the AutoAttachToKernel option for VH. Now the SSD does not re-appear after running the script and thus my backups fail (I want to keep the SSD invisible to the NAS as extra protection from ransomware). I have to stop VH server before running the script. Then it works. I have added the SSD to ignored devices list but that did not help any.

VH server version is 4.20 and the client is currently version 5.0.8.

I think QNAP changed something in QTS version 4.4 that VH server relied on.

Is there any other config option i could try? I want to have my backups start without manual intervention.

Please help.

Regards,
Lauri

#2

Unfortunately it sounds like a bug in the qnap kernel. I think you should leave "AutoAttachToKernel=1" as that is the only way to solve 2.

Regarding 1. can you try this. When it gets "stuck" again after resuming the vm can you right click on the dongle in the virtualhere client inside the vm and then select custom event handler... and enter

power_cycle_port

Then press ok. Can you use the dongle now?

In reply to by Michael

#3

Michael, thank you for the prompt reply!
I will try it tomorrow and report back here. Would server log file vhusbd.txt be relevant to you also?

In reply to by Michael

#4

Unfortunately entering "power_cycle_port" via custom event handler did not have the desired effect. It remains stuck. But the behavior was a little bit different this time. I did not receive any error messages from prior connect attempt after unplugging the dongle. I was not able to restart VH server (a zombie process remains from previous instance). I will probably have to restart the NAS.
I can delay doing that for about 24hrs if you want me to get some info about the current state.

#5

OK sounds like a bug in qts.

Can you email qnap and ask them to fix this.

I dont have control over their firmware unfortunately.

What is the name of the USB dongle that is causing trouble? Is it sentinel hasp or something like that?

In reply to by Michael

#6

I already asked Qnap and they told me it is a bug in VH and i should contact the author to have it fixed.
The dongle is an older version of Feitian Rockey 6. It classifies itself as a hard drive.

#7

Its not a bug in virtualhere

#8

Could you please ask Qnap to fix it then?
Since you are convinced it is their bug, then you must know the specifics of which functions are failing to work as expected. I have no such information to give them.

#9

No i dont get any response from them. (Notice virtualhere is still at 3.4.7 on their app store even though ive emailed them multiple times to upgrade it)

I think you just have to downgrade your qnap firmware. Or use some other hardware as a virtualhere server

#10

In that case, would you please tell me what exactly to tell them. Which kernel calls are failing to return? How can they reproduce the issue without my specific hardware? I will try to contact them again.

#11

Its impossible to know how to fix it without knowing their setup. You will need to accept that you have to wait for some kernel upgrade by them or you need to use some other server. They probably have many other bugs to fix all the time and they wont fix unless somehow they find it with their own testing on something unrelated. From 10 years of doing this that's how it works. Its just too bad ,if you want quick fixes you need to run your own server, and know all about it e.g a pi or something. If this happens on a pi then i just ask the user to upgrade their raspbian or to re-write their sdcard with a previous kernel. Luckily bugs like this are pretty rare and from my deduction its usually a buggy xhci driver. And really you shouldnt be using w7 anymore as its not support by me or microsoft so that would help to move to win10