I have 2 teamdrives (TD1 and TD2)
and two service accounts (SA1 and SA2)
By default SA1 is used on TD1's remote and SA2 is used on TD2's remote.
both SA's have "content manager" permissions on both teamdrives (full read/write/delete access)
Normally I never run into any permissions problems, but suddenly in this scenario...
SA1 copies some data from my PC to TD1. SA2 wants to MOVE that data to TD2
then...
Couldn't move: googleapi: Error 403: The user does not have sufficient permissions for this file., insufficientFilePermissions
SA1 is the owner of the files after they have copied to TD1 of course, but both accounts have full permissions both places (I even tried full manager/admin without any luck), so I don't understand why SA2 would not be permitted to move the files (I presume it's the delete part of move that is actually failing).
Copying the data the same way => OK
Deleting the data directly => OK (but I guess this is TD1 doing this action normally).
I have not tried setting up a test-remote with SA2 to TD1, and delting them directly that way... I will test that and update.
The above examples have been simplified to make it easier. This is the full un-shortened command that fails for me, but I am at this point pretty certain none of the other stuff is related to the permissions error.
@ncw@Animosity022@darthShadow - I would really appreciate your input if you think you can help or provide me with guidance on what to test to troubleshoot this
But I can't understand if manager permission is required though... since "content manager" specifically says it allows delete. Giving these accounts "manager" will let them add or remove users - which seems not only overkill but also a security risk. I will of course try anyway though.
Server-side is enabled in config on both. I should probably have mentioned that.
I think I tried that, but I will test again. Not cleaning up empty folders would be pretty messy anyway ... I hope that is not something I will have to work around in the end.
Well there we go ... Manager does indeed solve it (it is only needed on the acting SA it seems, which in this example is SA2)
No other change was needed in the command to make it work.
Thank you so much @darthShadow This was such an illogical thing that I would have taken forever to puzzle it out myself. I don't see WHY this is needed, but it apparently is.
I'm still not quite satisfied about this needing manager status though. If ever a SA should be exposed somehow that will let someone steal your entire drive... (not jus the data on it). Unlikely perhaps if you take normal precautions, but I don't like shortcutting such crucial security features just to make stuff work - especialyl when it shouldn't logically need this to work in the first place.
@ncw Can you comment on this? Is it possible that rclone is asking the API in a wrong way or something in this spesific condition? Because I just don't see how "manager" status would be needed. AFAIK "manager" should just be for controlling the user access-list. "Content manager" should be able to do anything it wants with any files.
Or could we perhaps implement a workaround for it where during a MOVE operation, the DEST. remote is used for the copying part, but the SOURCE remote is used for the deleting part? Would that be a good idea? It does seem like this approach would require less cross-access of permissions (a common question/problem that users have). For example, the various SAs would only need to have write-permissions on their own drives - rather than on every drive (they would only need read). That would be a much safer setup obviously as one rogue account could not decimate all data.
The current implementation for server-side copies uses a single request to add and remove drive/folder IDs. This could be the cause for needing manager permissions but not 100% sure about it.
ah, so it is currently done in a single API call? I understand why it was done this way then.
But maybe Gdrive requires a different approach due to it's permissions system or something. The exact details of that is a little above me, but I'm sure Nick will have some input on it. In any case... I have a temporary solution for now I guess - and hopefully we can solve it more elegantly later.
Thanks again for the help - and your acumen in identifying the niche problem exactly. I knew you were the right man to call on
Well I "solved" this ultimately by splitting of this spesific process into my normal manager account - so it can do this particular step. A messy solution, but it does work without the security downsides.
Rclone will be calling the server side Move api which does the move in one operation. It will call that operation using one of the SAs (the destination one I think).
What you could try is adding --disable Move to stop rclone doing server side moves then rclone will use a server side Copy + a Delete to do the operation which may work better...
Hmm... I will try. If the delete doesn't fail then that should work.
But this will effectively double the operations then right? If so I think my current solution is more optimal, at least for this spesific scenario.
