Gitlab in Proxmox container: cannot login

I have approved your website account so in future you can log in and you won't need to wait for me to approve your posts. You can also start a new thread if you have any further problems.

FYI, this issue has been discussed on another thread - which I've just posted on, noting a workaround.

Please try that and post back on how it goes over on that thread.

I have same problem:

in ProxMox, after installing debian-12-turnkey-gitiab_18.1-1_amd64.tar.gz as CT or turnkey-gitlab-18.1-bookworm-amd64.iso in VM I have same 500 error.

If I run "sudo gitlab-rake gitlab:doctor:secrets"
I get: "ApplicationSetting failures: 1"

If I run "gitlab-rails runner -e production "ApplicationSetting.current.reset_runners_registration_token!""
I get "/opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/encryptor-3.0.0/lib/encryptor.rb:98:in `final': OpenSSL::Cipher::CipherError"

So I am kind a stuck...

Apologies for slow response. Your GitLab looks really broken?! I couldn't reproduce your issue, but I must admit that my experience with the TurnKey GitLab LXC build (via Proxmox) didn't go particularly well for me either...

FIrstly, are you running this as unprivileged? If not, then either try it as unprivileged or enable "nesting" for the container (weird issues when running privileged without nesting enabled is a known issue for all v16.x TurnKey LXC builds).

Beyond that, have you tried updating the installed GitLab package? Another user has recently had issues with LDAP that was a bug in GitLab itself. Obviously, this issue isn't related to LDAP, but perhaps it's another bug that has been fixed in a newer GitLab version? Try updating GitLab like this:

apt update
apt install gitlab-ce

Also FWIW you don't need to use sudo when running as root (unless you want to run as a non-root user - e.g. 'sudo -u OTHER_USER COMMAND').

If you don't have any luck, please try downloading the ISO from the GitLab appliance page and installing that into a "proper" VM. I suspect that might give a better experience anyway (unless you run it as priveledged with nesting enabled - which has security implications)... As I'm sure you're already aware GitLab requires a ton of resources; at least 2x CPU & 4GB RAM with 4GB swap (recommended 4x CPU and 8GB RAM).

The password setting firstboot script uses the same (or at least very similar) method to set the password (as your solution). So I'm not really sure why it didn't just work?

Is it running with plenty of resources? GitLab is a beast and to run smoothly it takes a fair bit of resource allocation.

Even if it's running ok, perhaps it's especially slow to start? If that's the case, then perhaps the backend hadn't completely started by the time you were setting up the password? In that scenario, a race condition may have meant that the password you wanted may not have been set. In that case, the process would have errored, but you may have missed it?

Considering that we had huge issues with that in previous versions (and worked around it), and yours is the first complaint re v16.0 (which has been available for a while now) I suspect my guess isn't too far off.

Regardless, glad to hear that you are up and running now and we'll certainly keep an eye out for that when we do the rebuild for the next release.

I still have no idea what went wrong, but I managed to reset the gitlab root password using the rails console as described here:

https://docs.gitlab.com/ee/security/reset_user_password.html

Now an can log into my new GitLab installation successfully.