Bitbucket Support

Problem

If you own a Bitbucket Server instance that is older than the 3.2 release, moving an account to a different "OU" or losing the connectivity to the LDAP User Directory will make Bitbucket Server lose visibility of this AD account.

If you re-add the account to the correct OU or recover the account, Bitbucket Server will show the account again, but his old permissions/user access won't be in Bitbucket Server anymore. Adding the user back via global permissions and granting him permission on the Projects again will work as expected.

However, in some circumstances, when the user tries to create a personal repository it will get a message like:

You do not have permission to create a repository within the <Username> project

This error can also be perceived as:

401 You are not permitted to view this page

Both error messages have the same root cause and this issue needs to be manually fixed on the database.

Diagnosis

The queries below show which usernames are explicitly given project admin permissions to their own personal repository. Therefore, all users who have the right "PROJECT_ADMIN" permissions to their personal space are shown. Hence, if the query below doesn't return the user which is facing the described symptom, it means that it needs to be fixed.

If your instance older than 2.12.X, please run to diagnose ...

MySQL, PostgreSQL, Microsoft SQL Server

select u.id as user_id, u.name as user_name, pp.perm_id, pp.project_id, p.name as project_name 
from stash_user u 
left join sta_project_permission pp on (u.id = pp.user_id) 
left join project p on (pp.project_id = p.id)
where p.project_type = 1;

// p.project_type = 1 indicates a personal repository
// pp.perm_id = 4 indicates PROJECT_ADMIN permissions

OracleDB

select u.id user_id, u.name user_name, pp.perm_id, pp.project_id, p.name project_name 
from stash_user u 
left join sta_project_permission pp on (u.id = pp.user_id) 
left join project p on (pp.project_id = p.id)
where p.project_type = 1;

// p.project_type = 1 indicates a personal repository
// pp.perm_id = 4 indicates PROJECT_ADMIN permissions

Attention

If the user is not listed here it has an issue and needs to be fixed. All the other users in the output of the query above are fine.

If your instance newer than or equal to 2.12.X, please run to diagnose ...

You can run this following SQL query to check if the user is listed:

Attention

If the user is not listed here it has an issue and needs to be fixed. All the other users in the output of the query above are fine.

MySQL, PostgreSQL, Microsoft SQL Server

select u.id as user_id, nu.name as user_name, pp.perm_id, pp.project_id, p.name as project_name 
from stash_user u
left join sta_normal_user nu on (nu.user_id = u.id) 
left join sta_project_permission pp on (u.id = pp.user_id) 
left join project p on (pp.project_id = p.id)
where p.project_type = 1;

// p.project_type = 1 indicates a personal repository
// pp.perm_id = 4 indicates PROJECT_ADMIN permissions

OracleDB

select u.id user_id, nu.name user_name, pp.perm_id, pp.project_id, p.name project_name 
from stash_user u
left join sta_normal_user nu on (nu.user_id = u.id) 
left join sta_project_permission pp on (u.id = pp.user_id) 
left join project p on (pp.project_id = p.id)
where p.project_type = 1;

// p.project_type = 1 indicates a personal repository
// pp.perm_id = 4 indicates PROJECT_ADMIN permissions

OR

You can run this following SQL query to check if there are users that are affected by this symptom.

Attention

If the user is listed here it has an issue and needs to be fixed.

MySQL, PostgreSQL, Microsoft SQL Server

select u.id as user_id, nu.name as user_name
from stash_user u
left join sta_normal_user nu on (nu.user_id = u.id)
where 
u.id not in (select u.id as user_id
from stash_user u
left join sta_normal_user nu on (nu.user_id = u.id)
left join sta_project_permission pp on (u.id = pp.user_id)
left join project p on (pp.project_id = p.id)
where p.project_type = 1) 
and 
nu.name not in (select nu.name as user_name
from stash_user u
left join sta_normal_user nu on (nu.user_id = u.id)
left join sta_project_permission pp on (u.id = pp.user_id)
left join project p on (pp.project_id = p.id)
where p.project_type = 1);

OracleDB

select u.id user_id, nu.name user_name
from stash_user u
left join sta_normal_user nu on (nu.user_id = u.id)
where 
u.id not in (select u.id as user_id
from stash_user u
left join sta_normal_user nu on (nu.user_id = u.id)
left join sta_project_permission pp on (u.id = pp.user_id)
left join project p on (pp.project_id = p.id)
where p.project_type = 1) 
and 
nu.name not in (select nu.name user_name
from stash_user u
left join sta_normal_user nu on (nu.user_id = u.id)
left join sta_project_permission pp on (u.id = pp.user_id)
left join project p on (pp.project_id = p.id)
where p.project_type = 1);

Also, just as an extra note, users will only be given the right "PROJECT_ADMIN" permissions to their personal space once the user explicitly goes on to Bitbucket Server UI and click on Profile >> View Profile. Only then, the permission will be automatically created. Forking repository into the personal repository also creates this permission automatically.

Cause

In more recent version of Bitbucket, this issue has been identified as causing this problem: BSERV-10802 - Getting issue details... STATUS

The loss of permissions due to loss of connections to LDAP is fixed in Bitbucket Server 3.2.0: BSERV-4631 - Getting issue details... STATUS

Resolution

The database structure of Bitbucket Server can be changed on upgrades without discretion. If you are unsure about changing your database or you had errors running the queries above (in the Diagnosis), please file an issue with Atlassian Support before running the transaction described in the Resolution. Always remember to backup your instance before any database change as we recommend on:

Data recovery and backups

If your instance older than 2.12.X, please run ...

Use this query to find the project ID and user ID. Substitute username by the user having troubles creating a personal repo (i.e. mkramer or tbomfim). In one of the query parameters, the symbol " ~ " should be kept before the username:

MySQL, PostgreSQL, Microsoft SQL Server

select project.id as project_id, stash_user.id from project, stash_user where project.name LIKE '~username' AND project_type=1 AND stash_user.name LIKE 'username';

OracleDB

select project.id project_id, stash_user.id from project, stash_user where project.name LIKE '~username' AND project_type=1 AND stash_user.name LIKE 'username';

Double check! Make sure nothing already exists in the permission table:

MySQL, PostgreSQL, Microsoft SQL Server, OracleDB

select * from sta_project_permission where user_id=<user_id here> AND project_id=<project_id here>;

After that you can use the values found from the first query to fix the permissions with the transaction below:

begin;
insert into sta_project_permission
(id, perm_id, project_id, user_id)
values
(
    (
		select next_val from id_sequence
		where sequence_name = 'granted_permission'
    ), 4, <project_id here>, <user_id here>
);

update id_sequence set next_val = next_val + 1 where sequence_name = 'granted_permission';
commit;

If your instance newer than or equal to 2.12.X, please run ...

Use this query to find the project ID and user ID. Substitute username by the user having troubles creating a personal repo (i.e. mkramer or tbomfim). In one of the query parameters, the symbol " ~ " should be kept before the username:

MySQL, PostgreSQL, Microsoft SQL Server

select project.id as project_id, sta_normal_user.user_id from project, sta_normal_user where project.name LIKE '~username' AND project_type=1 AND sta_normal_user.name LIKE 'username';

OracleDB

select project.id project_id, sta_normal_user.user_id from project, sta_normal_user where project.name LIKE '~username' AND project_type=1 AND sta_normal_user.name LIKE 'username';

Double check! Make sure nothing already exists in the permission table:

MySQL, PostgreSQL, Microsoft SQL Server, OracleDB

select * from sta_project_permission where user_id=<user_id here> AND project_id=<project_id here>;

After that you can use the values found from the first query to fix the permissions with the transaction below:

begin;
insert into sta_project_permission
(id, perm_id, project_id, user_id)
values
(
    (
		select next_val from id_sequence
		where sequence_name = 'granted_permission'
    ), 4, <project_id here>, <user_id here>
);

update id_sequence set next_val = next_val + 1 where sequence_name = 'granted_permission';
commit;

The permissions might be cached thus the database change might not immediately resolve the error message the user is experiencing.

There are 2 options to repopulate the cache after the database change:

Restart Bitbucket Server

or

Grant and then revoke a new permission to a project, repo, or even a Global Permission via the UI for the affected user.

Bitbucket Support

Knowledge base

Products

Jira Software

Jira Service Management

Jira Work Management

Confluence

Bitbucket

Resources

Documentation

Community

Suggestions and bugs

Marketplace

Billing and licensing

You do not have permission to create a repository within the project

Still need help?

Problem

Diagnosis

OR

Cause

Resolution

Page

Viewport

Confluence

You do not have permission to create a repository within the project

Related content

Still need help?

Problem

Diagnosis

OR

Cause

Resolution

Related content