403 forbidden error on GitLab Fresh installation

Hello all,

I’ve installed gitlab-ce on RHEL 8 and followed the installation guide provided here.
When I try to access the Web Console for the first time, I get a 403 forbidden access error and hence i can’t configure my root password.
This has been bugging me for a couple days, and i didn’t get any luck finding solutions on the net.


Can you check you have these dependencies installed:

I suspect something with selinux.

dnf install libsemanage-static libsemanage-devel policycoreutils

thanks for the quick replay.
this is the output i got:

No match for argument: libsemanage-static
No match for argument: libsemanage-devel
Package policycoreutils-2.9-9.el8.x86_64 is already installed.
Error: Unable to find a match: libsemanage-static libsemanage-devel

OK, some of those packages might be RHEL7 names, so not to worry.

Anyway, we can do some debugging, do:

setenforce 0

to put selinux in permissive mode temporarily and then try again. If the problem still occurs, then we know it’s not selinux. If it does start working then we know that selinux is causing us issues.

The only other thing that might block you is firewalld. So you could do:

systemctl stop firewalld

and then try and see if you can gain access. If so, and after restarting firewalld again it stops working, then we need to sort out firewall rules to allow you access to the server on the appropriate ports that you are trying to connect to. But I expect standard HTTPS port 443 is allowing you access.

To be honest, I’m pretty sure it’s related to selinux, but let’s see. Normally it would be one of these items.

I’ve already tried those both, nothing changed.

Has this server just got gitlab on it? Or do you already run something else on there that may use Apache or Nginx? If so, then this will be conflicting with the Nginx installation in gitlab.

Failing that, you will need to check all your gitlab log files for errors as it’s impossible to debug your problem otherwise.

It’s actually a fresh installation of RHEL 8 on a VM, I didn’t install or run anything on it yet.

I’ve tried accessing the logs, but they are empty.( gitlab_error.log , gitlab_access.log both empty and i’ve checked error.log file under /var/log/gitlab/nginx and there are just a bunch of ssl error, nothing related to the 403 error)

OK, so we can rule out Apache/Nginx conflict - have seen people run into this problem by having other things installed.

You’ll need to check every single log file under /var/log/gitlab - it could be puma, or some other service with problems - and there are a load of logs to check to see if there is anything to find out why. Something is obviously not running as it should.

I’m totally new to gitlab so I have no idea what to look for tbh.

I got this on grafana

2021-02-15_10:19:37.30896 t=2021-02-15T11:19:37+0100 lvl=eror msg="Failed to read plugin provisioning files from directory" logger=provisioning.plugins path=/var/opt/gitlab/grafana/provisioning/plugins error="open /var/opt/gitlab/grafana/provisioning/plugins: no such file or directory"

Puma, redis and sidekiq don’t have anything that caught my attention.
PS : I tried the installation on a completely new system and still the same error.

What changes did you put in /etc/gitlab/gitlab.rb - maybe something you put here is not as it should be. To be honest, I have no idea, since I have done multiple installs on Ubuntu/Debian with Gitlab and it works every time.

Maybe we can find out based on the changes you put in gitlab.rb before running gitlab-ctl reconfigure.

What value did you put in external_url in gitlab.rb?

I’ve changed nothing on the gitlab.rb file except for the external url (the one that’s supposed to give me access to the web console for the first time config). the url is http://gitlab.testmed.com

OK, so assuming gitlab.testmed.com resolves to an IP address, then it shouldn’t be a problem.

I’m going to make a test CentOS 8 installation to see if I can find out where the problem is, because it should just work.

Actually, I’m very sorry and also very thankful for you help. I tried accessing the console on on firefox and I got the web console.
It seems like i have a problem with my DNS server.

Also, I still can’t access the site through the external URL. How can I set the DNS config to allow that ?

For testing you can set the server to use external_url as the IP for the server. For example, I’m currently doing my server now I could set it to:


and in my web browser I could then use that to connect without using DNS. If you have a DNS server, then you need to add a A record with the IP of your server, and the hostname you are wanting to use - gitlab.testmed.com or whatever it should be.

For mine right now I am configuring the host as gitlab.local and I add this to /etc/hosts on the server, as well as to my local /etc/hosts on my laptop so that I can test with this as well as the external_url value.

If on Windows, then edit c:\windows\system32\drivers\etc\hosts, and add in here the IP address of your server, and the hostname - that way you can use your system without DNS, but use the hostname, so: gitlab.local

In the Windows hosts or /etc/hosts on Linux, then you don’t need DNS but it’s only useful for debugging. Ideally you want to configure DNS.

So, yes it works fine. See my config here:

so you can see that /etc/hosts on my gitlab server has the entry gitlab.local and the IP of the server. You can also see this on /etc/hosts on my Linux laptop. This will be the same also for Windows in c:\windows\system32\drivers\etc\hosts file

In external_url I put http://gitlab.local and I use this to connect which you can see in the web browser on the screenshot above. Obviously I would want a proper DNS entry to resolve internally and externally to use my server. And also once DNS resolves internally and externally, configure the external_url to use HTTPS and then after the reconfigure it will automatically create a LetsEncrypt certificate.

So once you resolve the DNS issue, or use the IP/hostname like my test example, it will work for you. So far you are only able to resolve via localhost which is not so great. But at least it shows your install works.

That works perfectly thank you.