So, I have installed nginx in an EC2 instance that is running a RHEL OS. Everything is fine, except that I can't remotely edit the nginix conf file using SFTP client Cyberduck.
The problem is AWS EC2 seems to have a restriction on SFTP using root user. I installed nginx with sudo, guess it is saving the conf files with root priviledges. So when I sftp using ec2-user (since root is not allowed), Cyberduck simply complains that you can not save the file because conf file is owned by root.
So nginx developers out there, how do you handle this situation? For me it is really tedious to edit the conf file via ssh and vi editor in EC2 instance. That is why I prefer to edit it locally and sync. But I am not sure how to achieve this. I tried giving access to the conf folder to the ec2-user as per this post too. But invain!. Any help is appreciated.
PS: I installed the nginx using sources and here is the configure command with options I used:
./configure --sbin-path=/usr/bin/nginx --conf-path=/home/ec2-user/conf/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path==/var/log/nginx/access.log --with-pcre --pid-path=/var/run/nginx.pid --with-http_ssl_module --with-http_v2_module
I finally figured out that we can change the permissions of the root folder from where nginx is serving its contents, in this case /var/share/nginx/html to 777. Also ensure the permissions for files inside this folder have 666 permission.
sudo chmod 777 /var/share/nginx/html
sudo chmod 666 /var/share/nginx/html/*
Also enabled read/write permissions for all users for the configuration files as well. This enabled me remote editing the configs as well as html contents.
I have an Nginx server that has some 50 redirect config files it pulls from.
Is there any way to pull this data as a single list of the server names being listened on once Nginx is running? Or is my best option to manually compile the data?
I have SSH'd in but can't see anywhere obvious that this data could be. Is there a command I could use?
Add in your nginx.conf include /etc/nginx/sites-enabled/*; or another path where your sites located
after it check your configs
command nginx -t
and reload
command service nginx reload
If you meant you want to see complete config in one go then you can use below command
nginx -T
This will tell you if there are any errors in config and if not will print the whole config also
Edit-1: 5th Jul 2018
There is nothing like a apachectl -S in nginx. The only other thing you may try and do is to filter the complete config
nginx -T | grep server_name
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
Normally we point nginx at a directory by using the root directive in conf/nginx.conf.
However, I am wondering if I can put something for that option so that nginx will always serve the directory that I am currently working in (that is, the output of pwd) instead of the fixed path. I have tried setting . as the root, but that does not seem to work.
I am running nginx as a non-root user, serving requests at a port greater than 1024.
If you use directive root .;, the real path of root directory is /<nginx_prefix_path>/..
You can use command sbin/nginx -p $(pwd) -c /path/to/nginx.conf to start nginx,
in which case <nginx_prefix_path> is changed to your current working directory.
BTW, command sbin/nginx -h shows the default <nginx_prefix_path>:
-p prefix : set prefix path (default: /usr/local/nginx/)
I compiled the nginx on Ubuntu myself.
I start my nginx with -c nginx.conf parameter.
In my nginx.conf file, I try to turn off error log with but failed.
error_log /dev/null crit;
Still got the error message:
nginx: [alert] could not open error log file: open() "/usr/nginx/logs/error.log" failed (2: No such file or directory)
How could I turn off this log or change its location?
The syntax for disabling the error log is ok, but the docs state that a default logfile is used before the config is read. (which seems reasonable because how would it otherwise tell you you have an error in your config)
Try creating this file by hand with the correct permissions for the user that runs nginx. Or try starting the server as root.
I solved this issue using the -p parameter when starting nginx e.g:
/home/ubuntu/nginx/sbin/nginx -c /home/ubuntu/nginx/conf/nginx.conf -p /home/ubuntu/nginx
This will prepend any log paths specified in the config with the prefix directory.
I just solved this by using this configure parameter:
./configure --prefix="$HOME/nginx" --error-log-path=/dev/stderr
Since I never use this nginx as a daemon and always run it in a shell, it makes sense for it to log errors to stderr.
You can't solve the problem by specifying a -p prefix; because that would only apply to the directives in the configuration file; and as RickyA already noted the problem is that there is a compiled-in error log that nginx wants to open even before it opens the configuration. Changing permissions of the compiled-in error log is not ideal, for obvious reasons.
A workaround is to specify the error log as a configuration on the command line:
$ nginx -p . -g 'error_log error.log;'
or
$ nginx -p . -g 'error_log stderr;'
You'll still get an [alert] but at least it allowed me to start nginx as non-root on Ubuntu.
Per this post on the nginx.org mailing list (extract quoted below), the %%ERROR_LOG_PATH%% is set as a compile option, and checked immediately on startup, causing the "Could not open" alert. Specifying the prefix (with -p) may help suppress the alert, but only if the %%ERROR_LOG_PATH%% was specified as a relative path at compile time.
You can check how it is specified in your current executable with
nginx -V 2>&1 | grep -oE 'error-log-path=\S*'
That is why the solution proposed by #Michael works for some, but not for others.
See changelog:
Changes with nginx 0.7.53
...
*) Change: now a log set by --error-log-path is created from the very
start-up.
*) Feature: now the start up errors and warnings are outputted to an
error_log and stderr.
...
Now compiled in error_log value always used to log errors at start
time (and emits warning if nginx can't open it). Once config file
have been read - error_log from config will be used instead.
If you have compiled nginx with error_log path relative to prefix
- it should be possible to override startup error_log via -p
switch.
Maxim Dounin
There's no need to use a command line parameter. Simply ensure you add the error_log directive to the very top of nginx.conf or at least before any error messages may occur.
nh2's comment from Jan 2016 suggests that this option would have been available for at least a couple years now. I can confirm it works and it's less hassle. Customisation to nginx.conf is less likely to cause issues with updates to a packaged nginx installation than the alternatives.