Bug? rclone error on trying to delete file it has Read Write access but different owner

Suspected Bug
1

So I have my rclone setup with vfs-cache-mode writes with the following setting.
rclone mount in Linux, by Google user C. then do:

root@jupiter:~# rm -rf /mnt/Gdrive/movies3/I.Tonya.2017.DVDSCR.750MB.MkvCage.mkv
rm: cannot remove ‘/mnt/Gdrive/movies3/I.Tonya.2017.DVDSCR.750MB.MkvCage.mkv’: Input/output error

see screenshot:

movies3 folder and the file above is owned by Google user A, Google user C and R have full access read,write,delete etc.

In the past, I could do operation above with no problem for the same setting. However current rclone setup throws error above.
The work-around is always the same, I have to use GDrive web UI or google Drive File Stream on Windows, Login to any user C,A or R and delete from there. It is very annoying because many times I have to delete unnecessary movies, bad version, duplicate, wrong movies etc from Plex webUI.
Since Rclone has this bug(?) I can’t do that anymore… from Plex webUI or from linux command line I can only delete files owned by Google User C.

2

What is the corresponding error in rclone’s log?

Rclone will just be using the credentials you gave it to call the delete API so the problem will be in the credentials rather than rclone I think. There don’t appear to be any special parameters in the drive API delete call.

3

rclone[8616]: 2018/06/06 12:02:23 ERROR : movies3/I.Tonya.2017.DVDSCR.750MB.MkvCage.mkv: File.Remove file error: googleapi: Error 403: The user does not have sufficient permissions for this file., insufficientFilePermissions

I believe the credential is ok…? Because we are talking about the value in rclone config right? I never changed those, and there was no problem last time I did similar file operation in rclone last year.
In fact, I am logged in to Google user C in gdrive web ui, android app, and Google drive file stream in windows and rclone use Google user C. There was not a problem for Google Drive File Stream to delete that file.

Here is my config in case you find anything wrong…

`[GDrive1] type = drive client_id = redacted
client_secret = redacted service_account_file = token = {}
scope = drive root_folder_id =

Team drive = no`

Should i try to refresh my token?

4

It might be worth a try.

I don’t really know why it isn’t working so refreshing the token will make sure rclone is logged in as the user it should be and hopefully that will make it start working again :crossed_fingers:

5

Just did, and same error in log. I tried to deleted the file using Google drive android app from user C and i could delete it. I did some test, when i setup rclone config for Google user A who owns the file obviously I can delete it just fine.

6

Can you try deleting the file with rclone directly (not through the mount) with lots of logging, so

rclone -vv --dump bodies remote:path/to/file.mkv

Try with --dry-run first to check rclone is going to delete the right stuff.

That might give a clue - thanks.

7

rclone delete -vv --dump bodies GDrive1:/movies/movies3/transporter3-1920.mkv &> ncw

https://pastebin.com/2nqrXBRA

that file is owned by Google User A, rclone command was done with login info of Google User C who has full read write access to that file and folders above it.

{“trashed”:true}
2018/06/08 08:28:19 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2018/06/08 08:28:20 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2018/06/08 08:28:20 DEBUG : HTTP RESPONSE (req 0xc4201be300)
2018/06/08 08:28:20 DEBUG : HTTP/1.1 403 Forbidden
Transfer-Encoding: chunked
Alt-Svc: quic=":443"; ma=2592000; v=“43,42,41,39,35”
Cache-Control: private, max-age=0
Content-Type: application/json; charset=UTF-8
Date: Thu, 07 Jun 2018 23:28:20 GMT
Expires: Thu, 07 Jun 2018 23:28:20 GMT
Server: GSE
Vary: Origin
Vary: X-Origin
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block

11e
{
“error”: {
“errors”: [
{
“domain”: “global”,
“reason”: “insufficientFilePermissions”,
“message”: “The user does not have sufficient permissions for this file.”
}
],
“code”: 403,
“message”: “The user does not have sufficient permissions for this file.”
}
}

0

2018/06/08 08:28:20 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2018/06/08 08:28:20 ERROR : transporter3-1920.mkv: Couldn’t delete: googleapi: Error 403: The user does not have sufficient permissions for this file., insufficientFilePermissions
2018/06/08 08:28:20 ERROR : Attempt 3/3 failed with 1 errors and: failed to delete 1 files
2018/06/08 08:28:20 Failed to delete: failed to delete 1 files

and I could delete the file from Gdrive web from User C, I can confirm it being deleted from Gdrive web from user A, the file became orphan location wise ( by google design?) and then I could search and delete the orphaned file again from drive web User A and empty trash.

8

I wonder if that is the problem - trying to put the file into the users trash - Can you try using --drive-use-trash=false and see what happens?

9

2018/06/09 04:24:25 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2018/06/09 04:24:26 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2018/06/09 04:24:26 DEBUG : HTTP RESPONSE (req 0xc4203a7000)
2018/06/09 04:24:26 DEBUG : HTTP/1.1 200 OK
Transfer-Encoding: chunked
Alt-Svc: quic=":443"; ma=2592000; v=“43,42,41,39,35”
Cache-Control: private, max-age=0, must-revalidate, no-transform
Content-Type: application/json; charset=UTF-8
Date: Fri, 08 Jun 2018 19:24:26 GMT
Expires: Fri, 08 Jun 2018 19:24:26 GMT
Server: GSE
Vary: Origin
Vary: X-Origin
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block

104
{
“files”: [
{
“id”: “1FF-HdHTD4fVjKx46PxBlBoFKu8IvwYSB”,
“name”: “movies”,
“mimeType”: “application/vnd.google-apps.folder”,
“trashed”: false,
“createdTime”: “2017-12-03T03:42:11.375Z”,
“modifiedTime”: “2017-12-25T12:25:12.329Z”
}
]
}

0

2018/06/09 04:24:26 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2018/06/09 04:24:26 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2018/06/09 04:24:26 DEBUG : HTTP REQUEST (req 0xc4203a6700)
2018/06/09 04:24:26 DEBUG : GET /drive/v3/files?alt=json&fields=files%28id%2Cname%2Csize%2Cmd5Checksum%2Ctrashed%2CmodifiedTime%2CcreatedTime%2CmimeType%29%2CnextPageToken&pageSize=1000&q=trashed%3Dfalse+and+%271FF-H8HTDDr55Kx46PxfOBoFK$
Host: www.googleapis.com
User-Agent: rclone/v1.41-079-g5302e5f9β
Authorization: XXXX
Accept-Encoding: gzip

2018/06/09 04:24:26 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2018/06/09 04:24:27 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2018/06/09 04:24:27 DEBUG : HTTP RESPONSE (req 0xc4203a6700)
2018/06/09 04:24:27 DEBUG : HTTP/1.1 200 OK
Transfer-Encoding: chunked
Alt-Svc: quic=":443"; ma=2592000; v=“43,42,41,39,35”
Cache-Control: private, max-age=0, must-revalidate, no-transform

…
…
…

2018/06/09 04:24:51 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2018/06/09 04:24:51 DEBUG : HTTP REQUEST (req 0xc4203a6d00)
2018/06/09 04:24:51 DEBUG : DELETE /drive/v3/files/4WWJZ1zxBKWIieOnOnneQxDe9pcVzMFGR?alt=json&fields=&supportsTeamDrives=false HTTP/1.1
Host: www.googleapis.com
User-Agent: rclone/v1.41-079-g5302e5f9β
Authorization: XXXX
Accept-Encoding: gzip

2018/06/09 04:24:51 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2018/06/09 04:24:52 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2018/06/09 04:24:52 DEBUG : HTTP RESPONSE (req 0xc4203a6d00)
2018/06/09 04:24:52 DEBUG : HTTP/1.1 403 Forbidden
Transfer-Encoding: chunked
Alt-Svc: quic=":443"; ma=2592000; v=“43,42,41,39,35”
Cache-Control: private, max-age=0
Content-Type: application/json; charset=UTF-8
Date: Fri, 08 Jun 2018 19:24:52 GMT
Expires: Fri, 08 Jun 2018 19:24:52 GMT
Server: GSE
Vary: Origin
Vary: X-Origin
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block

11e
{
“error”: {
“errors”: [
{
“domain”: “global”,
“reason”: “insufficientFilePermissions”,
“message”: “The user does not have sufficient permissions for this file.”
}
],
“code”: 403,
“message”: “The user does not have sufficient permissions for this file.”
}
}

0

2018/06/09 04:24:52 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2018/06/09 04:24:52 ERROR : sector7-transporter2.1080p-x264.mkv: Couldn’t delete: googleapi: Error 403: The user does not have sufficient permissions for this file., insufficientFilePermissions
2018/06/09 04:24:52 ERROR : Attempt 3/3 failed with 1 errors and: failed to delete 1 files
2018/06/09 04:24:52 Failed to delete: failed to delete 1 files

10

Thanks for testing that.

The only thing I can think of is that it is something to do with the drive authorisation…

Can you try remaking the remote, but when rclone opens the browser window, go back to the terminal and copy the URL into an incognito window in Chrome (or whatever your browser calls it) and do the authentication there? I find that helps to be 100% sure what credentials you are using to authenticate rclone.

11

That’s how I do it all the time. This is headless server so I always copy the url into incognito window.
Is there api difference between what rclone uses and the one gdrive apk uses?

12

Am I the only one having the problem and no one else can reproduce it? It’s very easy to reproduce.

In My Drive folder create folder A by user A. In user B account, in My Drive folder create folder B by user B. Share the folder B to user A, give user A full read write access. User A accept the share, Add To My Drive and then move it to inside folder A. So the hierarchy is /My Drive/A/B.
User B upload content to folder B.
User A try to delete that content from rclone.

Is this a question that no one else can replicate this bug(?)
Or a question of change in recent Google api,
Or a question of limitation of public Google api?

13

I used your instructions and I can reproduce the problem perfectly - thanks.

However I don’t see how it can be an rclone bug - rclone is calling the correct API and there aren’t any extra parameters I could be passing.

I tried the delete with v1.28 (2016-03-01) which was the oldest I have lying around and that failed in the same way. So whatever has happened it isn’t due to recent rclone code changes.

I suspect one of these…

It might be worth trawling https://issuetracker.google.com/ to see if you can find anything relevant - I couldn’t :frowning:

There looked to be some kind of relevant things on stack overflow too.

14

Yes… I think there is some funky things going on with Public API. I still can delete the files if I use Google Drive android app or Google Drive File Stream on Windows, but can’t delete them using rclone or any other app that uses public API.
I guess this is Google way of saying that I should have used Team Drive instead of Shared Folders

15

Hmm, so Google’s own apps are using some non public API…

It would be worth reporting an issue ( https://issuetracker.google.com/ ) you may get some feedback at least.