Jump to content
  • 0

Google Drive: Cant Upload, 'The requested mime type change is forbidden'


Jonathan

Question

My setup is:  30TB via single google drive cloud drive.  That's broken up into two 15TB NTFS partitions, using 7TB on one and 4TB on the other.  Everything was working fine... but about a week or so ago i started to get thousands of errors: "The requested mime type change is forbidden".  This occurs when uploading.  I have about 40GB sitting in my 'To Upload' and it hasn't moved in a week, even though the upload rate has been over 100mbps, practically constantly.  Any ideas what this error is and how to fix.  I think I have tried everything I can on my end, reauth, etc... Thanks.

Link to comment
Share on other sites

Recommended Posts

  • 0

I had this issue and filed a ticket. They are looking at it. 

 

Are you using encryption? I was not originally, I destroyed that drive, made a new one with encryption and I have not seen this issue since. (however it has only been a day or two instead of over a week)

 

My guess was that Google was categorizing the chunk as say....a video, maybe because that chunk happened to contain the header of an actual video file I was uploading. Then, when a block in that chunk changed, and Cloud Drive tried to re-upload that chunk, Google Drive denied the re-upload since it saw the new chunk was no longer categorized as a video (no clue why Google would deny this). I theorized that if I used encryption, Google would never be able to categorize the chunk as a video and the problem may go away.

 

This is all a theory that is working so far in the short time I've tried it.

Link to comment
Share on other sites

  • 0

yes, this is something that we are aware of and looking into. 

 

 

I had this issue and filed a ticket. They are looking at it. 

 

Are you using encryption? I was not originally, I destroyed that drive, made a new one with encryption and I have not seen this issue since. (however it has only been a day or two instead of over a week)

 

My guess was that Google was categorizing the chunk as say....a video, maybe because that chunk happened to contain the header of an actual video file I was uploading. Then, when a block in that chunk changed, and Cloud Drive tried to re-upload that chunk, Google Drive denied the re-upload since it saw the new chunk was no longer categorized as a video (no clue why Google would deny this). I theorized that if I used encryption, Google would never be able to categorize the chunk as a video and the problem may go away.

 

This is all a theory that is working so far in the short time I've tried it.

 

 

Specifically, they are probably reading the file header, and trying to determine the mime type based on that. Amazon Cloud Drive does this regardless of the type of data we specify, as well.  If this is what is happening, then it means updating the provider to fix the issue.

 

in the meanwhile, encrypting the drive may significantly reduce the changes of this happening. 

Link to comment
Share on other sites

  • 0

Getting this on my encrypted drive now :( No solution to this ? Do i really have to create a new drive?

Basically, yes, you need to create a new drive to fix the issue. 

 

Alex has a new build that should fix this issue:

http://dl.covecube.com/CloudDriveWindows/beta/download/StableBit.CloudDrive_1.0.0.444_x64_BETA.exe

 

However, this basically prepends a null bit to each chunk. For a few reasons (compatibility, in case it's a legitimate character, etc), we can't just convert the drive over.  Sorry. 

 

And prepending the null bit should/will block Google from reading the mime type (well, error out on it, and see it as just binary data, which is what we want). 

Link to comment
Share on other sites

  • 0

Not possible to have a public post just saying the issue ? :-) "issue with the requested mime type change is forbidden" for example. Of course if it's a big hazzle you can leave it be

Well, there is a reason for that. :) 

https://stablebit.com/Admin/IssueAnalysis/23907

 

Somebody posted it in a contact thread/ticket, so it got flagged there first. 

 

And it doesn't seem to be as common of an issue with Google Drive. And IIRC, Alex changed something on the backend, to make this basically a switch we can toggle per provider, rather than rewriting the provider code. But it would be nice if it was an API option (eg, "don't index this file" flag or something, but that's not likely for a number of reasons).

 

And if you mean the issue with Amazon Cloud Drive, that's not just one issue. That's a list of issues, ongoing, semi-ridiculous all things considered, and some bad handling on their end. 

Link to comment
Share on other sites

  • 0

I'm the one the filed the ticket. Blew away my drive, upgraded to .444, created a new drive, encrypted, still seeing this issue.

 

I've only seen it happen with windows server backup.

 

Deleting the chunk manually fixed it, the chunk was indeed tagged in Google Drive as "Binary File"

Link to comment
Share on other sites

  • 0

To make sure, once you've deleted the chunk manually, it fixed the issue?

If it comes back, then definitely let us know.

 

And even if google is reporting it as a binary file, they are likely reading it to auto-organize it, or at least identify it for their backend (most providers use some sort of deduplication, or at least I'm guessing.... as this can save PBs of space in their data centers, staving on space, drives, cooling, etc).

Link to comment
Share on other sites

  • 0

To make sure, once you've deleted the chunk manually, it fixed the issue?

 

If it comes back, then definitely let us know.

 

And even if google is reporting it as a binary file, they are likely reading it to auto-organize it, or at least identify it for their backend (most providers use some sort of deduplication, or at least I'm guessing.... as this can save PBs of space in their data centers, staving on space, drives, cooling, etc).

 

Deleting absolutely resolved the issue. I was stuck in 1 thread, uploading that same chunk over and over, getting the MIME error every time. I found the chunk in Google Drive, deleted it, deleted it from the trash. Within less than a second or two the chunk uploaded successfully and I immediately went back to uploading 10 threads full speed.

Link to comment
Share on other sites

  • 0

I started getting the mime error so I restarted my server and now stablebit asks for my encryption key then says recovering then goes to the normal stablebit screen where you can create a new drive.  Can you please assist me in trying to get this drive to mount again?  I have over 10TB on this drive and would really like to be able to recover it.  Thanks.

Link to comment
Share on other sites

  • 0

I started getting the mime error so I restarted my server and now stablebit asks for my encryption key then says recovering then goes to the normal stablebit screen where you can create a new drive.  Can you please assist me in trying to get this drive to mount again?  I have over 10TB on this drive and would really like to be able to recover it.  Thanks.

 

What OS is this and what version of StableBit DrivePool are you using specifically?

 

And by the screen you mean, I'm assuming you mean the default "connect and add/attach" drive screen? 

 

If so, does the drive in question show up here? 

 

And could you grab the logs from the system and upload them?

http://wiki.covecube.com/StableBit_CloudDrive_Log_Collection

Link to comment
Share on other sites

  • 0

I am running Windows Server 2012 R2 64bit.  The issue came up when I was on Cloud Drive version 1.0.0.454 and is still occurring after updating to version 1.0.0.463.  I get the option to unlock the drive and after I type in my encryption key the drive tries to mount then fails.  I have uploaded the logs as requested on your support upload page.


 


Here is what it looks like after I Unlock it with my Encryption Key.


k7elF54.jpg


 


Here is what it looks like after about 30 seconds


KheAwCo.jpg


Link to comment
Share on other sites

  • 0

I created a new drive using the latest verison 1.0.0.463 and got about 500GB uploaded to it and now i'm getting the same mime error.  Back to square one.

 

This scares the crap out of me to even use stablebit cloud drive even when it does come out of beta.  One thing goes wrong and you lose all data that is in a proprietary format.  I may need to stick with my old process of using netdrive and boxcryptor. :( Unfortunately I already paid for the program.

 

EDIT: The data is sitting there in chunks on my google drive.  It would be really nice if there was something implemented where if a major failure happened, we could somehow import the chunked data in to a new drive.  It doesn't make a whole lot of since that you lose all of your data just because an error in the software when all of the data is still there.

Link to comment
Share on other sites

  • 0

Any update on deleting these chunks when this happens? I hit this on 3 chunks today. Deleted them manually and all went back to normal. The updated chunks are on the local disk, having stablebit delete the chunk on google drive and upload the updated chunk when this error is hit shouldn't be an issue. Note: It appears a permanent delete is necessary (delete from Trash too).

 

It's just an annoyance because my upload ground to a halt for 12 hours before I logged into my server and saw I was hitting this error in an infinite loop and fixed it manually.

 

Edit: I'm using .463, encryption, the new version that appended the null byte, etc all seem to have reduced this from occurring but definitely do not solve the problem completely.

Link to comment
Share on other sites

  • 0

I created a new drive using the latest verison 1.0.0.463 and got about 500GB uploaded to it and now i'm getting the same mime error.  Back to square one.

 

This scares the crap out of me to even use stablebit cloud drive even when it does come out of beta.  One thing goes wrong and you lose all data that is in a proprietary format.  I may need to stick with my old process of using netdrive and boxcryptor. :( Unfortunately I already paid for the program.

 

EDIT: The data is sitting there in chunks on my google drive.  It would be really nice if there was something implemented where if a major failure happened, we could somehow import the chunked data in to a new drive.  It doesn't make a whole lot of since that you lose all of your data just because an error in the software when all of the data is still there.

 

Unless you've encrypted it, it is "mostly" raw drive data. 

 

As for a recovery tool/procedure, I believe that this has been brought up before, but I'll flag this for Alex, as yes, I think we definitely do need something like that. 

 

As for the mime error specifically, was this drive created before the 1.0.0.444 version?  

If so, then the  fix isn't actually applied to the specific drive (this is because it's technically an architectural change and we don't want to "brute force change" this for drives, as it can cause even more issues). 

 

If you are sure this drive was created with the 1.0.0.444 build or later, then please let me know and if you could enable logging if/when it happens again?

http://wiki.covecube.com/StableBit_CloudDrive_Log_Collection

 

Any update on deleting these chunks when this happens? I hit this on 3 chunks today. Deleted them manually and all went back to normal. The updated chunks are on the local disk, having stablebit delete the chunk on google drive and upload the updated chunk when this error is hit shouldn't be an issue. Note: It appears a permanent delete is necessary (delete from Trash too).

 

It's just an annoyance because my upload ground to a halt for 12 hours before I logged into my server and saw I was hitting this error in an infinite loop and fixed it manually.

 

Edit: I'm using .463, encryption, the new version that appended the null byte, etc all seem to have reduced this from occurring but definitely do not solve the problem completely.

 

Was the drive created before the 1.0.0.444 build? 

 

And if/when this happens again, could you enable logging:

http://wiki.covecube.com/StableBit_CloudDrive_Log_Collection

Also, created a ticket for this already, and have marked as critical:

https://stablebit.com/Admin/IssueAnalysis/25923

Link to comment
Share on other sites

  • 0

Unless you've encrypted it, it is "mostly" raw drive data. 

 

As for a recovery tool/procedure, I believe that this has been brought up before, but I'll flag this for Alex, as yes, I think we definitely do need something like that. 

 

As for the mime error specifically, was this drive created before the 1.0.0.444 version?  

If so, then the  fix isn't actually applied to the specific drive (this is because it's technically an architectural change and we don't want to "brute force change" this for drives, as it can cause even more issues). 

 

If you are sure this drive was created with the 1.0.0.444 build or later, then please let me know and if you could enable logging if/when it happens again?

http://wiki.covecube.com/StableBit_CloudDrive_Log_Collection

 

 

Was the drive created before the 1.0.0.444 build? 

 

And if/when this happens again, could you enable logging:

http://wiki.covecube.com/StableBit_CloudDrive_Log_Collection

Also, created a ticket for this already, and have marked as critical:

https://stablebit.com/Admin/IssueAnalysis/25923

 

Yes I think I posted in this thread, right after the .444 build came out, that I blew away my existing disk that I was seeing this issue on, and created a new encrypted disk, the next day I saw the issue again. Deleting the chunk fixes the issue immediately.

Link to comment
Share on other sites

  • 0

Yes I think I posted in this thread, right after the .444 build came out, that I blew away my existing disk that I was seeing this issue on, and created a new encrypted disk, the next day I saw the issue again. Deleting the chunk fixes the issue immediately.

Okay, thanks for confirming.

 

I've just talked with Alex directly about this.  The next time this occurs, could you grab and download the actual chunk before deleting it, and upload it to us? 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...