Hi for the last two weeks or so Odrive has been failing to sync. I have been unable to spot anything obvious. Can anyone help?current_odrive_status.txt (6.7 MB)
Thanks for providing the status file.
From the status file it looks like there are many items within a shared folder that you have tried to delete, but Google is rejecting these requests. This is generally because Google doesn’t allow deletes via their API of items that are “shared”.
You can see these items listed in the status file under “Trash”. Do you know what the story is with these files?
Additionally, there are a bunch of Google Doc files that look like they could’ve been copied from another location and cannot be uploaded. This is because Google Docs files are not “real” files, and only exist in Google’s cloud, so they cannot be duplicated/copied to other location via odrive.
Do you know where these files came from?
Once we are able to get the above two things worked out we can see if there is anything else that needs to be addressed
- That make sense as virtually everything on our Google Drive is shared. Is there anything we can do about that? We have odrive running a lot of places with this same situation of everything being shared.
- Again, possibly the case as users are moving docs around on the server and then this is syncing up to Google Drive.
This is tricky. For standard shared items, Google only lets the owner of a file actually perform a delete. So if a file is shared with you and you try to delete it, the request will be rejected.
Google seems to handle this by essentially “orphaning” the file by removing the parents. This makes the file disappear from the shared folder and, instead, it suddenly appears in the root of the file owner’s drive. Since that behavior is also pretty odd, we haven’t tried to go that route yet, but I suppose it could possibly be an advanced option.
The better solution is to use Google’s “Shared Drives” (previously known as “Team Drives”). These allow for more options including giving “content management” rights to users so that they can delete items and they will go into a specific recycle bin for that Shared Drive.
Moving around, in general, is okay. However, moving things between shared folders can get pretty tricky, again, because things can be moved in and out of views of other users if not everyone has the same exact access to shared items that the mover does.
In this case it looks like all of the “not allowed” items are Google Docs that odrive is seeing as “new”. So these could’ve been copied from somewhere else, or moved from another location that odrive wasn’t able to properly detect as a move (across mounts or accounts, for example).
A few questions:
I tried to look back at some previous tickets, but I wasn’t able to get a good sense for how things are setup between you and your users. Can you explain the environment a bit and how your users are interacting with it?
For example: Are you using a single Google Drive account as the “master” and then sharing specific folders from that to other Google Drive users?
Does your account have access to Google “Shared Drive”/“Team Drives”?
The sync activity logs will be able to provide some more information as to how some of these files came to be in their current states. You can access these logs from
C:\Users\administrator.WELLINGTON\.odrive\log\. If you zip up that folder and message it to me (click on my name and then click on “Message”, I can take a look.
Thanks very much for your help Tony and I understand what you are saying.
In terms of our setup, yes, we have 1 master account with all of the folder structure created and this is shared out to the staff, mainly through groups. They then access these areas, create, edit and delete items. I understand that the problem you describe is probably arising when the staff create something as I believe they then become the owner, even though it is created inside the ‘masters’ folder.
I also understand what you are saying about Shared Drives but unfortunately for most of our clients, there is a fundamental shortcoming of shared drives and that is the lack of ability to change security on sub folders. We always have a situation whereby we want to give staff read only access to the root folder but then write access below that. Shared drives does not support this.
I will send you the log file.
Hi @wellington ,
My apologies, I lost track of this issue. I responded to your direct message if you want to take a look, when you get a chance.