amnezia-vpn/amnezia-client

Fork 0

mirror of https://github.com/amnezia-vpn/amnezia-client.git synced 2026-10-15 05:42:07 +00:00

[GH-ISSUE #2111] Confusing "Action not allowed in sudoers" error on Google Cloud #932

New issue

Open

opened 2026-10-13 20:31:16 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-13 20:31:16 +00:00

Owner

Originally created by @ddudov on GitHub (Jan 1, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2111

Describe the bug
When installing AmneziaVPN on a GCP instance, you get an error 209: "Action not allowed in sudoers", even when the user is in the sudo group and has all the necessary permissions.

Why this happens:

github.com/amnezia-vpn/amnezia-client@d859b111ca/client/server_scripts/check_user_in_sudo.sh (L12) for a non-"root" user actually prints out the output of the groups || grep to stdout.
On GCP, users are added to the "google-sudoers" groups by default, so the output woud look like:
foo@amnezia-1:~$ groups "$CUR_USER" | grep -E '\<(sudo|wheel)\>'
foo : foo adm dialout cdrom floppy sudo audio dip video plugdev netdev lxd ubuntu google-sudoers
github.com/amnezia-vpn/amnezia-client@d859b111ca/client/core/controllers/serverController.cpp (L809) checks for "sudoers" in stdout. Because of "google-sudoers" (see 2.), there's a match, and the sudo check returns error 209.

To Reproduce
Steps to reproduce the behavior:

Create a GCP instance
Create a non-root user e. g. foo
Give the user root permissions: sudo usermod -aG sudo foo, echo 'foo ALL=(ALL:ALL) NOPASSWD:ALL' | sudo tee -a /etc/sudoers.d/90-foo
Connect as this user from the AmneziaVPN client, and try to install any component.

Expected behavior
E. g.

Ignore membership in google-sudoers if there's already a membership in sudo
Or make the error message more clear: e.g. "user is not allowed to be in any "sudoers" group".

One really simple way to fix this would be to send the output of groups || grep (see step 1. in bug description) to /dev/null. But since later we check for "sudoers" string in stdout, it seems this is intended - but I'm not sure what the intent is?

Desktop (please complete the following information):

OS: Windows 11

Server (please complete the following information):

OS: Ubuntu 22.04 on GCP

Additional context
Workaround: on the server, remove your user from any groups containing "sudoers" in their name (groups $USER | grep sudoers)

Originally created by @ddudov on GitHub (Jan 1, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2111 **Describe the bug** When installing AmneziaVPN on a GCP instance, you get an error 209: "Action not allowed in sudoers", even when the user is in the `sudo` group and has all the necessary permissions. Why this happens: 1. https://github.com/amnezia-vpn/amnezia-client/blob/d859b111ca1ade8cf29d676244a6e3d3ac8e3835/client/server_scripts/check_user_in_sudo.sh#L12 for a non-"root" user actually prints out the output of the `groups || grep` to stdout. 2. On GCP, users are added to the "google-sudoers" groups by default, so the output woud look like: `foo@amnezia-1:~$ groups "$CUR_USER" | grep -E '\<(sudo|wheel)\>'` `foo : foo adm dialout cdrom floppy sudo audio dip video plugdev netdev lxd ubuntu google-sudoers` 3. https://github.com/amnezia-vpn/amnezia-client/blob/d859b111ca1ade8cf29d676244a6e3d3ac8e3835/client/core/controllers/serverController.cpp#L809 checks for "sudoers" in stdout. Because of "google-sudoers" (see 2.), there's a match, and the sudo check returns error 209. **To Reproduce** Steps to reproduce the behavior: 1. Create a GCP instance 2. Create a non-root user e. g. `foo` 3. Give the user root permissions: `sudo usermod -aG sudo foo`, `echo 'foo ALL=(ALL:ALL) NOPASSWD:ALL' | sudo tee -a /etc/sudoers.d/90-foo` 4. Connect as this user from the AmneziaVPN client, and try to install any component. **Expected behavior** E. g. - Ignore membership in google-sudoers if there's already a membership in sudo - Or make the error message more clear: e.g. "user is not allowed to be in any "sudoers" group". One really simple way to fix this would be to send the output of `groups || grep` (see step 1. in bug description) to /dev/null. But since later we check for "sudoers" string in stdout, it seems this is intended - but I'm not sure what the intent is? **Desktop (please complete the following information):** - OS: Windows 11 **Server (please complete the following information):** - OS: Ubuntu 22.04 on GCP **Additional context** Workaround: on the server, remove your user from any groups containing "sudoers" in their name (`groups $USER | grep sudoers`)

bsakaguchi commented

2026-10-13 20:31:17 +00:00

Author

Owner

@iamjamilkhan commented on GitHub (Feb 6, 2026):

Any solution?

@iamjamilkhan commented on GitHub (Feb 6, 2026): Any solution?

bsakaguchi commented

2026-10-13 20:31:17 +00:00

Author

Owner

@s3ths1 commented on GitHub (Feb 25, 2026):

Hello everyone! I recently encountered this error 209 and I wanted to share with you how I was able to fix it.

The issue:

The check for sudo permissions in Amnezia is a bit simplistic - it simply looks for the word "sudoers" anywhere in the group output. On cloud virtual machines (like Yandex Cloud or Google Cloud), you may have a group called "google-sudoers" that triggers this false positive. Even though you actually have full sudo access, Amnezia will throw an error 209.

To fix the issue, I followed these steps:

SSH'd into the server.
Removed myself from the "google-sudoers" group: sudo gpasswd -d <my-username> google-sudoers
Made sure I was also in the "sudo" group (cloud images usually add me to this group, but I wanted to be extra sure): sudo usermod -aG sudo my-username
Checked my groups with groups my-username, and saw that "sudo" was listed, but not "sudoers".
Ran the Amnezia client again, and it worked without any errors.

@s3ths1 commented on GitHub (Feb 25, 2026): Hello everyone! I recently encountered this error 209 and I wanted to share with you how I was able to fix it. **The issue:** The check for sudo permissions in Amnezia is a bit simplistic - it simply looks for the word "sudoers" anywhere in the group output. On cloud virtual machines (like Yandex Cloud or Google Cloud), you may have a group called "google-sudoers" that triggers this false positive. Even though you actually have full sudo access, Amnezia will throw an error 209. **To fix the issue, I followed these steps:** 1. SSH'd into the server. 2. Removed myself from the "google-sudoers" group: `sudo gpasswd -d <my-username> google-sudoers` 3. Made sure I was also in the "sudo" group (cloud images usually add me to this group, but I wanted to be extra sure): `sudo usermod -aG sudo my-username` 4. Checked my groups with `groups my-username`, and saw that "sudo" was listed, but not "sudoers". 5. Ran the Amnezia client again, and it worked without any errors.

bsakaguchi commented

2026-10-13 20:31:17 +00:00

Author

Owner

@nikolai-smolianinov commented on GitHub (Jul 12, 2026):

Thanks theseriff
worked for me also

@nikolai-smolianinov commented on GitHub (Jul 12, 2026): Thanks [theseriff](https://github.com/theseriff) worked for me also

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

amnezia-vpn/amnezia-client#932

No description provided.

Rows
Columns