My actual problem is that Nginx is not able to render pages (403 forbidden) despite the permissions being set to 755 for nginx:nginx.
I am using the following command...
[root#wfe1 user1]# strace -p 26934 -e trace=file
Process 26934 attached
stat("/home/user1/site3/index.html", {st_mode=S_IFREG|0755, st_size=6, ...}) = 0
open("/home/user1/site3/index.html", O_RDONLY|O_NONBLOCK) = -1 EACCES (Permission denied)
The output as you can see is Permission Denied. I would like to know which user account was used to access the file? How can I dig in further?
[root#wfe1 user1]# ls -al site3
total 8
drwxr-xr-x. 2 nginx nginx 23 Mar 6 06:12 .
drwx------. 5 user1 user1 4096 Mar 6 06:12 ..
-rwxr-xr-x. 1 nginx nginx 6 Mar 6 06:12 index.html
Take a look in the nginx access logs to see where things are failing
Use ps aux | grep nginx to see which user nginx is running as.
Make sure you have the correct "allow all" permissions set in your nginx config / location stanza.
Related
I am trying to run Nginx on Openshift but facing this directory permissions issues. Due to this error container is not creating.
The following permissions are set to files created manually.
drwxr-xr-x. 3 root root 79 Dec 22 02:50 /etc/nginx
drwxr-xr-x. 2 root root 26 Dec 22 02:50 /etc/nginx/conf.d
-rw-r--r--. 1 root root 5231 Dec 22 02:48 /etc/nginx/mime.types
drwxrwxr-x. 3 root root 25 Dec 22 01:23 /var/cache/nginx
drwxrwxr-x. 2 root root 6 Dec 22 01:10 /var/log/nginx
drwxrwxr-x. 47 root root 1340 Dec 21 06:51 /var/run
like #dbaker mentioned, RedHat being a security company makes their decisions in openshift regarding security more serious or aggressive as one might say, like for example running containers by default with running with random UID's.
you can fix that by reassigning the paths for different Nginx uses.
changing the PID location:
pid /tmp/nginx.pid;
changing the client temp location (your issue):
client_body_temp_path /tmp/nginx/client_temp
and any other paths in a similar fashion.
you can also use the unprivileged nginx image from docker hub aside from the image specified in the other answer from by RedHat as a certified image, ones that should play more nicely with RedHat products oriented towards security. as the other image is due to being deprecated I'm including the other tag recommended by RedHat rhscl/nginx-120-rhel7
Which specific container image are you trying to run? If you use this one -- https://catalog.redhat.com/software/containers/ubi8/nginx-120/6156abfac739c0a4123a86fd -- it will play nicer with OpenShift out of the box.
This sort of problem is almost always due to OpenShift running containers as non-root by default. If you change file permissions to permit write access to GROUP=0 you'll resolve nearly all of them.
I have a Synology Diskstation DS216se running DSM 6.2.3-25426. I've installed MariaDB 10, Web Station, PHP 7.2, and myPhpAdmin, but when I open it at http://diskstation/phpMyAdmin/ I get this error message
"Sorry, the page you are looking for is not found."
I'm using an nginx server in Web Station, and the error log at /var/log/nginx/error.log contains multiple entries like the following
*621 open() "/var/services/web/phpMyAdmin/js/vendor/jquery/jquery.debounce-1.0.5.js" failed (13: Permission denied)
The file, and all other files with permission denied entries in the logs, exist in the /var/services/web/phpMyAdmin/ directory - what permissions need to be granted to the directory for this to succeed?
I hit this as well. I managed to recover, but it effectively amounts to hard clearing any evidence of prior installs of Web Station, PHP 7.2, phpMyAdmin, and any other web related services. Then manually ripping out some bad directories with broken symlinks/permissions.
My hypothesis is that I tried to install adminer prior to this and - having not done any set up for Web Station et. al. - it put the filesystem in a bad state.
I am not willing to try installing adminer again to test this hypothesis.
What I did to fix this:
Backup what you need (e.g., any personal web site).
SSH into your diskstation. Please be aware of what you are doing and keep in mind the big picture. Don't go deleting random things.
Uninstall Web Station, PHP 7.2, Apache, phpMyAdmin, etc. Anything that Web Station would ultimately be inclined to read and serve up.
Verify that /var/services/web doesn't contain anything you care about, and delete it (sudo rm -rf /var/services/web).
Verify that /volume1/web doesn't contain anything you care about, and delete everything inside it (sudo rm -rf /var/services/web). You may need to chmod permissions for this - I ended up leaving the web directory itself intact, but nothing inside.
Reboot. Mount any encrypted disks, etc.
Check that /var/services/web now shows it is symlinked to /volume1/web, e.g. sudo readlink -e /var/services/web.
Also check permissions for /volume1/web, e.g. ls -al /volume1. It should be owned by root:root and have permissive (777) bits.
Install Web Station, PHP 7.2, and phpMyAdmin in that order.
After this, I could open phpMyAdmin and be served its log in screen.
Debugging notes:
For me, when I SSH in I see in the logs similar issues:
2020/12/17 10:36:35 [error] 32658#32658: *1028 "/var/services/web/phpMyAdmin/index.php" is forbidden (13: Permission denied),
ps says that the nginx workers run as the http user (uid=1023(http) gid=1023(http) groups=1023(http)).
The directory /var/services/web/ appears to be owned by root, both group and user:
# ls -al /var/services/web/
total 424
drwxr-xr-x 3 root root 4096 Dec 17 10:29 .
drwxr-xr-x 3 root root 4096 Dec 17 10:22 ..
-rw-r--r-- 1 root root 27959 Apr 13 2016 adminer.css
-rw-r--r-- 1 root root 82 Apr 13 2016 .htaccess
-rw-r--r-- 1 root root 387223 Apr 13 2016 index.php
drwxr-xr-x 10 root root 4096 Dec 17 10:29 phpMyAdmin
It's not clear to me how Web Station's nginx is intended to work at all given the mismatch - perhaps some set of actions I took prior caused it to decide to install with bad ownership.
I decided to leave everything owned by root, but changed group permissions so that http can access:
# chown -R root:http /var/services/web/
# chmod -R 775 /var/services/web/
This got past the initial error, but revealed a new one:
"/usr/syno/synoman/phpMyAdmin/index.cgi" is not found (2: No such file or directory)
Indeed, there was no trace of phpMyAdmin anywhere in that directory. Evidence of a bad install.
I decided to uninstall anything web related: phpMyAdmin, PHP 7, Apache (happened to be installed), nginx, and Web Station. Once I did, I still had two files in /var/services/web: adminer.css index.php.
I had tried adminer prior to this. In /var/services, there were symlinks to specific volume locations, e.g.:
# ls -al /var/services/
total 12
drwxr-xr-x 3 root root 4096 Dec 17 10:22 .
drwxr-xr-x 17 root root 4096 Dec 17 10:21 ..
lrwxrwxrwx 1 root root 18 Jan 20 2020 download -> /volume1/#download
lrwxrwxrwx+ 1 root root 14 Dec 17 10:22 homes -> /volume1/homes
lrwxrwxrwx 1 root root 24 Jan 20 2020 pgsql -> /volume1/#database/pgsql
lrwxrwxrwx 1 root root 13 Dec 17 10:22 tmp -> /volume1/#tmp
lrwxrwxrwx 1 root root 13 Dec 17 10:22 web
Interestingly, web was not symlinked. I fully deleted /var/services/web.
Looking over at /volume1, I do see a /volume1/web, again fully owned by root but with extremely constrained permission:
d---------+ 1 root root 52 Dec 17 10:14 web
There are only a few things in here, which look related to a blank install of Web Station. I fully deleted everything within /volume1/web, but left it as is. With everything maximally cleaned I rebooted.
Upon boot, /var/services/web was now symlinked to /volume1/web, which now also had useful permission bits (777), and owned by root:root. Maybe this was done by some boot recover process, who knows. (I still have nothing web related installed at this point.)
I installed Web Station, then PHP 7.2, then phpMyAdmin.
I had the same issue when accessing my server via
<name>.local/phpMyAdmin/
It worked when I accessed it via
<local ip>/phpMyAdmin/
So I have a homeserver running nginx which is serving a Nextcloud instance. The Nextcloud instance is working beautifully, but I'm getting nginx self-reported errors like such when executing
nginx -t
nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
2020/02/27 15:50:55 [warn] 6985#6985: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
2020/02/27 15:50:55 [emerg] 6985#6985: cannot load certificate "/etc/letsencrypt/live/myserver.com/fullchain.pem": BIO_new_file() failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/etc/letsencrypt/live/myserver.com/fullchain.pem','r') error:2006D002:BIO routines:BIO_new_file:system lib)
nginx: configuration file /etc/nginx/nginx.conf test failed
not quite sure what to do about that - my google-fu is failing me for now. It seems it might have something to do with getting permissions set right, but ls -l /etc/letsencrypt/live/myserver.com outputs
lrwxrwxrwx 1 root ssl-cert 36 Jan 21 08:38 cert.pem -> ../../archive/myserver.com/cert1.pem
lrwxrwxrwx 1 root ssl-cert 37 Jan 21 08:38 chain.pem -> ../../archive/myserver.com/chain1.pem
lrwxrwxrwx 1 root ssl-cert 41 Jan 21 08:38 fullchain.pem -> ../../archive/myserver.com/fullchain1.pem
lrwxrwxrwx 1 root ssl-cert 39 Jan 21 08:38 privkey.pem -> ../../archive/myserver.com/privkey1.pem
-rw-r--r-- 1 root ssl-cert 692 Jan 21 08:38 README
ls -l -R /var/log/nginx doesn't do anything, but executing it as sudo yields:
-rwxrw-rw- 1 www-data www-data 6553 Feb 27 15:19 access.log
for every entry. Does that seem alright?
EDIT: #RichardSmith is the man, his comment below pointing out to run nginx -t as sudo did the trick. I feel slightly stupid now, so thanks man ;). sudo nginx -T now also works, allowing me to further troubleshoot another problem.
#RichardSmith's comment suggested running nginx -t as sudo, which did the trick.
sudo nginx -T now also works, allowing me to further troubleshoot another problem.
I have just installed nginx on Ubuntu 14.04 using the command
sudo apt-get install nginx
Now, when I open my browser and type in the address localhost then I am correctly shown the "Welcome to nginx" page. Also, I checked the config file located in /etc/nginx/nginx.conf and found the following log settings:
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
However, when I check these two files, both are empty. I have opened the localhost page multiple times but still the log files are empty. What might be wrong with my setup ?
I had the same issue after reinstalling nginx to newer version. Seems like log files ownership changed and new nginx couldn't save anything there.
Removing log files and reloading nginx worked for me:
$ sudo rm -f /var/log/nginx/*
$ sudo nginx -s reload
It looks like by default they are set to go to stdout and stderr.
lrwxrwxrwx 1 root root 11 Apr 27 2016 access.log -> /dev/stdout
lrwxrwxrwx 1 root root 11 Apr 27 2016 error.log -> /dev/stderr
So you can remove the symlinks and should be fine.
rm -f /var/log/nginx/*
For all of those whose, like me, came here to figure out why the logs file are empty, and did not realise that you might actually be inside a docker container like one of the comments on another answer suggests, just open a new shell and tail the logs with
docker logs {your-container-id-here} -f
By default Nginx image output the logs access/error to stdout/stderr.
lrwxrwxrwx 1 root root 11 Apr 27 2016 access.log -> /dev/stdout
lrwxrwxrwx 1 root root 11 Apr 27 2016 error.log -> /dev/stderr
We can also check the same by visit this Nginx Dockerfile, look for the comment # forward request and error logs to docker log collector
Now Use the below configuration in order to view the files.
I have changed file name
*error.log = error.logs
access.log = access.logs*
error_log /var/log/nginx/error.logs notice;
access_log /var/log/nginx/access.logs;
Your answer is here
Step1: Open the rsyslog config file
#vi /etc/rsyslog.conf
Step2: Add the following line before the line $IncludeConfig /etc/rsyslog.d/*.conf
$ModLoad imfile
Step3: Create a new file for nginx rsyslog configuration
#vi /etc/rsyslog.d/nginx.conf
Step4: Update the following lines.
# error log
$InputFileName /var/log/nginx/error.log
$InputFileTag nginx:
$InputFileStateFile stat-nginx-error
$InputFileSeverity error
$InputFileFacility local6
$InputFilePollInterval 1
$InputRunFileMonitor
# access log
$InputFileName /var/log/nginx/access.log
$InputFileTag nginx:
$InputFileStateFile stat-nginx-access
$InputFileSeverity notice
$InputFileFacility local6
$InputFilePollInterval 1
$InputRunFileMonitor
Step5: Restart rsyslog service
#service rsyslog restart
I'm getting a "500 Internal Server Error" message when my app tries to write to my sqlite3 database.
Everything works fine when I'm using WEBbrick, but I get the above error when I'm using Apache and Passenger. My app loads the first page but fails when it tries to POST.
Here is how I have everything setup:
awesome.rb file:
require 'sinatra'
require 'data_mapper'
require 'dm-core'
require 'dm-migrations'
require 'slim'
APP_ROOT = File.expand_path(File.dirname(__FILE__))
DataMapper::setup(:default, "sqlite3://#{APP_ROOT}/emails.db")
class Email
include DataMapper::Resource
property :id, Serial
property :email, String, :required => true
end
DataMapper.finalize
get '/' do
slim :index
end
post '/add' do
Email.create params[:email]
redirect '/'
end
config.ru file:
require '/var/www/awesome'
root_dir = File.dirname(__FILE__)
set :environment, ENV['RACK_ENV'].to_sym
set :root, root_dir
set :app_file, File.join(root_dir, 'awesome.rb')
disable :run
run Sinatra::Application
httpd.conf file:
<VirtualHost *:80>
ServerName foo.com
DocumentRoot /var/www/public
<Directory /var/www/public>
AllowOverride None
Options FollowSymLinks
Options -MultiViews
Order Allow,Deny
Allow from all
</Directory>
</VirtualHost>
this is at the very bottom of my apache2.conf file:
LoadModule passenger_module /usr/local/rvm/gems/ruby-1.9.3-p327/gems/passenger-3.0.18/ext/apache2/mod_passenger.so
PassengerRoot /usr/local/rvm/gems/ruby-1.9.3-p327/gems/passenger-3.0.18
PassengerRuby /usr/local/rvm/wrappers/ruby-1.9.3-p327/ruby
I've also given the group www-data write access to /var/www
--UPDATE--
Here is the output for the "ps axu | grep Pass" command:
root 28373 0.0 0.7 220936 1884 ? Ssl 13:15 0:00 PassengerWatchdog
root 28377 0.1 1.0 2067100 2528 ? Sl 13:15 0:10 PassengerHelperAgent
root 28379 0.0 3.8 111856 9508 ? Sl 13:15 0:00 Passenger spawn server
nobody 28382 0.0 1.8 169332 4632 ? Sl 13:15 0:00 PassengerLoggingAgent
I'm running everything as the root user. This is just a test server and I wanted to just get everything working first. I had troubles before with installing ruby system wide so I started over with a clean server and I haven't added any other users.
--UPDATE 2--
emails.db was already set for everyone to read it with chmod 777, but I just changed it to chmod 666. Here is my ls -l output:
-rw-rw-r-- 1 root www-data 442 Dec 23 13:15 awesome.rb
-rw-rw-r-- 1 root www-data 215 Dec 23 12:41 config.ru
-rw-rw-rw- 1 www-data www-data 12288 Dec 23 12:56 emails.db
-rw-rw-r-- 1 root www-data 54 Dec 23 10:55 hello.rb
drwxrwxr-x 2 root www-data 4096 Dec 22 14:50 log
drwxrwxr-x 2 root www-data 4096 Dec 22 15:34 public
drwxrwxr-x 2 root www-data 4096 Dec 23 12:03 tmp
drwxrwxr-x 2 root www-data 4096 Dec 22 17:16 views
I then restarted apache with "/etc/init.d/apache2 restart". I know going from chmod 777 to chmod 666 wouldn't fix my problem, but it is probably a little more secure. I re-ran my app and I still get the same "HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfill the request." I'm pretty sure it still has something to do with apache and sqlite3 because when I comment out the "Email.create params[:email]" line I don't get the error.
--UPDATE 3--
Here is the output of "tail -f /var/log/apache2/error.log":
96.18.233.137 - - [24/Dec/2012 20:46:54] "GET / " 200 706 0.0274
96.18.233.137 - - [24/Dec/2012 20:46:54] "GET /favicon.ico " 404 18 0.0013
96.18.233.137 - - [24/Dec/2012 20:47:01] "POST /add " 14 - 0.0046
And that is all it shows. Chrome shows:
Request Method:POST
Status Code:500 Internal Server Error