I have a simple Flask/Nginx server and 3 files in location /opt/hosting/files:
[adam#localhost]$ namei -om /opt/hosting/files
f: /opt/hosting/files
dr-xr-xr-x root root /
drwxr-xr-x root root opt
drwxr-xr-x root root hosting
drwxr-xr-x nginx nginx files
In the folder files I have 3 files: two images and a bigger zip file:
[adam#localhost]$ ls -lh /opt/hosting/files/
total 424M
-rwx-----x. 1 nginx nginx 19K 03-06 01:29 file1.jpg
-rwx-----x. 1 nginx nginx 18M 03-06 03:34 file2.png
-rwxr-xr-x. 1 nginx nginx 406M 07-07 13:07 file3.zip
I am serving these files and while the first two appear without a problem, I get 403 Forbidden for the zip file both through www and using wget. I think directories permissions are set correctly, since the two other files are fine. Zip file properties are even higher so this shouldn't be an issue as well.
I tried using chown root:root and chown 777 for file and folders and couldn't access the file anyway. After making changes I'm restarting nginx with sudo systemctl restart uwsgi. SELinux shows Enforcing.
What is the problem here?
Got it. Reading a comment by tinesoft here made me check SELinux context of files (yes, I'm running CentOS, forgot to mention that) and it was:
[adam#localhost]$ ls -lZ /opt/hosting/files
-rwx-----x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 file1.jpg
-rwx-----x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 file2.png
-rwxr-xr-x. nginx nginx unconfined_u:object_r:user_home_t:s0 file3.zip
Then, following SELinux documentation from RedHat I managed to change the type of SELinux context from user_home_t to httpd_sys_content_t using
sudo chcon -t httpd_sys_content_t file3.zip
That was it.
Related
To give first some history to this problem; I'm setting up a django site on digitalocean first copied using root and the django folder had as the owner root and I've since worked on fixing this and now the site it up and running but one image still has the 403 forbidden error.
I'm looking for a command that can change the rights of this file.
-rwxr----- 1 sammy sammy 566719 Jul 1 14:52 developer.jpg
Your NGINX user is likely using the www-data or a different user, to verify the user being used by NGINX in a shell execute:
grep user /etc/nginx/nginx.conf
Then to change the file permissions:
chown www-data:www-data developer.jpg
Looking at your file permissions they also needed adjusted - see this answer for recommended perms.
(may require sudo, replace www-data with your NGINX user)
chmod -R 777 folder_name
chmod -R 777 file.name //when You are in directory where this file exist
or
chmod -R 777 file_path/file.name
I am trying to create a local pip2pi repo and then serve it up via Nginx. I have successfully created the repo and have all the wheel files I am wanting on my local machine. They are located like this:
/home/user/code/misc/pip-packs/simple
\
---index.html
--- amqp
\
-------- index.html
-------- amqp-1.4.6-py2-none-any.whl
--- django
\
-------- index.html
-------- Django-1.9.3-py2.py3-none-any.whl
... ETC
Now to serve the files I am using Nginx on docker, simply using the official Nginx docker image. I run the container like this:
docker run --name pypi-nginx -p 80:80 \
-v /home/user/code/misc/pip-packs/simple:/usr/share/nginx/html \
-d nginx
I can open localhost and see the index.html at root (/) and I can click on a link e.g. amqp and then get a link for the amqp-1.4.6-py2-none-any.whl file. When I click on the link I expect a download to initiate. Howver I get a 404 page from Nginx.
THe file is definitely there, as I can run:
docker exec -it pypi-nginx /bin/bash
And then ls and the /usr/share/nginx/html directory and see all the files from the voulume.
Further I can run pip install amqp-1.4.6-py2-none-any.whl on my local, so I know it's an actual wheel file.
Nginx's official log error is:
2016/05/20 14:48:01 [error] 7#7: *1 open() "/usr/share/nginx/html/funcsigs/funcsigs-0.4-py2.py3-none-any.whl" failed (2: No such file or directory), client: 172.17.0.1, server: localhost, request: "GET /funcsigs/funcsigs-0.4-py2.py3-none-any.whl HTTP/1.1", host: "localhost", referrer: "http://localhost/funcsigs/"
but yet it serves the index files in each firectory. The nginx conf files I am using are the standard ones from the container. I can post those if necessary.
In the directory /home/user/code/misc/pip-packs/ is where pip2pi stores the packages it downloaded. So in /home/user/code/misc/pip-packs/ you have
/home/user/code/misc/pip-packs/
\
--- amqp-1.4.6-py2-none-any.whl
--- Django-1.9.3-py2.py3-none-any.whl
--- ETC
Then as in the simple directory as described in the question above, each repo folder supposedly has the wheel file as well, yet there was a 404. Well i glossed over the dir2pi pip-packs/ command, which only created symlinks and did not copy the wheel files. So when I mounted the volume to the container, the actual wheel files, that all the symlinks pointed to, never got copied to the container.
The output of 'ls -al' for the Django folder (packages/simple/django) is:
drwxr-xr-x 2 bdew70 bdew70 4096 May 20 11:02 .
drwxr-xr-x 64 bdew70 bdew70 4096 May 20 11:02 ..
lrwxrwxrwx 1 bdew70 bdew70 39 May 20 11:02 Django-1.9.3-py2.py3-none-any.whl -> ../../Django-1.9.3-py2.py3-none-any.whl
-rwxr-xr-x 1 bdew70 bdew70 88 May 20 11:02 index.html
The solution is to make a Dockerfile and then ADD the wheel files to the /user/share/nginx/ folder along with the html files to the /usr/share/nginx/html/ folder. The Dockerfile should look like this:
FROM nginx
ADD packages/simple /usr/share/nginx/html/
ADD packages /usr/share/nginx
The moral of the story is to use '-al' (or create an alias for ls) when investigating file problems and to be careful of symlinks in Docker container volumes. Especially if the symlink is relative and in the form ../../some-file.
I've ran into a problem after setting a folder and its contents to 755 permissions.
I ran
chmod 755 -R folder/
However, when trying to access in my /var/www folder via the browser I get a 403 Forbidden error.
I did download the folder from the web, but other files with 755 permissions are loaded just fine into the browser. Here is what it looks like:
ls -l
drwxr-xr-x. 4 root root 4096 folder
Edit: If you're going to down vote, how about explain why?
drwxr-xr-x.
The trailing dot means the directory has an SElinux ACL, which is likely the cause of your problem. -- the ACL denies access.
I have Nginx setup and displaying the test page properly. If I try to change the root path, I get a 403 Forbidden error, even though all permissions are identical. Additionally, the nginx user exists.
nginx.conf:
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
events {
worker_connections 1024;
}
http {
index index.html index.htm;
server {
listen 80;
server_name localhost;
root /var/www/html; #changed from the default /usr/share/nginx/html
}
}
namei -om /usr/share/nginx/html/index.html
f: /usr/share/nginx/html/index.html
dr-xr-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 root root html
-rw-r--r-- root root index.html
namei -om /var/www/html/index.html
f: /var/www/html/index.html
dr-xr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root www
drwxr-xr-x root root html
-rw-r--r-- root root index.html
error log
2014/03/23 12:45:08 [error] 5490#0: *13 open()
"/var/www/html/index.html" failed (13: Permission denied), client:
XXX.XX.XXX.XXX, server: localhost, request: "GET /index.html HTTP/1.1", host: "ec2-XXX-XX-XXX-XXX.compute-1.amazonaws.com"
I experienced the same problem and it was due to SELinux.
To check if SELinux is running:
# getenforce
To disable SELinux until next reboot:
# setenforce Permissive
Restart Nginx and see if the problem persists. If you would like to permanently alter the settings you can edit /etc/sysconfig/selinux
If SELinux is your problem you can run the following to allow nginx to serve your www directory (make sure you turn SELinux back on before testing this. i.e, # setenforce Enforcing)
# chcon -Rt httpd_sys_content_t /path/to/www
If you're still having issues take a look at the boolean flags in getsebool -a, in particular you may need to turn on httpd_can_network_connect for network access
# setsebool -P httpd_can_network_connect on
For me it was enough to allow http to serve my www directory.
First of all you have to run following command to allow nginx to access filesystem
sudo setsebool -P httpd_read_user_content 1
You can check if the files or directory with following command:
ls -Z
If it is still not accessible, you can try changing the SELinux property of the files and folder with following command:
chcon -Rt httpd_sys_content_t /path/to/www
However, above command cannot apply to files under FUSE or NFS system.
To enable serving files from FUSE mounts, you can use:
setsebool httpd_use_fusefs 1
To enable serving files from NFS mounts, you can use:
setsebool httpd_use_nfs 1
I ran into the same problem. If you're using Fedora/RedHat/CentOS, this might help you:
According to SELinux: setsebool -P httpd_read_user_content 1
Hope this helps.
This is an addition to Prowlas answer but I dont have enough reputation to commment:
If the /path/to/www is a home directory of a user. You should try:
setsebool -P httpd_enable_homedirs=1
This solved my problem
Source: http://forums.fedoraforum.org/archive/index.php/t-250779.html
There are 2 possible reasons for denied access:
Access is denied by DAC. Double check user, group and file permissions. Make sure the nginx process, when running as the user specified in its config file, can access the new html root path.
Access is denied by MAC. The most widely used of such is SELinux. To check whether it caused the problem, you can stop the nginx process and run this command:
setenforce Permissive
Then start nginx again to see if access is granted.
Alternatively, you can check the file context:
setenforce Enforcing
ls -Zd /usr/share/nginx/html /var/www/html
If the two contexts differ, you may need to change the context for the new html root path:
chcon -R -t httpd_sys_content_t /var/www/html
Restart nginx and see if it works fine. If so, you can make the change permanent:
semanage fcontext -a -t httpd_sys_content_t '/var/www/html(/.*)?'
restorecon -Rv /var/www/html
Some of these commands need to be run as root.
well seems logical, all files are root user, try changing it to nginx user, just wanted to make sure it's not a listing permission denied first.
sudo chown -R nginx:nginx /var/www/html
I have met this problem when I added a new user with a folder /home/new_user as a new virtual host. Make sure these folders (/home, /home/new_user, /home/new_user/xxx...) are 755 so that it resolved my problem. At last, I found my problem were correctly according to the /var/log/nginx/error.log file.
Remember you need to allow other users to read the entire path. Also remember Dropbox will set 700 to its root directory. So chmod 755 ~/Dropbox solved my problem.
The folks using the /home/{user} directory to serve their website need to provide a chmod 755 access on their /home/{user} directory to make this work .
Also , if SELinux is enabled on the server please use the below mentioned commands :-
sudo setsebool -P httpd_can_network_connect on
chcon -Rt httpd_sys_content_t /path/to/www
I was using:
sudo service nginx start
If I use:
sudo nginx
...everything works fine. Can anyone explain the difference between these two?
I ran into the same problem:
Checked nginx.conf to verify the user
Permissions were set properly
Made sure "x" right was set for the entire path
Did a restart from the command line (I'd been using Webmin all this time) and noticed this error:
aed#aed:/var/www/test.local$ sudo service nginx restart
* Restarting nginx nginx
nginx: [warn] conflicting server name "test.local" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "test.local" on 0.0.0.0:80, ignored
Apparently there was a duplicate definition and thus my attempt to access "test.local" failed.
Work fine for me on nginx
semanage permissive -a httpd_t
Another possible reason (NOT IN THIS CASE) is a symlink for index.html file pointing to another directory.
ls -lrt /usr/share/nginx/html/
rsync files to that particular directory will easily solve the problem.
or disable symlinks in nginx.conf
http {
disable_symlinks off;
}
i meet another issue(don't know why yet, but it might be useful for someone else)
i first put the folder under my /home/my_name/www/site_name, and change the owner and change the permission.
then check the selinux stuff.
all the above doesn't solve my problem.
finally, i change the folder to /srv/www/site_name, all is good now.
Modify the file nginx.conf, change the user name to your account name, and restart nginx.it work !
this solved the same problem:
restart Nginx and try again. If it fails, check again the logs. This worked for me
Just want to help somebody out. yes ,you just want to serve static file using nginx, and you got everything right in nginx.conf:
location /static {
autoindex on;
#root /root/downloads/boxes/;
alias /root/downloads/boxes/;
}
But , in the end , you failed. You got "403 forbidden" from browser...
----------------------------------------The Answer Below:----------------------------------------
The Solution is very Simple:
Way 1 : Run nginx as the user as the '/root/downloads/boxes/' owner
In nginx.conf :
＃user nobody;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
YES, in the first line "＃user noboy;" , just delete "#" , and change "nobody" to your own username in Linux/OS X, i.e change to "root" for test. The restart nginx.
Attention , You'd better not run nginx as root! Here just for testing, it's dangerous for the Hacker.
For more reference , see nginx (engine X) – What a Pain in the BUM! [13: Permission denied]
Way 2 : Change '/root/downloads/boxes/' owner to 'www-data' or 'nobody'
In Terminal:
ps aux | grep nginx
Get the username of running nginx . It should be 'www-data' or 'nobody' determined by the version of nginx. Then hit in Terminal(use 'www-data' for example):
chown -R www-data:www-data /root/downloads/boxes/
------------------------------One More Important Thing Is:------------------------------
These parent directories "/", "/root", "/root/downloads" should give the execute(x) permission to 'www-data' or 'nobody'. i.e.
ls -al /root
chmod o+x /root
chmod o+x /root/downloads
For more reference , see Resolving "403 Forbidden" error and Nginx 403 forbidden for all files
You should give nginx permissions to read the file. That means you should give the user that runs the nginx process permissions to read the file.
This user that runs the nginx process is configurable with the user directive in the nginx config, usually located somewhere on the top of nginx.conf:
user www-data
http://wiki.nginx.org/CoreModule#user
The second argument you give to user is the group, but if you don't specify it, it uses the same one as the user, so in my example the user and the group both are www-data.
Now the files you want to serve with nginx should have the correct permissions. Nginx should have permissions to read the files. You can give the group www-data read permissions to a file like this:
chown :www-data my-file.html
http://linux.die.net/man/1/chown
With chown you can change the user and group owner of a file. In this command I only change the group, if you would change the user too you would specify the username before the colon, like chown www-data:www-data my-file.html. But setting the group permissions correct should be enough for nginx to be able to read the file.
Since Nginx is handling the static files directly, it needs access to
the appropriate directories. We need to give it executable permissions for our home directory.
The safest way to do this is to add the Nginx user to our own user group. We can then add the executable permission to the group owners of our home directory, giving just enough access for Nginx to serve the files:
CentOS / Fedora
sudo usermod -a -G your_user nginx
chmod 710 /home/your_user
Set SELinux to globally permissive mode, run:
sudo setenforce 0
for more info, please visit
https://www.nginx.com/blog/using-nginx-plus-with-selinux/
Ubuntu / Debian
sudo usermod -a -G your_user www-data
sudo chown -R :www-data /path/to/your/static/folder
for accepted answer
sudo chown -R :www-data static_folder
for changing group owner of all files in that folder
For me is was SElinux, I had to run the following: (RHEL/Centos on AWS)
sudo setsebool -P httpd_can_network_connect on
chcon -Rt httpd_sys_content_t /var/www/
I ran into this issue with a Django project. Changing user permissions and groups didn't work. However, moving the entire static folder from my project to /var/www did.
Copy your project static files to /var/www/static
# cp -r /project/static /var/www/static
Point nginx to proper directory
# sudo nano /etc/nginx/sites-available/default
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
location /static/ {
root /var/www;
}
location / {
include proxy_params;
proxy_pass http://unix:/run/gunicorn.sock;
}
}
Test nginx config and reload
# sudo nginx -t
# sudo systemctl reload nginx
After digging into very useful answers decided to collect everything related to permissions as a recipe. Specifically, the simplest solution with maximal security (=minimal permissions).
Suppose we deploy the site as user admin, that is, she owns site dir and everything within. We do not want to run nginx as this user (too many permissions). It's OK for testing, not for prod.
By default Nginx runs workers as a user nginx, that is, config contains line user nginx
By default user nginx is in the group with the same name: nginx.
We want to give minimal permissions to user nginx without changing file ownership. This seems to be the most secure of naive options.
In order to serve static files, the minimal required permissions in the folders hierarchy (see the group permissions) should be like this (use the command namei -l /home/admin/WebProject/site/static/hmenu.css):
dr-xr-xr-x root root /
drwxr-xr-x root root home
drwxr-x--- admin nginx admin
drwx--x--- admin nginx WebProject
drwx--x--- admin nginx site
drwx--x--- admin nginx static
-rwxr----- admin nginx hmenu.css
Next, how to get this beautiful picture? To change group ownership for dirs, we first apply sudo chown :nginx /home/admin/WebProject/site/static and then repeat the command stripping dirs from the right one-by-one.
To change permissions for dirs, we apply sudo chmod g+x /home/admin/WebProject/site/static and again strip dirs.
Change group for the files in the /static dir: sudo chown -R :nginx /home/admin/WebProject/site/static
Finally, change permissions for the files in the /static dir: sudo chmod g+r /home/admin/WebProject/site/static/*
(Of course one can create a dedicated group and change the user name, but this would obscure the narration with unimportant details.)
Setting user root in nginx can be really dangerous. Having to set permissions to all file hierarchy can be cumbersome (imagine the folder's full path is under more than 10 subfolders).
What I'd do is to mirror the folder you want to share, under /usr/share/nginx/any_folder_name with permissions for nginx's configured user (usually www-data). That you can do with bindfs.
In your case I would do:
sudo bindfs -u www-data -g www-data /root/downloads/boxes/ /usr/share/nginx/root_boxes
It will mount /root/downloads/boxes into /usr/share/nginx/root_boxes with all permissions for user www-data. Now you set that path in your location block config
location /static {
autoindex on;
alias /usr/share/nginx/root_boxes/;
}
Try the accepted answer by #gitaarik, and if it still gives 403 Forbidden or 404 Not Found and your location target is / read on.
I also experienced this issue, but none of the permission changes mentioned above solved my problem. It was solved by adding the root directive because I was defining the root location (/) and accidentally used the alias directive when I should have used the root directive.
The configuration is accepted, but gives 403 Forbidden, or 404 Not Found if auto-indexing is enabled for /:
location / {
alias /my/path/;
index index.html;
}
Correct definition:
location / {
root /my/path/;
index index.html;
}
You can just do like what is did:
CentOS / Fedora
sudo usermod -a -G your_user_name nginx
chmod 710 /home/your_user_name
Ubuntu / Debian
sudo usermod -a -G your_user_name www-data
sudo chown -R :www-data /path/to/your/static_folder
And in your nginx file that serve your site make sure that your location for static is like this:
location /static/ {
root /path/to/your/static_folder;
}
I bang my head on this 403 problem for quite some time.
I'm using CentOS from DigitalOcean.
I thought to fix the problem was just to set SELINUX=disabled in /etc/selinux/config but I was wrong. Somehow, I screwed my droplet.
This works for me!
sudo chown nginx:nginx /var/www/mydir
My nginx is run as nginx user and nginx group, but add nginx group to public folder not work for me.
I check the permission as a nginx user.
su nginx -s /bin/bash
I found the I need to add the group for the full path. My path is start at /root, so I need to do following:
chown -R :nginx /root