Google Drive config backups are failing due to Google changing their Service Account permissions about 20 days ago, is there a workaround?
Getting this error (below) and this reddit thread seems to have people configuring differently, does this apply to OPNsense config workflow?
https://www.reddit.com/r/googlecloud/comments/1m0br1d/using_service_accounts_with_the_google_drive_api/ (https://www.reddit.com/r/googlecloud/comments/1m0br1d/using_service_accounts_with_the_google_drive_api/)
error: "message": "Service Accounts do not have storage quota. Leverage shared drives (https://developers.google.com/workspace/drive/api/guides/about-shareddrives), or use OAuth delegation (http://support.google.com/a/answer/7281227) instead."
Any tips on how to address this change and configure backups correctly is much appreciated, as this seems to be an emerging issue that others may face soon, or as the notice failures and missing backup files.
do a search for google drive on this forum, it is a known situation caused by google drive's changes.
If my take is correct the TLD is:
- functionality in OPN has gone from core to plugins so that existing users can still use it.
- existing users will see it still working. I can't remember what the experience will be for new users (of the functionality)
Did the search...there definitely is a change to the plugin as well as a recent change to the google drive permissions for service accounts, so there is a single post from July 25th about the google drive that mentions a new way to authorize the plugin - however it is an AI hallucination as to how to actually do it and not helpful.
I think that this functionality may be broken for the time being, until a new workflow is worked out on the OPNsense team's side.
The plugin hasn't changed, but Google changed its policy for new accounts so the plugin may be useless for new installs (I'm unclear on whether that includes paid services or not).
Adjusting the plugin to work with the new auth policies is a possibility, but the core team passed the plugin to the community for this. We've added an SFTP backup plugin which we think also works as a viable replacement. The git backup is also a good candidate.
PRs to the Google Drive plugin are welcome, but I'm assuming this is a non-trivial change.
Cheers,
Franco
Hi Franco,
That makes sense...and was also my thinking with the change to the plugin - that it falls outside the main team!
I'll look into the SFTP workflow to see if I have a suitable storage space to ship the items off to - appreciate the offer of this backup solution for keeping all options open to ensure configs are safe.
Best,
Daniel
consolidating into quote for reply
consolidating into quote for reply, and figuring out forum operability
Quote from: franco on August 07, 2025, 08:46:36 PMThe plugin hasn't changed, but Google changed its policy for new accounts so the plugin may be useless for new installs (I'm unclear on whether that includes paid services or not).
Adjusting the plugin to work with the new auth policies is a possibility, but the core team passed the plugin to the community for this. We've added an SFTP backup plugin which we think also works as a viable replacement. The git backup is also a good candidate.
PRs to the Google Drive plugin are welcome, but I'm assuming this is a non-trivial change.
Cheers,
Franco
Arghh for the life of me I cannot get the SFTP connection established either, I keep getting:
user@server_ip: Permission denied (publickey,password). Connection closed
This is to a Truenas SMB share using my non-root admin account with SSH priveleges - I did both a keygen with and without password I placed the public key in the user account I gave user account full access to SSH Service - I chmod 700 the .ssh folder and 600 the keys inside on opnsense and 700 the folder and 600 the authorized_keys file on truenas
Franco - What am I missing here, there must be a simple config that I'm overlooking, right?!?
this will likely be the permissions for the user on the target. Keys permissions done. You will need to set the permissions on sshd on that target.
Quote from: cookiemonster on August 09, 2025, 01:19:52 AMthis will likely be the permissions for the user on the target. Keys permissions done. You will need to set the permissions on sshd on that target.
I set the user on truenas with the auth pub key...it does have a password on the ssh set for this user - I set this to the passphrase for the key gen (once with, once without this passphrase), not sure what is the missing secret sauce on the platforms to establish an sftp connection as I feel I've followed the instructions well.
Side question - the smb share can host the sftp folder and if I log into the server and have certain folder structure presented to navigate to the backup location - I should propagate that into the sftp location, right?!?
smb (cifs) is a network protocol to share "shares" (directories) over the network. Those directories can also be accessed via ssh and in doing so, have no relation to smb. With ssh you are connecting to the machine and navigating the filesystem.
SFTP uses ssh for authentication.
So all you need to do is verify you can ssh into the machine and get to the directory where you want to sftp your backups.
I expect if you tried, you'd get the "permission denied" message, because the current problem seems to be authentication. Try verbose i.e. -vv for additional detail.
Quote from: cookiemonster on August 09, 2025, 01:44:53 AMsmb (cifs) is a network protocol to share "shares" (directories) over the network. Those directories can also be accessed via ssh and in doing so, have no relation to smb. With ssh you are connecting to the machine and navigating the filesystem.
SFTP uses ssh for authentication.
So all you need to do is verify you can ssh into the machine and get to the directory where you want to sftp your backups.
I expect if you tried, you'd get the "permission denied" message, because the current problem seems to be authentication. Try verbose i.e. -vv for additional detail.
Gotcha so the data store is irrelevant just the secure method of connecting using ssh for sftp transfers - I can connect using sftp username@ip address and navigate to the folder on the datastore...it asks for the password when connecting to the sftp connection using this method and I simply enter the ssh password - is this where the permission, password error is coming in and how do I overcome this on the opnsense backup plugin option entries provided?
ok so you can ssh into the target server with that username and password. Good.
I don't use that plugin. I'm a longtime user of the google drive backup. But to be automated I imagine that the plugin can use an non-password authentication i.e. by keys. What does it say on it?
Quote from: cookiemonster on August 09, 2025, 02:01:14 AMok so you can ssh into the target server with that username and password. Good.
I don't use that plugin. I'm a longtime user of the google drive backup. But to be automated I imagine that the plugin can use an non-password authentication i.e. by keys. What does it say on it?
So I created a new truenas user with nologin in the shell and no password required in the ssh checkbox, added the folder to transfer to as the home directory without creating a home folder...added this to the SSH service in auxillary parameters (found on a forum):
Match User username
ForceCommand internal-sftp
Then I had to add my other user to the group permissions for the folder to get access inside the SMB and it authenticated using the public key just fine and backed up perfectly now - thanks for all your help cookiemonster and Franco!!
-Daniel
Very good. Thanks for posting the successful outcome.