Skip to content
Snippets Groups Projects
New issue look: Off

Cannot create project: Name has already been taken, Path has already been taken

    • Closed (moved) Issue created by username-removed-480053 @jeffmccune

    Summary

    Trying to create a new project in a group we consistently get the form validation error. "Name has already been taken, Path has already been taken"

    We attempted to import this project from an export from another Gitlab instance and ran into PG::UniqueViolation errors as described in https://gitlab.com/gitlab-org/gitlab-ce/issues/23475

    Requested work-around: Is there a way to manually clean up (remove) whatever stale data is triggering this validation error? Is there any other known work-around to create a new repository with the same name?

    There are no pending background jobs in /admin/background_jobs

    Steps to reproduce

    With Gitlab CE 8.14.1 on EL-7

    • Create a project in a group, e.g. puppet/control-repo
    • Add one or more merge requests which run CI Jobs.
    • Export the project
    • Import the project into another Gitlab CE 8.14.1 instance. Observe the import fails on "bad decrypt" https://gitlab.com/gitlab-org/gitlab-ce/issues/24458
    • Delete the project partially created from the import.
    • Try to re-create the project as a bare repository using the normal "New Project" button from the group page.
    • Observe the Form validation error, Name has already been taken, Path has already been taken

    Expected behavior

    New project should be created successfully.

    Actual behavior

    New project is not created.

    Relevant logs and/or screenshots

    I'm happy to attach logs, but I'd like some help knowing which logs to look in for this error.

    Output of checks

    Results of GitLab application Check

    (For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:check SANITIZE=true)

    gitlab-rake gitlab:check SANITIZE=true
Checking GitLab Shell ...

GitLab Shell version >= 4.0.0 ? ... OK (4.0.0)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:git?
default... no
  User id for git: 996. Groupd id for git: 994
  Try fixing it:
  sudo chown -R git:git /var/opt/gitlab/git-data/repositories
  For more information see:
  doc/install/installation.md in section "GitLab Shell"
  Please fix the error above and rerun the checks.
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
4/4 ... ok
4/5 ... ok
4/7 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
Send ping to redis server: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking Reply by email ...

Reply by email is disabled in config/gitlab.yml

Checking Reply by email ... Finished

Checking LDAP ...

Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
   DN: REDACTED

Checking LDAP ... Finished

Checking GitLab ...

Git configured with autocrlf=input? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory setup correctly? ... no
  Try fixing it:
  sudo chown -R git /var/opt/gitlab/gitlab-rails/uploads
  sudo find /var/opt/gitlab/gitlab-rails/uploads -type f -exec chmod 0644 {} \;
  sudo find /var/opt/gitlab/gitlab-rails/uploads -type d -not -path /var/opt/gitlab/gitlab-rails/uploads -exec chmod 0700 {} \;
  For more information see:
  doc/install/installation.md in section "GitLab"
  Please fix the error above and rerun the checks.
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
projects have namespace: ...
4/4 ... yes
4/5 ... yes
4/7 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.1.0 ? ... yes (2.3.1)
Your git bin path is "/opt/gitlab/embedded/bin/git"
Git version >= 2.7.3 ? ... yes (2.7.4)
Active users: 3

    Results of GitLab environment info

    (For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:env:info)

    System information
System:
Current User:   git
Using RVM:      no
Ruby Version:   2.3.1p112
Gem Version:    2.6.6
Bundler Version:1.13.6
Rake Version:   10.5.0
Sidekiq Version:4.2.1

GitLab information
Version:        8.14.1
Revision:       e45bf3d
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     postgresql
URL:            http://gitlab01a.inf.utshare.local
HTTP Clone URL: http://gitlab01a.inf.utshare.local/some-group/some-project.git
SSH Clone URL:  git@gitlab01a.inf.utshare.local:some-group/some-project.git
Using LDAP:     yes
Using Omniauth: no

GitLab Shell
Version:        4.0.0
Repository storage paths:
- default:      /var/opt/gitlab/git-data/repositories
Hooks:          /opt/gitlab/embedded/service/gitlab-shell/hooks/
Git:            /opt/gitlab/embedded/bin/git

    Possible fixes

    Unknown.

    Designs

    Child items 0

    • No child items are currently open.

    Activity

    • username-removed-480053
      username-removed-480053 @jeffmccune ·
      Author

      As an update, we worked around the issue in the following way. I'm going to leave this open because I think there's likely still a bug in the undesirable behavior of getting Gitlab into a state where a repository cannot be created. Ideally the "bad decrypt" behavior described in #24458 (closed) will not result in a partially created project which, if removed, cannot be re-created under the same name.

      Here's how we worked around the issue:

      1. Completely destroyed and re-created the second (B) gitlab instance. (Host OS and all)
      2. Copied /etc/gitlab/gitlab-secrets.json from instance A to B taking care to preserve permissions.
      3. Installed gitlab-ce RPM
      4. Copied /etc/gitlab/gitlab.rb from A to B
      5. gitlab-ctl restart
      6. gitlab-ctl reconfigure
      7. Exported the project with the secret environment variables defined.
      8. Imported the project successfully.

      Tip of the hat and respect on the gitlab-secrets.json file! From an operational perspective I think it's a great way to handle sensitive data, and copying the single file between hosts made it a relatively easy task to get export and import of sensitive data working. This experience gives me a lot of confidence in how well designed the security aspects of Gitlab are.

    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

      @jeffmccune Awesome write-up. Thanks for taking the time to log and explain your findings 😃

      @jameslopez Please can you take a look at this one?

    • username-removed-419655 Added ~480950 ~12980 import labels

      Added ~480950 ~12980 import labels

    • James Lopez
      James Lopez @jameslopez ·
      Maintainer

      I wonder if this is related to https://gitlab.com/gitlab-org/gitlab-ce/issues/20984

      And basically the project was not getting actually deleted - hence the duplication error...

    • username-removed-419655
      username-removed-419655 @markglenfletcher1 ·
      Developer

      Hi,

      First of all, thank you for raising an issue to help improve the GitLab product. We're sorry about this, but this particular issue has gone unnoticed for quite some time. To establish order in the GitLab-CE Issue Tracker, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.

      This issue will be marked for closure, as it meets the following criteria:

      • Issue is open
      • No activity in the past 6 months
      • Labelled as a bug
      • Unscheduled (no milestone)

      We'd like to ask you to help us out and determine whether this issue should be reopened.

      Because this issue is reporting a bug, please can you attempt to reproduce on the latest version of GitLab or on GitLab.com, to help us to understand whether the bug still needs our attention.

      Thanks for your help

      /cc @markglenfletcher

    • username-removed-419655 added auto updated awaiting feedback labels

      added auto updated awaiting feedback labels

    • Felipe Artur moved to gitlab#7246

      moved to gitlab#7246

    • Felipe Artur
      Felipe Artur @felipe_artur ·
      Maintainer

      Hey! 👋

      GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

      If you have any questions about all of this, please ask them in our dedicated FAQ issue.

      https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

      You can also find more information here:

      Frequently Asked Questions

      For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

      What will we do with the repository names?

      https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

      Why rename gitlab-ce to gitlab-foss?

      Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

      I created a merge requests for CE, and this got closed. What do I need to do?

      You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

      How does the licensing work in this new setup?

      Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

      Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

      No. Merge requests submitted to this project will be closed automatically.

      Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

      Yes.

      How will this affect users of GitLab CE using Omnibus?

      No changes will be necessary, as the packages built remain the same.

      How will this affect users of GitLab CE that build from source?

      Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

      Where can I see a timeline of the remaining steps?

      https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

      Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

      Yes, these changes will be synced to gitlab-foss automatically, several times per day.

    • Felipe Artur locked this issue

      locked this issue

    Please register or sign in to reply