Submitted by dataforxyz on Mon, 10/07/2019 - 11:10
While backing up all my sites it fails on 8 out of close to 30 total websites. Mostly wordpress installs.
The error message for all these is the same. All 8 are wordpress installs. But so are 95% of the sites on this server.
.. upload failed! Error in call to API function "files/upload_session/append:2": Bad HTTP "Content-Type" header: "application/x-www-form-urlencoded". Expecting one of "application/octet-stream", "text/plain; charset=dropbox-cors-hack". (performed 3 attempts)
Its pretty clear what that means. Just not sure why it might be happening.
What other error logs or info do we need to help trouble shoot this.
Status:
Fixed (pending)
Comments
Submitted by andreychek on Mon, 10/07/2019 - 13:16 Comment #1
Howdy -- thanks for your report!
That's an issue that Jamie is working on now, several folks are seeing that issue. It will be fixed in the next Virtualmin version.
Note though that the dropbox upload feature only comes with Virtualmin Pro, and it appears your Pro subscription lapsed last month. You'd need to have an active Virtualmin Pro license in order to receive any updates for Virtualmin Pro.
Submitted by CrankyCronos on Wed, 10/16/2019 - 04:41 Pro Licensee Comment #2
I have this happening too. Any word on its cause or a possible fix?
Submitted by andreychek on Wed, 10/16/2019 - 09:49 Comment #3
Thanks for checking in on this! I asked Jamie for his thoughts on when we'll be releasing an update... if it's not soon we'll work with you to get a patch applied.
Submitted by CrankyCronos on Thu, 10/17/2019 - 07:48 Pro Licensee Comment #4
That's cool. You guys rock.
Submitted by JEMEDIACORP on Mon, 10/21/2019 - 08:44 Pro Licensee Comment #5
We're seeing this as well, on almost all of the 170+ virtual servers we back up to Dropbox. The exact same error message as in the original post. I'd say this issue cropped up for us about 2 weeks ago but I don't know for sure. We thought it may have just been a fluke on Dropbox's end but I'm glad to see this issue exists and is being worked on. Looking forward to the next Virtualmin update and we of course appreciate everyone's hard work on Virtualmin and Webmin over the years! :)
Submitted by andreychek on Fri, 10/18/2019 - 01:18 Comment #6
There's details on the new Webmin and Virtualmin release to fix this issue here:
https://www.virtualmin.com/node/67528
Submitted by JEMEDIACORP on Mon, 10/21/2019 - 08:40 Pro Licensee Comment #7
We've updated to Virtualmin 6.08 but are now receiving a new (though eerily similar) error message when trying to backup with Dropbox:
Uploading archive to Dropbox .. .. upload failed! Error in call to API function "files/upload": Bad HTTP "Content-Type" header: "application/x-tar". Expecting one of "application/octet-stream", "text/plain; charset=dropbox-cors-hack".
We are using Virtualmin 6.08 Professional and Webmin 1.932 on an up-to-date (and rebooted) CentOS 7 x64 system. Additionally, we have encrypted backups enabled.
Submitted by andreychek on Mon, 10/21/2019 - 09:23 Comment #8
Thanks for letting us know!
That did fix the issues we were seeing with Dropbox on our own system, but if you're still seeing issues there, we'll get Jamie's thoughts on that so we can get to the bottom of it.
Submitted by stevepisg on Mon, 10/21/2019 - 22:48 Pro Licensee Comment #9
I am seeing a similar message: "Uploading archive to Dropbox .. .. upload failed! Error in call to API function "files/upload": Bad HTTP "Content-Type" header: "application/x-gzip". Expecting one of "application/octet-stream", "text/plain; charset=dropbox-cors-hack"."
Submitted by CrankyCronos on Wed, 10/23/2019 - 02:48 Pro Licensee Comment #10
The upgrade and/or fix produced no joy for me. The same issue is continuing.
Submitted by andreychek on Wed, 10/23/2019 - 09:57 Comment #11
Thanks for your reports! I'll pass that along to Jamie.
Submitted by andreychek on Thu, 10/24/2019 - 10:22 Comment #12
Okay, Jamie thinks he was able to find that issue.
In the Virtualmin path (either /usr/share/webmin/virtual-server/pro, or /usr/libexec/webmin/virtual-server/pro), there are two files to edit.
The first is "dropbox-lib.pl". On line 208, it looks like the following:
$authheaders);
Change that to read:
$authheaders, "application/octet-stream");
Next, edit "google-lib.pl" -- there's two lines to edit here.
On line 158, you'll see this:
$timeout, $osdn, $nocache, $headers) = @_;
Change that to read:
$timeout, $osdn, $nocache, $headers, $forcemime) = @_;
And then on line 179 you'll see:
push(@headers, [ "Content-type", &guess_mime_type($file) ]);
Change that to read:
push(@headers, [ "Content-type", $forcemime || &guess_mime_type($file) ]);
Of course, you'd definitely want to make backups of those before changing them.
Once those changes are done, restart Webmin with "service webmin restart".
We'll also be pushing out an update containing those changes, though it'd be great to know if the above works for you.
Submitted by JEMEDIACORP on Thu, 10/24/2019 - 13:38 Pro Licensee Comment #13
Thanks for this update. I've implemented the changes on our Virtualmin systems; we have backups scheduled for midnight each day so once the next one runs I'll update this post noting whether it was successful.
Submitted by JEMEDIACORP on Fri, 10/25/2019 - 09:25 Pro Licensee Comment #14
The fix worked! Our backups to Dropbox are now working without a hitch :) and we really appreciate the Virtualmin guys for their prompt resolution to this important issue.
Submitted by andreychek on Fri, 10/25/2019 - 09:41 Comment #15
That's fantastic, thanks for letting us know! I'll work with Joe to get that pushed out in a new Virtualmin version as soon as possible.
Submitted by JEMEDIACORP on Thu, 11/21/2019 - 22:18 Pro Licensee Comment #16
Hi,
So unfortunately it seems there's been a regression of some sort and now the fix given above for the Dropbox backup issue is no longer working for us. We've moved to a new CentOS 7 server and a new installation of Virtualmin, then restored all our existing domains and Virtualmin configuration settings from a backup. After changing settings to fit our new server and getting everything up and running and all Websites back online, I tried to do a manual full backup to Dropbox just a few minutes ago and got the following error:
Uploading archive to Dropbox .. .. upload failed! JSON decoding failed : malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at /usr/libexec/webmin/virtual-server/pro/dropbox-lib.pl line 241. (performed 3 attempts)
The files we were directed to edit in comments above are exactly as they should be, and as I said this is a fresh Virtualmin 6.08 installation on a fresh CentOS 7 x64 install.
Submitted by andreychek on Thu, 11/21/2019 - 23:26 Comment #17
Howdy -- thanks for contacting us!
The latest Webmin and Virtualmin versions should have all those fixes.
Just to verify, what output do you receive when running these commands:
rpm -qa | grep webmin
rpm -qa | grep virtual-server
Submitted by JEMEDIACORP on Thu, 11/21/2019 - 23:28 Pro Licensee Comment #18
[root@web1-newark ~]# rpm -qa | grep webmin
webmin-1.932-1.noarch
[root@web1-newark ~]# rpm -qa | grep virtual-server
ust-virtual-server-mobile-2.1-1.noarch
wbt-virtual-server-mobile-2.5-1.noarch
wbt-virtual-server-theme-9.4-1.noarch
ust-virtual-server-theme-6.9-1.noarch
wbm-virtual-server-6.08-2.noarch
Submitted by andreychek on Fri, 11/22/2019 - 22:28 Comment #19
Thanks for the info!
I haven't been seeing that myself, but I'm passing this along to Jamie to see if he has any thoughts as to what may cause that.
Submitted by JEMEDIACORP on Fri, 11/22/2019 - 22:32 Pro Licensee Comment #20
Thank you for looking into this issue for us. If you'd like remote access into our new Virtualmin machine we can provide that. Also, as an additional update, we ran our first automatic, incremental nightly backup last night and that failed as well with the same Dropbox error message as the automatic full backup I tried to run previously. I thought maybe something was just askew with my manual backup but the automatic backup is failing with the same error as well.
Submitted by JamieCameron on Sat, 11/23/2019 - 13:41 Comment #21
Yes, remote access to a Virtualmin system that is experiencing this issue would be really useful.
Submitted by JEMEDIACORP on Sat, 11/23/2019 - 13:45 Pro Licensee Comment #22
I've just set up remote access on my system, and Virtualmin reported that it sent access information via e-mail. You can connect to the hostname web1-newark.jemediacorp.com. Let me know if you need anything else :) we've already set up scheduled backups to go to Dropbox so you can run them to test the error we are experiencing. Thanks for your help! :)
Submitted by JEMEDIACORP on Sun, 11/24/2019 - 00:38 Pro Licensee Comment #23
As an additional note the IP of our new Virtualmin server is 45.79.158.84.
Submitted by JamieCameron on Sun, 11/24/2019 - 00:37 Comment #24
Thanks! I was able to find the bug that causes this and patch it on your system. The same fix will be included in the next Virtualmin release.
Submitted by JEMEDIACORP on Sun, 11/24/2019 - 23:30 Pro Licensee Comment #25
I can confirm this bug has now been fixed - we ran a full backup to Dropbox today as a test and it was successful with no uploading errors. Thanks so much for fixing this bug and we look forward to its inclusion in the next Virtualmin release :)