Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[crit] 39#0 *11 open() "/etc/nginx/htpasswd/mydomain.com" failed (13: Permission Denied) #96

Closed
kcrumpton87 opened this issue Feb 5, 2015 · 15 comments

Comments

@kcrumpton87
Copy link

Hi,

First I'd like to say thank you for a great container. I am having one issue with it though. I have been able to get SSL to work and everything runs smoothly. I am hosting a REST API which works fine without basic authentication, however when I add basic authentication via:

docker run -d -p 80:80 -p 443:443 -v /path/to/certs:/etc/nginx/certs -v /path/to/htpasswdfile:/etc/nginx/htpasswd -v /var/run/docker.sock:/tmp/docker.sock jwilder/nginx-proxy

Everything runs fine. I'm only using basic auth on one container (the rest have built in authentication methods). So when I attempt to access my rest api via firefox (or curl) I get a 500 error. The nginx container log shows the error from the subject line:

[crit] 39#0 *11 open() "/etc/nginx/htpasswd/mydomain.com" failed (13: Permission Denied)

@jwilder
Copy link
Collaborator

jwilder commented Feb 5, 2015

Is the container that you want basic auth using it's own distinct virtual hostname? If so, are you mapping it in the parent directory as -v /path/to/httaccess/files:/etc/nginx/htpasswd and there is an htaccess file name mydomain.com in /path/to/httaccess/files?

Basically, nginx-proxy will look for a file named after the VIRTUAL_HOST values in the /etc/nginx/htpasswd dir. If one exists, it will enable basic auth for that domain.

You might want to docker exec -it nginx-proxy bash a running nginx-proxy container and inspect the /etc/nginx/htpasswd directory permissions. Maybe the nginx user is not able to see that directory for some reason.

@kcrumpton87
Copy link
Author

Thanks for the reply. I feel that it's the latter.

I am using the -v option as you described. I will attach the bash to it and see how the permissions look on the /etc/nginx/htpasswd file. Thanks!

@md5
Copy link
Contributor

md5 commented Feb 5, 2015

I think the issue is that the nginx-proxy image expects /etc/nginx/htpasswd to be a directory with files named after the VIRTUAL_HOST, while @kcrumpton87 expects /etc/nginx/htpasswd to be a file.

The "permission denied" error is misleading.

@kcrumpton87
Copy link
Author

Hi @md5

In my nginx-proxy container's logs it is actually looking for /etc/nginx/htpasswd/vhost.mydomain.com and subsequently getting a permission denied. Sorry if it wasn't clear but I believe the bind mount is working as intended in that regard; perhaps not carrying over permissions correctly. I'm in the process of spinning up a new instance to investigate with the bash tool.

@thaJeztah
Copy link
Contributor

Have you tried using -v /path/to/htpasswdfile:/etc/nginx/htpasswd/ <--- trailing slash? I know some parts of docker treat mounts/copies different, depending on the trailing slash.

Might be nothing, but worth a try

@kcrumpton87
Copy link
Author

After investigating within the container I've found that htpasswd does not exist within the /etc/nginx directory. So I will try what you have suggested @thaJeztah. Thanks!

@kcrumpton87
Copy link
Author

Still having issues with this. Actually appending the trailing forward slash did not help. When I go to the machine's bash it still shows no htpasswd folder within /etc/nginx.

@md5
Copy link
Contributor

md5 commented Feb 6, 2015 via email

@kcrumpton87
Copy link
Author

@md5 am not using boot2docker. This is actually running on an Ubuntu 14.04 machine.

@kcrumpton87
Copy link
Author

Also I noticed that the error goes away if the file mode of the htpasswd file to 0777 (not something I want to do in actuality).

@md5
Copy link
Contributor

md5 commented Feb 6, 2015

The Nginx worker processes are running as www-data:www-data (33:33). Could you chown the file to that uid and gid and see if it works? It looks like the Nginx worker processes may need to access auth_basic_user_file and not just the initial root Nginx process.

@kcrumpton87
Copy link
Author

@md5 I have actually tried that. It did not work. More interestingly the SSL certificates are readable by the process.

@maxcnunes
Copy link
Contributor

I had this problem too. After some attempts I got this working with:

# inside the nginx container
chmod -R 0654 /etc/nginx/
chown -R :www-data /etc/nginx/

@fnkr
Copy link

fnkr commented Mar 2, 2016

@maxcnunes A better (more restrictive) solution is to change the group of the htpasswd files to www-data and assign chmod 640.

In my example I have a single htpasswd file (/etc/nginx/management.htpasswd), and a folder full of htpasswd files (/etc/nginx/htpasswd).

The www-data user will have permissions to list files in /etc/nginx and /etc/nginx/htpasswd and will be able to read the file /etc/nginx/management.htpasswd and all files in /etc/nginx/htpasswd. The user will not be able to read other files or list files in other directories.

chmod -R o-rwx /etc/nginx                                             # world should not be able to see anything
chmod o+rx /etc/nginx                                                 # but needs permission to list files inside 
chgrp -R www-data /etc/nginx/htpasswd /etc/nginx/management.htpasswd  # these file and directory will be accessible for the www-data user
chmod -R g+rx /etc/nginx/htpasswd                                     # give read+list permission to group
chmod g+r /etc/nginx/management.htpasswd                              # give read permission to file

Verify permissions afterwards:

$ sudo -u www-data ls -l /etc | grep nginx
drwxr-xr-x  7 root root    4096 Feb 29 21:46 nginx

$ sudo -u www-data ls -l /etc/nginx
total 72
drwxr-x--- 2 root root     4096 Feb 28 20:57 certs
drwxr-x--- 2 root root     4096 Feb 27 12:34 conf.d
-rw-r----- 1 root root     1259 Feb 29 22:24 fastcgi_params
drw-r-x--- 2 root www-data 4096 Mar  1 09:02 htpasswd
-rw-r----- 1 root root     2837 Feb 24 18:02 koi-utf
-rw-r----- 1 root root     2223 Feb 24 18:02 koi-win
-rw-r----- 1 root www-data   43 Feb 28 21:14 management.htpasswd
-rw-r----- 1 root root     3957 Feb 24 18:02 mime.types
lrwxrwxrwx 1 root root       22 Feb 24 18:02 modules -> /usr/lib/nginx/modules
-rw-r----- 1 root root     1046 Feb 29 20:22 nginx.conf
-rw-r----- 1 root root      258 Feb 27 12:52 php_config
-rw-r----- 1 root root      334 Feb 29 19:54 proxy_params
-rw-r----- 1 root root      636 Feb 24 18:02 scgi_params
drwxr-x--- 2 root root     4096 Mar  1 22:57 sites-available
drwxr-x--- 2 root root     4096 Mar  1 22:57 sites-enabled
-rw-r----- 1 root root     1135 Feb 29 22:30 ssl_config
-rw-r----- 1 root root      664 Feb 24 18:02 uwsgi_params
-rw-r----- 1 root root     3610 Feb 24 18:02 win-utf
-rw-r----- 1 root root      103 Feb 29 17:51 ws_params

$ sudo -u www-data cat /etc/nginx/nginx.conf
cat: /etc/nginx/nginx.conf: Permission denied

$ sudo -u www-data cat /etc/nginx/conf.d
cat: /etc/nginx/conf.d: Permission denied

$ sudo -u www-data cat /etc/nginx/management.htpasswd
... # should work

$ sudo -u www-data cat /etc/nginx/htpasswd/*
... # should work

@tkw1536
Copy link
Collaborator

tkw1536 commented Apr 10, 2022

Seems to be an issue migrating from extremely old versions. Resolved by now, closing.

@tkw1536 tkw1536 closed this as completed Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants