I recently installed Odrive to sync some files but I’ve been getting the error in the title every time I do. This isn’t the only program that’s giving me problems with Amazon cloud drive.
This indicates that there is an issue occurring within the Amazon service, but it is something that is not “expected”. It is possible they are having some technical difficulties at that time.
Are you still seeing this issue? Are you able to use their web client?
The cloud drive app to upload files? I was having a ton of problems with it not listing any folders. I also tried using ExpanDrive and Netdrive to no success. I was actually not having any problems with the service at all or with any of the apps I said for at least 2 months then all of a sudden… problems.
Sounds like they are having issues with your account. I would suggest contacting Amazon Cloud Drive to look into it.
Already did twice. Both times they said that it’s on my end and there’s nothing wrong on their’s.
I would concentrate on highlighting where their own application is failing to list folders properly or behave properly, which you mentioned above. They can’t really claim it is on your side given that behavior.
Does their web application have issues too? https://www.amazon.com/clouddrive
Was there any resolution to this? I am receiving the same “Amazon Cloud Drive internal server error” error.
Anecdotal at this point, but I’m seeing the error with my Infinite File Size (IFS) files that I uploaded. I do not get the same sync error when I sync other files. I have synced a dozen other files of varying sizes with success (not as large as the 138 GB IFS file and 167 GB IFS file where I am seeing the error, but some reasonably sized files).
I am seeing an error when using the Amazon Cloud Drive (ACD) web application too. For some reason, even if I only select one or two of the IFS split files to download, ACD still presents the following download limit error saying that I can’t download over 5 GB or 1000 files at a time. I’m only selecting two 100 MB files out of the total 1,258 IFS files.
If I go to a TM backup that I made and select just two of the files there, ACD web app downloads them just fine.
I have no idea what I’m talking about here technically speaking, but it seems like Amazon is reading the meta file or something and thinking there are over 1000 files to download no matter what, or more likely that they total over 5 GB.
I also started getting this error:
So far, it does not seem to like the IFS files, which would be a real bummer as that’s the reason I signed up for odrive. I realize this post was started though before you ever launched IFS, so I am optimistic that it’s really something else.
The web app has now seemed to clear that error, at least for small number of files. (Can’t try it over 5GB of course without downloading their app.) I get the zip file created successfully by ACD download process now. I’m going to have to try downloading the IFS file again once I get home to the machine set up with odrive and see what happens.
Same error after retrying, and confirmed that ACD web app is working fine for all files, including IFS.
If you are still seeing this issue on the odrive desktop client, can you send a diagnostic from the tray menu? I will see if we can figure out what the underlying issue is. It sounds like ACD was having issues earlier today, but those seem to have cleared now.
Unfortunately, same issues. Even using Amazon Drive, I get a permissions error. But when I download the file individually from ACD, it works fine, the zip file gets created and downloaded. It is not working as a group download it seems.
I’d like to mention all worked fine with my original 168 GB IFS file the first time I tried that. It uploaded successfully as did this latest IFS file, and I was able to download it (resync placeholder using odrive) and restore the disk image it contained. I just don’t know why it has stopped working, and if it is ACD by itself or odrive causing the issue, or ACD failing when accessed by odrive, etc.
Now I’m getting the following when double clicking the .cloud placeholder on external hard drive (H1), even for the original large file that was successful before:
I will send a diagnostic.
Did you rename or move the remote folder that the local “sync to odrive” folder was mapped to? The mapping needs to stay the same for odrive to continue syncing from local to remote.
No, but it is an external hard drive, maybe my laptop thinks it’s changed. But no, I didn’t move it.
I restarted the laptop. Now sync is back, odrive recognizes the file again, and can try to start the sync… but same amazon internal error is back.
There are probably multiple things going on here. There may have been issues at ACD, as I successfully downloaded the 1st IFS file. However, the second still renders an error. For that one, the disk image was compressed and encrypted, so we need to consider that but I doubt that’s it. The other difference is that I split at 100 MB instead of 2 GB, again unlikely but needs to be considered. The most likely difference that matters is that I had to reboot during the 2nd IFS file’s upload process, so the IFS process was interrupted. When I came back up, odrive had one of the uploading files in it’s trash. I thought we needed to clear that so I emptied the trash, clearing it from ACD. Then, I restarted the sync or let it restart, I can’t remember. I suspect that IFS may not have successfully adapted to the interruption nor managed the interrupted and deleted file successfully. I’m now going to try uploading that same file again.
So what I had noticed in the diagnostic was that the “sync to odrive” folder was reporting that the remote location that 2 of the local folders were mapped to no longer existed. Generally this happens if its moved or renamed. This could’ve been a result of Amazon Drive issues.
Can you send another diagnostic and let me know what the file name is of this particular file you are still having issues with?
IFS should be able to recover from any partial upload issue, so an interruption should be no problem at all.
NOTE: corrected folder paths and image, see below note as well.
Hi Tony, sending another diagnostic. The name of the troublesome file is "TIMEMACHINE1 -LUKE MBP BAK 16-0625.dmg’
I made a new file as I said I would, and I’ve noticed odrive seems to create mutliple instances of the same file when I sync (TIMEMACHINE1 -LUKE MBP BAK 16-0703.dmg.cloud):
There’s a copy of the new cloud file here:
/Volumes/LUKE-LrgFiles/TIMEMACHINE1 -LUKE MBP BAK 16-0625 Image/TIMEMACHINE1 -LUKE MBP BAK 16-0703 Image/TIMEMACHINE1 -LUKE MBP BAK 16-0703.dmg.cloud
When I didn’t sync there. I synced “from” here (Update- realized I copied and pasted incorrectly the first time. This is corrected folder path, which now matches the original image which I have not changed - Wait, dang it, the image was wrong too, sorry, I’m not a Mac user and must have messed up the cut and paste putting the same things in both places. The image is right now too showing the different location and syncing dmg file with sync icon, and you will note the different modified times above versus here.):
/Volumes/LUKE-LrgFiles/TIMEMACHINE1 -LUKE MBP BAK 16-0703 Image/TIMEMACHINE1 -LUKE MBP BAK 16-0703.dmg
I never moved any files or folders myself, I realize you said ACD might be doing it, but I wanted to confirm that with you.
I’m syncing up to ACD the new compressed and encrypted disk image as we speak. It will take 4 days or so before I can tell you if this one worked or not. If you see something in the diagnostics or code before then, please let me know. Thanks
FYI, over half-way through the sync/“upload” process now. Nothing to comment on from reviewing the diagnostics? Thanks
The new diagnostic does not show the errors I saw previously. Since you have not changed anything, it looks like ACD was definitely having issues during that time. The previous diagnostic was reporting that certain remote folders were inaccessible and now those errors do not show up anywhere…
Let’s see how things work out for the current test.
Sending new diagnostic… same error with new file, 0703 file.internal server error when trying to re-sync after unsync.
Looks like its getting a read timeout on the request. Do you know what the split was on that file and how large it is?
Split = 100MB (The time the split worked, it was set at 2 GB… both times failed at 100MB)
Total file size = 131.8 GB on MBPro laptop locally, ~125.8 GB total on Amazon / ACD
ACD = 125.8 GB figured out by the following:
1,256 files at max 100 MB split
1 “remainder” file topping out at 99.2 MB
1 meta file at 136.5 KB