Hi! I’ve been running QuObjects on my NAS for quite a while now with no issues, but the latest update apparently broke uploads. I managed to get the log files and every single one is failing with HTTP/1.0 400. I couldn’t find much else, but downgrading it to the previous version (2.5.513) solved the problem. Any ideas on how to get more debug information about this?
Hope this helps, in case anyone else is hitting the same issue.
Cheers!
Hi!
I had the same issue after the last upgrade, I fixed just moving the server port from 59000 to 59010.
Best regards
Same here - The latest QuObject release broke uploads.
Reverting to the previous package version works for now.
Changing port numbers does not.
After internal analysis, we were unable to reproduce this issue for the time being. If you are experiencing a similar problem, please feel free to open a support ticket, or send us the logs and settings via private message so our team can further analyze the issue. Thanks!
any solution for this bug?
do you have tested the latest version before release to production? can you imagine our company loss more user because the system can’t access photo profile account to identify the member?
and why you hiding the stable version before?i need to downgrade. can you share quobject 2.5.513 download?
The same issue at TS-673. FW 5.2.9.3410. I can not upload the files or create the folder. Only downloading is working. Changing the port from http:8010 to 5910 does not helps. Storage space contains myS3 folder. Linked bucket is private with the enabled versioning and enabled Number of days to retain and Number of versions to retain. Object lock is disabled. Server configured for HTTP. Client is Brows3 v0.2.34. QuObject version is 2.5.539
I also see 400 error when connecting to QuObjects from Velero. The error detail was:
I checked the pcap. The upload packet included X-Amz-Checksum-Crc32 and a X-Amz-Content-Sha256. I used AI to generate a script for re-calculating the checksums based on the pcap payload, and the result shows that the crc32 and sha256 are both correct.
I downgraded to 2.5.513 and everything worked again.
I filed a support ticket, and Jack Gao1 says:
可以使用着513版本的看看，观察后续会不会出现问题
QuObjects 2.5.539 对齐 AWS S3 最新校验标准，强制多校验头互斥 / 兼容，导致与未适配的 SDK（Velero AWS 插件）不兼容
Tanslation:
You can try using version 513 and see if any issues occur later.
QuObjects 2.5.539 aligns with the latest AWS S3 checksum standards, enforcing mutual exclusivity/compatibility for multiple checksum headers, which causes incompatibility with unadapted SDKs (Velero AWS plugin).
@SteveKo Is that your QNAP official response on this breaking change? Caiming AWS Go SDK not compatible with your so-called “aligned-with-AWS” behavior? And asking the user to roll back without any diagnose and suggestion?
Hi @taoyouh12138
We are truly sorry for the unsatisfactory experience. Could you please provide us with your support ticket number so we can look into how it was handled?
Additionally, after some time spent trying to reproduce the issue, we have successfully replicated it and will have it fixed in a future release. We sincerely apologize for the inconvenience and thank you all for your understanding and patience.
My ticket is Q-202605-30542. After some arguing, he finally tried to reproduce the issue and admitted that it was a bug.
I found that sometimes the support team may think I’m a newbie and throws me some obviously AI-generated content (no reliable source, not matching the info I provided).
I have provided a detailed capture in the ticket. Someone could extract all the headers and payload and try to reproduce (if they don’t know how, AI can help). Someone could tell me what they tried and what was the response from the software. But I got nothing except the response I posted above.
We are truly sorry for the unsatisfactory experience, and our support team will continue to work on improving our service. Regarding the issue discussed in this thread, it will be fixed in the next release, which is expected to be available within two weeks. Thanks!