trying to setup nginx to serve anarchistparty.org synapse homeserver reverse proxy. Nginx.conf is currently standard install, hasn’t been edited.
Sudo nginx -t gives:
nginx: [emerg] open() "/etc/nginx/sites-enabled/anarchistparty.org"
failed (2: No such file or directory) in /etc/nginx/nginx.conf:62
nginx: configuration file /etc/nginx/nginx.conf test failed
anarchistparty.org is present in sites-available and symlinked
source
Perhaps you created the symbolic link using relative paths instead of absolute paths, like the author of the source article (and I) did. In this case, the solution is to use absolute paths:
sudo ln -s /etc/nginx/sites-available/anarchistparty.org /etc/nginx/sites-enabled/
I have set up an Ubuntu server on Digital Ocean. Following are the config details:
Ubuntu version : Ubuntu 16.04.2 LTS
Apache version : Apache/2.4.18 (Ubuntu)
I am trying to run a php script through browser which will need to create a file in the directory . I keep getting the following permission denied message in the /var/log/apache2/error.log file fopen(<folder_to_write>): failed to open stream: Permission denied in test_write.php
I discovered that the user www-data (apache2 user) is having a permission issue. I changed the owner of the folder as follows :
chown -R www-data:www-data folder_to_write
and then
chmod 2775 folder_to_write
This did not work.
Finally, I tried the last option. I changed the directory permission to sudo chmod -R 777 folder_to_write hoping to get some lead. However, despite giving this full access permission, I got the permission denied message.
Has anyone experienced any such issue earlier? Not sure what I am doing wrong. I tried the same steps with another user and that seems to be working fine.
I appreciate your help. Thank you so much.
fopen(): failed to open stream:
It seems not able to find directory folder_to_write , Please check your absolute directory path if that's configured right for writing to a file.
I used a specific library that used an embedded version of elasticsearch. Now as we are growing, I want to start elasticsearch as a service.
I followed this guide to install it using yum on a linux machine. I pointed ES to the new directory using
path:
logs: /home/ec2-user/.searchindex/logs
data: /home/ec2-user/.searchindex/data
When I start the service
sudo service elasticsearch start
I get a permission denied error:
java.io.FileNotFoundException: /home/ec2-user/.searchindex/logs/elasticsearch_index_search_slowlog.log (Permission denied)
at java.io.FileOutputStream.open0(Native Method)
....
I guess this has to do with the folder permission, I changed folder permission using:
sudo chown elasticsearch:elasticsearch -R .searchindex
But that didn't help.
Any help?
Your user elasticsearch can't write in the logging folder : /home/ec2-user/.searchindex/logs
Check the permissions with ls -l
Set write permission with the chmod command :e.g. : sudo chmod -R u+wx .searchindex
The issue occurred because .searchindex is located in ec2-user directory which obviously is inaccessible by elasticsearch user created to manage the elasticsearch service.
Moving the folder to /var/lib/elasticsearch did the trick.
The below is my nginx configuration file located in /etc/nginx/nginx.conf
user Foo;
worker_processes 1;
error_log /home/Foo/log/nginx/error.log;
pid /home/Foo/run/nginx.pid;
events {
worker_connections 1024;
use epoll;
}
http {
access_log /home/Foo/log/nginx/access.log;
server {
listen 80;
location = / {
proxy_pass http://192.168.0.16:9999;
}
}
}
As you can see I change log, pid files location into home directory.
When I re-start Linux it seems to work, Nginx records error logs in the file I set and pid file also.
However, when it tries nginx -s reload or the other, It tries to open other error log file.
nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
2015/12/14 11:23:54 [warn] 3356#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
2015/12/14 11:23:54 [emerg] 3356#0: open() "/home/Foo/run/nginx.pid" failed (13: Permission denied)
nginx: configuration file /etc/nginx/nginx.conf test failed
I know, I can solve permission error with sudo but the main issue in here is a error log file(/var/log/nginx/error.log) Nginx tries to open.
Why does it try to access another error log file?
This is old... but I went through the same pain and here is my solution.
As you can see the log is an alert, not a blocking error:
nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
It shouldn't be a problem :) Nginx just likes to check that file on startup...
Just use -p option. Something like this to launch Nginx locally works for me:
nginx -c /etc/nginx/nginx.conf -g 'daemon off;' -p /home/Foo/log/nginx
You might need to fire it with sudo
sudo nginx -t
The alert comes from the nginx initialization procedure, when it checks that it can write to the error log path that has been compiled in with the --error-log-path configure flag. This happens before nginx even looks at your configuration file, so it doesn't matter what you write in it.
Recently (2020-11-19), an -e option was added to nginx, allowing you to override the error log path that has been compiled in. You can use that option to point nginx to a user-writeable file (or maybe stderr).
See https://trac.nginx.org/nginx/changeset/f18db38a9826a9239feea43c95515bac4e343c59/nginx
Yes, Nginx just likes to check that file on startup. I copy the nginx installed directory to another place, I start it, and the pid of the new Nginx still in old place. So I suggest you to delete old directory.
You will get this alert because your user doesn't have permission to modify the log file. I just assign the permission to the Nginx log file and it worked as expected.
just use this command.
sudo chmod 766 /var/log/nginx/error.log
This simple answer is to use sudo.
So when I used sudo nginx -t
Everything turned out fine.
BTW, this had error precipitated for me when I was increasing the file upload limits in PHP.INI on Ubuntu 18.04, and I had restarted my PHP and my NGINX and thats when I tested:
2020/10/19 20:27:43 [warn] 1317#1317: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
2020/10/19 20:27:43 [emerg] 1317#1317: BIO_new_file("/etc/letsencrypt/live/websitename.com/fullchain.pem") failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/etc/letsencrypt/live/websitename.com/fullchain.pem','r') error:2006D002:BIO routines:BIO_new_file:system lib)
nginx: configuration file /etc/nginx/nginx.conf test failed
Check the permissions on the directory /home/Foo/log/nginx/. It must be writable by nginx. Set permissions like so:
sudo chmod 766 /home/Foo/log/nginx
Alternatively reload nginx with sudo
sudo nginx -s reload
I'm running into a permissions problem with Cherokee+uWSGI on Ubuntu Server 13.10 intended for a Django production environment. When I start uWSGI manually as root user prior to launching cherokee, everything goes smooth:
sudo uwsgi --ini /home/instytut21/instytut21l/instytut21/uwsgi.ini
But when I try to access the site through the server (running as www-data) without that, I keep getting a 503 Service Unavailable response and the following message in the logs:
sudo cat /var/log/cherokee/instytut21.error.log
realpath() of /home/instytut21/instytut21.pl/instytut21/uwsgi.ini failed:
[core/utils.c line 3574]
I've spent a good while trying to figure out what causes the problem. I've tried giving ownership to $USER:www-data and www-data:www-data with all kinds of file permissions ranging from 600 to 777.
I don't want to run the server as root for security reasons. How can I make the ini file accessible to cherokee?
I finally found a solution to a similar problem at www-data permissions? . I slightly modified it and solved my problem by executing the following commands.
Own the whole directory by me and group www-data:
sudo chown -R $USER:www-data /home/instytut21/instytut21.pl/
Grant all permissions to the group:
sudo chmod -R g+rwx /home/instytut21/instytut21.pl/
Ensure all uploaded filed get the same permissions:
sudo chmod -R g+s /home/instytut21/instytut21.pl/