I'm trying to restart (it is running) MongoDB on Ubuntu 14.04 but keep getting failures with this line in the log error getting file /srv/mongodb/keyfile: Permission denied
Here's directory structure
drwxr-xr-x 3 root root 4096 Jan 31 05:54 srv/
drw------- 2 mongodb mongodb 4096 Jan 31 07:07 mongodb/
-rw------- 1 mongodb mongodb 876 Jan 31 07:07 keyfile
The user running mongod is "mongodb", group "mongodb" so it should be available for reading.
If I change permissions on mongodb/ and keyfile to -rw-r--r-- it becomes readable, but mongo claims it's too permissive of course
Going cookoo with this thing already. Any suggestion what's wrong here?
I've had the same problem before, and the solution I found and was not documented had to do with the context. If you are in Linux try:
ls -lahZ
That will display in list, all files, sizes in human readable and Z for contexts, I noticed that the keyFile must have "system_u:object_r:mongod_var_lib_t:s0" context, so it gets fixed with:
chcon system_u:object_r:mongod_var_lib_t:s0 mongodb-keyfile
Hope that helps!!
I got the mongod service working by changing the owner of the key file to mongod
sudo chown mongod:mongod mongodb.key
the mongod process owner is mongod which tries to access the file
In addition to read and write permission for a directory, usually you must have an execute permission as well (more info at http://en.wikipedia.org/wiki/File_system_permissions#Permissions). So, you have to set the following permissions:
chmod 700 /srv/mongodb/
chmod 600 /srv/mongodb/keyfile
Since none of the answers here solved my problem, and I had the same problem exactly, I'll try to post what worked for me.
My solution:
Stop Mongo
Edit mongod.conf and temproraily comment out the attribute keyFile: /path/to/key
Start Mongo
sudo chown mongod </path/to/key>
sudo chmod 400 </path/to/key>
Remove comment from KeyFile attribute in mongod.conf
Restart Mongo
Hope this helps
Related
I am trying to setup Docker with Jenkins and I need to read /var/run/docker.sock.
I tried temporarily to set permission 666 on file /var/run/docker.sock but when I try to read it as jenkins user it says permission denied.
As far as I know if file permission is 666 any user can read it.
srw-rw-rw- 1 root docker 0 Oct 17 17:05 docker.sock
drwxr-xr-x 31 root root 1100 Oct 17 17:05 run
Directory permission is not issue, /run directory has permission 755. Selinux is disabled. Jenkins user is part of docker gorup.
I do not know what is the problem.
Kind regards,
Ivan
create jenkins user on your host
get this user id
change ownership of /var/jenkins_home to fetched id.
I found the problem, I was mounting /etc/passwd and /etc/groups to docker container but for some reason docker didn't correctly added jenkins user to docker group inside container.
I had to add group_add: - <docker_group_id> inside docker-compose file. Now everything is working as expected.
I thought that there was some problem with Centos OS but I found out that someone already had this problem documented at this link: Linux user groups missing when user mounted to container
I hope this information will help someone.
I have installed mongodb 2.6 in a ubuntu 14.02 server. To allow remote access I added the static Ip to /etc/mongod.conf
bindIp= 127.0.0.1, 192.168.0.150
I edited the file as root user using sudo command.
After this mongodb is not starting as service on boot up. But I can start it using following command :
sudo mongod --dbpath /var/lib/mongodb
As I understand I made some permission problem while editing conf file. I tried a few solutions including changing owner of /etc folder to mongodb as well as current system user. But they are not working. I am a very new user to linux environment. Any help would be much appreciated.
Edit:
Result of ls -l /etc/mongod.conf:
-rw-r--r-- 1 root root 1716 Aug 14 23:32 /etc/mongod.conf
Also the result for the command:
sudo service mongod start
is:
mongod start/running, process 2660.
But if I try to open mongo client with mongo, I get
errno:111 connection refused, connection attempt failed at src/mongo/shell/mongo.js:146
this line should be:
bindIp=[127.0.0.1,192.168.0.150]
I've installed ghost blog to my digitalocean droplet.
Everything's running fine with root user.
However, I've created another user to run apps (including ghost) to make things more secure.
I've installed pm2, following this guide https://www.digitalocean.com/community/tutorials/how-to-use-pm2-to-setup-a-node-js-production-environment-on-an-ubuntu-vps. I also have forever installed.
The problem is, I'm not able to start my blog with the created user since the blog is located at /var/www -- When I sudo-start, it of course works, however I'm not sure if it's possible to add apps to startup to run as another user?
If there is a way, I would love to know.
Try this:
Move your blog location to /var/www/[blog_directory]
Where blog_directory is "ghost" or the name of your blog, or whatever.
e.g., /var/www/ghost
Then make sure your permissions look like this:
Permissions on /var:
drwxr-xr-x 21 root root 4096 Oct 20 23:55 var
Permission on /var/www:
drwxr-xr-x 8 root root 4096 Oct 1 01:04 www
Notice that everybody has directory execute permissions on both /var and /var/www
Then chown and chmod the actual blog directory so that your blog user has rwx permissions
chown -R [blog_user] [blog_dir]
chmod 755 [blog_dir]
You should now be able to start the blog as blog_user
Or, you could just visudo to add the necessary permissions for your blog_user to run the blog and use "sudo [blah]" in the various script files.
We have a working version of Nagios 3.2.0 running on two other servers but on these new server we installed it using apt-get install but keep getting the following problem.
The permissions and config file is all default from install and everything seems correct when comparing it to the working versions we have of Nagios...
Note: The Nagios website is running but when i click on any option on the left i get this...
Error: Could not read object configuration data!
Verify configuration options using the -v command-line option to check for errors.
Check the Nagios log file for messages relating to startup or status data errors.
Running
sudo /usr/sbin/nagios3 -v /etc/nagios3/nagios.cfg
Gives:
...
Total Warnings: 0
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
/var/log/nagios3/nagios.log gives no errors, just a bunch of:
...
[1389054450] Auto-save of retention data completed successfully.
[1389058050] Auto-save of retention data completed successfully.
Not a permission issue either tried changing everything to nagios user and group but no luck:
drwxr-xr-x 4 root root 4096 2013-12-10 16:35 .
drwxr-xr-x 141 root root 12288 2014-01-06 16:27 ..
-rw-r--r-- 1 root root 1905 2011-06-08 01:07 apache2.conf
-rw-r--r-- 1 root root 12218 2011-06-08 01:08 cgi.cfg
-rw-r--r-- 1 root root 2441 2011-06-08 01:08 commands.cfg
drwxr-xr-x 2 root root 4096 2013-12-10 16:35 conf.d
-rw-r--r-- 1 root root 26 2013-12-10 16:35 htpasswd.users
-rw-r--r-- 1 root root 43769 2011-06-08 01:08 nagios.cfg
-rw-r----- 1 root nagios 1293 2011-06-08 01:07 resource.cfg
drwxr-xr-x 2 root root 4096 2013-12-10 16:35 stylesheets
Changed it back to root.
Stopped Nagios and restarted but still nothing. Please help!
This is a permission issue, webserver user should be able to accees nagios directory structure.
try the following . assuming your web server is not running as the root user.
chgrp -R webserver_user /var/cache/nagiosx/
and also check other nagios directories for correct permissions.
run nagios as daemon
/usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
Solved it a few days ago. Apache on these servers had been configured long ago to run as a different user, not www-data. This did not solve the problem we had back then so we left it as is and forgot about apache. Now that we have Nagios running on apache this caused the problem.
So it was a permission issue in the end.
Note: When checking if it is a permission issue, don't just check the file and directory permissions, check that what needs access to them is indeed running as that user in its configuration. In this case it was changed in /etc/apache2/envvars
Lesson learnt.
In my case (Nagios 4, Centos 7), I got this error because of selinux permissions (although no traces of any denies were logged to syslog). Simple way to test if the issue is selinux:
Load page, confirm failue.
Run command getenforce, should return Enforcing.
Run command setenforce 0.
Reload page. If it now works, the error is related to selinux permissions.
Optional:
Run command setenforce 1.
Reload page, it should fail again.
There was a SELinux issue, and if you don't like to turn off the security,
you can create a rule just for this situation.
to see the error in human readable format
audit2allow -a -w
have audit2allow create a te allow rule
audit2allow -a -M nagios-www
semange nagios-www.pp
refresh and see it works
The nagios configuration file is referenced in the cgi config file, /etc/nagios3/cgi.cfg. Check if that file contains the line
main_config_file=/etc/nagios3/nagios.cfg
In my case it was permissions on /var/cache/nagios3. You can confirm it by straceing the CGI, i.e. sudo su -s /bin/sh -c 'REQUEST_METHOD=GET strace -fo /tmp/strace.log /usr/lib/cgi-bin/nagios3/status.cgi' www-data.
In my case the web server didn't have permission to access /var/log/nagios/nagios.log.
Had the same problem after an update from Nagios 3.5 to Nagios 4.3 using the RPM packages from EPEL. Solved installing the appropriate package containing the SELinux profile (yum install nagios-selinux). For more details: https://serverfault.com/q/894349/217522
In my case I had to bring broader permissions to objects.cache file. In my case my file is at:
/usr/local/nagios/var/objects.cache
hope this helps
I've set up Symfony2 on the AWS Linux AMI (a free tier micro instance) and set up PHP-FPM and nginx successfully.
My Symfony app works.. until I use the command line to clear the cache. When I do this the /app/logs and app/cache/ folder becomes owned by root and the app can no longer write to it.
I can manually chmod 777 / chown nginx:nginx these files after each cache clear, but there must be a better way?
I've tried using a bash function to su nginx; before it clears the cache, but that doesn't work.
Before cache folder before cache clear:
drwxrwxrwx 11 nginx nginx 4096 Nov 4 13:23 dev
drwxrwxrwx 10 nginx nginx 4096 Nov 4 20:39 prod
And after:
drwxrwxrwx 11 nginx nginx 4096 Nov 4 13:23 dev
drwxr-xr-x 10 root root 4096 Nov 4 20:39 prod
Is this something I can fix in the app, or is there a way of setting up the permissions so they don't become rooted?
Edit: I should also mention I tried:
sudo chmod +a "nginx allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs
But the server doesn't recognise +a.
Also tried using:
setfacl -R -m u:nginx:rwx app/cache app/logs
Which doesn't error, but doesn't fix the issue.
sudo -u nginx php app/console cache:clear
Edit:
Can't accept this answer yet but this worked for me:
So I successfully enabled ACL on my mount following the guide here: http://blog.dsyph3r.com/2011/09/symfony2-using-setfacl-for-cache-and.html
For newbies like, me note the label of the drive is (somewhat strangely) "Label=/" in fstab.
Once that was done I used
setfacl -R -m u:nginx:rwx app/cache app/logs
setfacl -dR -m u:nginx:rwx app/cache app/logs
Now I can clear cache at will it seems.
Original (only use if you cannot or will not enabled ACL):
I followed a help page which got me to set umask(0000); in numerous places, namely the app/app*.phps and the app/console script. This seems to have worked, but I'm not sure of the implications.
Leaving question open for non-umask solutions. Looking into activating ACL on my mount, but new to that and it all seems.. strangely named.