Docker Community Forums

Share and learn in the Docker community.

Nginx - 403 forbidden

Hello, I am totally new to Docker and am currently following a tutorial on YouTube. I have downloaded the nginx image and successfully start a container by running the following command: docker run --name website -d -p 8080:80 nginx:latest When I go to localhost:8080 I can see the welcome nginx screen.

The next step was to host a static page by using -v so I cd’ed into the folder that contains my index.html file and from there I run the following: docker run --name Project_009 -v $(pwd):/usr/share/nginx/html:ro -p 8080:80 -d nginx:latest

However, unlike in the tutorial I am getting 403 Forbidden error when I go to localhost:8080. I have already googled the error but most explanations are related to some more advanced stuff which I haven’t yet covered. I did try to go to /usr/share/nginx directory to see if it is an authority issue but that structure doesn’t exist. Do I have to create this manually myself or should this have been created by the above command? I also tried running the docker command with sudo in front just to see if that makes any difference but no luck.

I am a bit stuck and was hoping someone could point me in the right direction.
Many thanks

Docker version 19.03.11, build 42e35e6
Fedora 32

Check the permissions of the files in this folder. They should be -rw-r--r--.

Hi tekki, the index.html file in the folder has -rw-r–r-- authority. Could you think of anything else I need should check? Many thanks

Las time I checked, the nginx image is designed to run the nginx process as root, so actually the unix permissions tekki wrote should be sufficient. Enter the running container and check the content of /usr/share/nginx/html, if it’s empty things like ACLs (typical for Syno/QNAP setups) or selinux prevent the folder from beeing mounted to the container.

Please be aware that your -v parameter uses a bind-mount that mounts your $(pwd) folder on top of the container folder, thus making all its original content unavailable to the container. You will only see what is present in $(pwd). Btw. you can use the variable $PWD instead of running the pwd command in a subshell -> $(pwd)

Did you check the container logs? I would assume they provide a more reasonable explaination.

The worker process runs as nginx (uid 101).

@purpleshadow1975 The only ways I find to reproduce this error is to either set index.html or the folder itself to 0700. So maybe you should check the access rights to the folder too. A simple way to find out if the mounting of the volume works is to run a command like

docker container run --rm -v $PWD:/data debian ls /data

Hi, thank you for your assistance. So, I tried to run the command you specified above and I got: ls: cannot open directory ‘/data’: Permission denied.

Does this mean there is a permission problem on the host or in the container?

I have run docker exec -it Project_009 bash and then tried to get into the /usr/share/nginx/html directory to see if the index.html file is there. but when I try to run ls -l in the html folder I get ls: cannot open directory ‘.’: Permission denied

I don’t know if this is relevant but when I ran the docker exec -it command it connected me as root@container name.

Many thanks.

Thank you for responding. I have tried to have a look in the error.log and access.log in the container and they were both empty.

Thank you for the feedback about the $PWD, once I have this issue resolved I will try it out.
Many thanks

Maybe I missed that the user nginx is added with the uid in the Dockerfile, though the container itself is started as root. which makes the permission problems even more suprising. I haven’t tracked down what part of the configuration is responsible to execute the worker processes as restricted user.

Can you share the output of stat $PWD within the folder where you run the docker run command in?

Are you by any chance running docker on a NAS where you configure the access permissions in a ui? You will want to have “pure” unix permissions for the folder.

[@DESKTOP-1EIKTFE website]$ stat $PWD
File: /home//
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: fd02h/64770d Inode: 4981018 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 1000/
) Gid: ( 1000/******)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2020-10-25 12:06:59.648995836 +0000
Modify: 2020-10-23 17:31:47.773977182 +0100
Change: 2020-10-23 17:31:47.773977182 +0100
Birth: -

I have also just ran the namei -om /usr/share/nginx/html/index.html in the container and got the following:

root@9e4d50f67648:/# namei -om /usr/share/nginx/html/index.html
f: /usr/share/nginx/html/index.html
drwxr-xr-x root root /
drwxr-xr-x root root usr
drwxr-xr-x root root share
drwxr-xr-x root root nginx
drwxr-xr-x 1000 1000 html
index.html - Permission denied

I am running on my laptop with Fedora 32 installed.
Many thanks for your assistance.

stats and the output for namei -om match for the html folder. So far so good.

Though, I am afraid your selinux configuration is responsible for the “permission denied” error.

Please delete you old container and check wether it works with the :Z suffix for the bind-mount volume mapping:

docker run --name Project_009 -v $(pwd):/usr/share/nginx/html:Z -p 8080:80 -d nginx:latest

It works! I am sooo happy. Thank you all for your help. If someone could tell me what selinux configuration has to do with these permission errors?

Again, many many thanks to all that have replied.

This made it clear that its likely a selinux problem. The fact that even though you’d been root in the container and namei returned a Permission error made it clear that SELinux forbidds access.

SELinux provides elaborated access control, which checks if a process is allowed to access an object (in your case a file). Afair, with the :Z suffix, docker takes care to map the hosts selinux contexts to the container.

1 Like

“403 Forbidden” is an all-purpose NGINX error which indicates that you have asked for something that NGINX - for a variety of potential reasons - cannot deliver. “403” is actually an HTTP status code that means that the web server has received and understood your request, but that it cannot take any further action.