Dropbox backup (partial) failure

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

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.

I have this happening too. Any word on its cause or a possible fix?

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.

That's cool. You guys rock.

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! :)

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.

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.

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"."

The upgrade and/or fix produced no joy for me. The same issue is continuing.

Thanks for your reports! I'll pass that along to Jamie.

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.

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.

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.

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.

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.

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
[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
Assigned: Unassigned ยป

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.

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.

Yes, remote access to a Virtualmin system that is experiencing this issue would be really useful.

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! :)

As an additional note the IP of our new Virtualmin server is 45.79.158.84.

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.

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 :)