Creating groups via API on gitlab.com always returns 403 Forbidden

Summary

Creating groups and subgroups via POST request on https://gitlab.com/api/v4/groups always returns 403 Forbidden. There is a user option Can create group within in the user administration on self-hosted GitLab instances but this is not available on gitlab.com, which probably prevents creating groups via API in the first place.

Steps to reproduce

Create a personal access token and assign yourself to a group with the appropriate role (e.g. owner). Then send a POST request to the relevant API endpoint https://gitlab.com/api/v4/groups to create a subgroup. See docs.

What is the current bug behavior?

The API returns 403 Forbidden in all cases.

What is the expected correct behavior?

The API should return a successful response code and actually create the (sub-)group if the access-token is from a user which has the appropriate role for the group for which the (sub-)group should be created.

Output of checks

This bug happens on GitLab.com

Workaround for Self-Managed Instances

#244345 (comment 560606561)

To create a group from the API, admins rights are not sufficient, you must have specific authorization to create a group, which can be found at http://:yourgitlaburl/admin/users/:username/edit. Check the checkbox "can create group" You can retrieve if the user can create group or not in the /users path of the API if the authenticated user have admin rights.

mentioned in issue gitlab-org/quality/triage-reports#366 (closed)

added api devopsmanage groupauthentication and authorization [DEPRECATED] severity3 + 1 deleted label

added typebug label

added sectiondev label

mentioned in issue #246438 (closed)

mentioned in issue #249039 (closed)

mentioned in issue #254141 (closed)

mentioned in issue #257766 (closed)

mentioned in issue #261974 (closed)

mentioned in issue gitlab-org/quality/triage-reports#468 (closed)

mentioned in issue gitlab-org/quality/triage-reports#526 (closed)

mentioned in issue gitlab-org/quality/triage-reports#604 (closed)

mentioned in issue gitlab-org/quality/triage-reports#662 (closed)

mentioned in issue gitlab-org/quality/triage-reports#670 (closed)

mentioned in issue gitlab-org/quality/triage-reports#703 (closed)

I can confirm, I am experiencing the same issue. I have tried it on multiple gitlab.com accounts. Also creating a subgroup under a parent_id group works fine. Only creating a group in the root account gives a 403: forbidden. Any ideas on this? thanks in advance

I can confirm this issue too. Creating a group in the root account gives "403 - Forbidden".

The only way I got around it was to create a Group (in root) via the GUI. Then export that empty group using the export function. And then I was able to use the import API to create a new group (in root) using the tar.gz export file. As @ilya.kozlov.sympli mentioned, sub-groups (with parent-id) work fine. Seem like a silly workaround but works for now. Also, might be good to note that this was not happening last week so something happened in the last week or so.

Yes, it works in GitLab.com GUI (for regular use). But our service has a close integration, and all user cases work through API.

Hi @ilya.kozlov.sympli I am in the same boat. I have a CICD pipeline (funnily enough through Gitlab) that creates groups and subgroups. So you only have to do that GUI group create ONE time. Once you have the tar.gz file, you can add it to your pipeline that uses the API to create the group. And instead of using the groups API, you can use the following Import API to create your Group. The command is as follows:

curl --request POST --header "PRIVATE-TOKEN: ${YOUR_TOKEN}" \
--form "name=${NAME_OF_THE_ROOT_GROUP}" --form "path=${PATH_OF_THE_ROOT_GROUP}" \
--form "file=@file-you-got-from-export.tar.gz" \
  "https://gitlab.com/api/v4/groups/import"

You can use the file-you-got-from-export.tar.gz to create a new group with a different name and path. I had to add this file to my CICD pipeline.

Hope this helps.

I can also confirm that I also can't create groups from the root path.

Same for me, cannot create groups on root via API calls. UI works. Subgroups work via API, too.

Yes same problem for me, creating a new group via API calls always returns 403 forbidden, even with the access token of an admin user with maximum rights.

Same here - i tried with this tool https://gitlab.com/bdowney/gitlab-group-fork - and got 403

I have found the cause of the problem, and I have the solution! To create a group from the API, admins rights are not sufficient, you must have specific authorization to create a group, which can be found at http://:yourgitlaburl/admin/users/:username/edit. Check the checkbox "can create group" You can retrieve if the user can create group or not in the /users path of the API if the authenticated user have admin rights.

@LetsApps, Your solution is not valid for public gitlab.com API.

@LetsApps, thx! it works for me.

I can't see this option anywhere in the public gitlab.com API

Experiencing the same issues with the cloud gitlab.com API

Same issue, using https://github.com/python-gitlab/python-gitlab, receiving

Impossible to create object (403: 403 Forbidden)

by CLI gitlab group create --name=group994 --path=group994

Not sure if this message helps in any way, but I have the same error/problem when I want to make use of an Ansible module with gitlab.com, see: https://github.com/ansible-collections/community.general/issues/2770

any news/progress about this issue?

+1

+1 - I am using terraform and I get

Error: POST https://gitlab.com/api/v4/groups: 403 {message: 403 Forbidden}
  on gitlab-group.tf line 15, in resource "gitlab_group" "xxxxx":
  15: resource "gitlab_group" "xxxxx" {

Completely the same issue here #244345 (comment 661073663)

I was actually able to get this to work. When creating a subgroup you have to supply the parent_id. The path parameter is not the full path -- it's the path segment name of the subgroup being created.

In python-gitlab, this would be:

parent_group = gl.groups.get('parent-path')
gl.groups.create({'name': 'My Subgroup', 'path': 'my-subgroup', 'parent_id': parent_group.id})

Thank you @robotben that solved my problem with the Gitlab provider (terraform)

Thank you! This worked for me using the terraform provider as well. Path is just the "slug" for the path (not the fully qualified path). The parent_id is required if it is going to be a child group.

resource "gitlab_group" "engineering_group" {
  name        = "My Group Name"
  path        = "my-group-slug"
  parent_id   = 123456789 # (parent group id)
  description = "My engineering group"

+1, also fails with terraform

I would also appreciate if that could be fixed after 1 year.

+1 same here

Failed with Terraform

gitlab = {
  source = "gitlabhq/gitlab"
  version = "3.7.0"
}

gitlab_group.example: Creating...
╷
│ Error: POST https://gitlab.com/api/v4/groups: 403 {message: 403 Forbidden}
│ 
│   with gitlab_group.example,
│   on main.tf line 1, in resource "gitlab_group" "example":
│    1: resource "gitlab_group" "example" {
│ 
╵

Have you managed it? Also facing the same issue using Terraform..

thanks

Same problem creating group with python-gitlab module returns 403

This problem still occurs but in my eyes is critical to have fixed in the API. Any updates?

I'm experiencing the same issue even today. Any updates on the fix?

Seeing the same issue with Terraform still

For everyone commenting on this, see my comment above. You have to supply the parent id.

This is still a bug in that the error message is misleading, but it's easy to get around.

@robotben I can create subgroups fine the problem is creating a root group that has no parent ID

@robotben I think most people are having issues related to being able to create a root group rather than a subgroup...

Some of you (if you are running a self-hosted instance with version 14.5 or 14.5.1) may have the same problem I had. There is an issue in version 14.5 that will be fixed in version 14.6.

More information and a workaround can be found here: #346943 (closed)

#244345 (comment 690678635)

i added the parent_id and it works now

https://registry.terraform.io/providers/gitlabhq/gitlab/latest/docs/resources/group#parent_id

But the problem is not with SUB groups but with creating the groups in ROOT path.

my-group > my-subgroup

{ "message": "403 Forbidden" }

when trying to create group -https://gitlab.com/api/v4/groups

body: {

    "name": "tea",
    "path": "PR1638775705629"

}

marked #346781 (closed) as a duplicate of this issue

marked this issue as related to #346781 (closed)

removed the relation with #346781 (closed)

changed the description

Getting 403 while creating the group. Is this fixed?

Failing with pulumi as well.

/srv/todo/infra # pulumi up
Previewing update (dev):
     Type                   Name              Plan
     pulumi:pulumi:Stack    awesome-todo-dev
 +   └─ gitlab:index:Group  Awesome TODO      create

Resources:
    + 1 to create
    1 unchanged

Do you want to perform this update? yes
Updating (dev):
     Type                   Name              Status                  Info
     pulumi:pulumi:Stack    awesome-todo-dev  **failed**              1 error
 +   └─ gitlab:index:Group  Awesome TODO      **creating failed**     1 error

Diagnostics:
  pulumi:pulumi:Stack (awesome-todo-dev):
    error: update failed

  gitlab:index:Group (Awesome TODO):
    error: POST https://gitlab.com/api/v4/groups: 403 {message: 403 Forbidden

Resources:
    1 unchanged

Duration: 2s

Error with groups in ROOT path is still happening. Any news ?

Same things for creating merge requests through api. Access token with all scopes gets back 403 forbidden. Will this ever get looked at?

Hey everyone

I just want to give some possible reasons why this is disabled on ~SaaS (as mentioned in the docs).

GitLab (and every other platform offering free computation (here via CI and the shared runners)) has problems with abuse of their platform from cryptominers. Also, to prevent unlimited usage of the computation resources, each namespace has a limit on free CI minutes it can use each month. Subgroups use the quota of their parent group and therefore, all groups within a single root group share the same quota.

Now, if you create a new root group, it's CI minutes quota is independent from the other root group. So if you allow to create root groups over the API, you enable abusive users to gain unlimited minutes as they can just spin up new root groups automatically once they run out of CI minutes (or even earlier and running much more pipelines in parallel).
Forcing the manual step for the root group creation on ~SaaS prevents that problem and helps making the CI more stable for legitimate users.

Another point, someone could just create groups with all possible combinations of characters and that would prevent new users getting a reasonable username as the paths were already taken by the abuse user which just created a huge amount of root groups with many of the possible character combinations.

---

I know that this doesn't help the problem and this can be quite frustrating for legitimate users which just want to automate some tasks, but I hope this maybe explains some possible reasons, why this is the case on gitlab.com.

Sadly we live in a world, where we must think of the possible abuses and try to prevent them, even at the cost of impacting legitimate users.

Thanks for the feedback

Apologies for the long delay in triaging this issue, but Niklas has summarized the reason for this behaviour well. I'll mark this issue as a typefeature featureenhancement so that we can review with product team to see if there are alternative ways of supporting this.

added Category:System Access label

removed severity3 label

removed typebug label

added featureenhancement typefeature labels

added auto updated potential proposal labels

added devopsgovern sectionsec labels and removed devopsmanage sectiondev labels

added groupauthentication label and removed groupauthentication and authorization [DEPRECATED] label

Good evening, I get the same error when I try to create a new "message" Group: "403 Forbidden"

If I try to put a parentId then the call works correctly. My question is it possible to create a Group without a parentId? I'm using the free version of Gitlab Thank you

changed milestone to %Backlog

Marking this as wontfix due to it's purposeful disablement because it's an abuse vector. This is documented and we don't have plans to change it.

added wontfix label