I'm in a bind here. I've attempted to remove a folder that I created within a folder that I also created. This entire collection of data was my own doing on a single account. Unfortunately, one of folders has decided it owns the place and is now giving me the following errors.
While trying to purge a sub folder within a folder I get this error:
2019/12/06 14:11:45 ERROR : Attempt 1/3 failed with 2 errors and: googleapi: Error 403: The user does not have sufficient permissions for this file., insufficientFilePermissions
^[[D2019/12/06 14:11:46 ERROR : Attempt 2/3 failed with 2 errors and: googleapi: Error 403: The user does not have sufficient permissions for this file., insufficientFilePermissions
2019/12/06 14:11:48 ERROR : Attempt 3/3 failed with 2 errors and: googleapi: Error 403: The user does not have sufficient permissions for this file., insufficientFilePermissions
2019/12/06 14:11:48 Failed to purge with 2 errors: last error was: googleapi: Error 403: The user does not have sufficient permissions for this file., insufficientFilePermissions
While attempting to remove the file I get:
Input/output error
I'm a bit stuck on this, and have exhausted what I can think of. Anyone else run into this? I should clarify that this is the only folder doing this. Other folders get the IO on moving to another folder sometimes (typically the file is already there) but this one was the first to fight me on delete.
This is on Gdrive right?
I've run into some weird behaviour relating to deleting files too (in my case, the delete on a move operation to another drive) - and in my case it turned out to require manager-level access. Content-manager was not enough - which is weird since a content manager can usually delete files just fine. In my case I had files uploaded there by other accounts however, so that could maybe be part of the issue somehow.
Not sure if this is the same issue you are seeing - but worth checking perhaps.
Not exactly sure why it would act like this. It almost seems like a bug on Google's end to me. It's just very hard to know without access to more debugging info.
Yes it is. The issue is happening on files within a personal folder, not a team drive. This makes me wonder how I could have more access to the file. I did have this on a prior account that I had, but other files that have been there since that account are able to move rather easily.
On a personal drive there isn't really any permissions settings by user - outsides of shared folders, so assuming that is not used you should implicitly have manager-level access - or as full access as you can get anyway. A personal drive is directly linked to your user after all.
To fix the issue, the next thing I would try is removing the folder via the Google Drive web-interface (the Google website I mean). But maybe ahead of doing that you should run a full debug-log of this, because if that ends up working then it might indicate an issue for rclone worth making a note of. Might not be rclone's fault as it can only work within the parameters set by the API but it would be valuable information regardless - and perhaps there can be a workaround for it.
I think I might have found the issue. I move nearly everything from one folder in one gsuites group, to another in a different gsuites group. I have since shared those folders back with the original user and group (luckily I didn't delete them) but unfortunately though I'm able to access the encrypted shared-with-me I can't seem to access the decrypted....
My best guess is that it has something to do with more than one account having permissions, and then trying to delete the file with the user that is not the owner. If so then removing the original owner or somehow otherwise taking ownership-control with the other user would maybe fix the whole issue. Not entirely sure how you'd do the latter, but I'm sure there's a way.
If you can access the encrypted files then it should just be a matter of running those through a crypt remote with the right key. That all happens locally, so don't see how it could be possible to be able to access the encrypted files but not their unencrypted versions as underneath the hood they are both in fact the same file.
Hmmm, perhaps I did something wrong. So I made a new rclone remote for the old user and mounted it with the --shared-with-me flag. It works and I can see the encrypted folders. From there, using the key I've checked is correct, I've tried decrypting the remote, but I get 0 for files available. Please see below:
Config
[s0n1cm0nk3ymedia]
type = drive
client_id =(removed)
client_secret = (removed)
token = (removed)
root_folder_id = (just pressed enter so this should be the users root)
[s0n1cm0nk3ymediacrypt]
type = crypt
remote = s0n1cm0nk3ymedia:
password = (removed)
command to mount: rclone mount -vvv --drive-shared-with-me s0n1cm0n3kymediacrypt: /GDrive/s0n1cm0nk3ymedia/
no errors while mounting, but 0 shows.
mounting just s0n1cm0nk3ymedia:
s0n1cm0nk3y@!!!!!!!!!!!!!!:/GDrive/s0n1cm0nk3ymedia$ ls -al
total 1
drwxr-xr-x 1 s0n1cm0nk3y s0n1cm0nk3y 0 Oct 10 20:11 18spe5bs1a0c3o7fnvh3445p6k
drwxr-xr-x 1 s0n1cm0nk3y s0n1cm0nk3y 0 Jul 6 12:21 4ua6ubngs71lchb92ahr6b3jsg
drwxr-xr-x 1 s0n1cm0nk3y s0n1cm0nk3y 0 Jun 9 08:50 5aqpnipfu0o2cvpk1jc43vcupg
drwxr-xr-x 1 s0n1cm0nk3y s0n1cm0nk3y 0 Jul 5 16:47 6pgbcju1f66cr7c73oe1k8758g
-rw-r--r-- 1 s0n1cm0nk3y s0n1cm0nk3y 64 Jun 9 08:49 a1nj4kjrm4qtnkanuf4f5b01lc
drwxr-xr-x 1 s0n1cm0nk3y s0n1cm0nk3y 0 Jun 9 08:50 andlrpqc1kfag5nkmsbi7mk0b8
drwxr-xr-x 1 s0n1cm0nk3y s0n1cm0nk3y 0 Jul 17 07:59 i704qf22ar25qc1s7reddslu7g
drwxr-xr-x 1 s0n1cm0nk3y s0n1cm0nk3y 0 Jun 9 08:50 j5ffa62tl3et5rtiud9vpbdok4
drwxr-xr-x 1 s0n1cm0nk3y s0n1cm0nk3y 0 Jun 25 18:13 nnt08pb350igc9ig2o5jrbl7q0
s0n1cm0nk3y@!!!!!!!!!!!!!!!!!!!:/GDrive/s0n1cm0nk3ymedia$
With s01ncm0n3kymediacrypt mounted:
s0n1cm0nk3y@!!!!!!!!!!!!!:/GDrive$ ls -al ./s0n1cm0nk3ymedia/
total 0
s0n1cm0nk3y@!!!!!!!!!!!!!!!!:/GDrive$
And I realized my mistake. So for my primary root, my top level folders are unencrypted (we will use bob and steve as an example). Under bob is one encryption key, and under steve is another. What I missed was when I mounted s0n1cm0nk3ymedia, I narrowed it down to media, instead of point to the root. So the encrypted remote mount was instead pointing to an unencrypted root folder, and trying to decrypt it.
Yep, that sounds about right.
Trying to "decrypt" unencrypted files will result in such as a mess that they usually won't show up at all.
You can usually see this in rclone's log that you get a whole lot of decrypt-errors of something like "invalid base32..." and similar.
Yep. And the 403 was based on the previous users permissions. For anyone else curious about his issue, that is the answer.