Im running as root on a smartos64 machine.
My database is at /data/db
Mongod is at /mongo/bin/mongod
I get a 'permission denied' error with no further details when running either
- run ./mongo/bin/mongod or
- sudo ./mongo/bin/mongod
I tried changing permissions with chown on /data/db, but I still get this behaviour. How would I start mongo?
What build of Mongo did you download? I believe SmartOS64 is a derivative of Solaris, so I would try a Solaris build from the Mongo download site. If that doesn't work, you may want to build it from source.
Related
That is:
hashanp#DESKTOP-9E00J4S: ~/cats-cakes$ git add .
error: open("img/cake.jpg"): Permission denied
error: unable to index file img/cake.jpg
fatal: adding files failed
Trying to add image in Git add but keep getting the following message? I tried restarting/reloading git and closing VS Code but nothing worked.
That looks like a git bash session on Windows, or a WSL session.
If you can not easily identify the process which keeps an handle to that file, preventing another program (like git) to access it, I would:
reboot
restart my git bash or WSL2 session
try to add img/cake.jpg before opening any IDE.
Since it is an Ubuntu session, I would also try, for tesdting:
sudo chmod -R 755 img
That way, the folder img will be accessible.
When I created a new .conf file inside /etc/supervisor/conf.d/ and tried to start this program it was showing some errors (fatal error) and restarting frequently by itself. Then I ran the command sudo service supervisor restart but now the supervisor also stopped and couldn't be restarted it. During solving my error the nginx server also got stuck also.
After spending a vast time I recovered it Alhamdulillah and writing the solution in the answer section.
Don't trust the solution entirely for your problem. Your problem may belong to another issues as well.
Sometime Supervisor can show the below horrible error when you restart the
service (by the command sudo service supervisor restart):
unix:///var/run/supervisor.sock refused connection
Try to diagnosis the problem with the command supervisord. You can also run journalctl -xe.
Problems and Solutions:
When you write a new .conf file to inside the /etc/supervisor/conf.d directory which contains some statements that are generating error.
Like, you write some statements that will run a script. That script contains some statements that runsGunicorn to deploy a python web apps. In the script you wrote a statement to bind an unix socket. But the mentioned directory where the unix socket will be created doesn't give permission to create the .sock file there. This can lead the permission error.
The demo gunicorn command is below:
SOCKFILE = /home/shamim/python_project/another_directroy/gunicorn.sock
gunicorn ${DJANGO_WSGI_MODULE}:application \
--name $NAME \
--bind=unix:$SOCKFILE
If the another_directory doesn't give the permission to create a .sock file inside it then an error can be occurred. So give it enough permission to create something here from outside. Or, Bind IP and port instead unix socket (like 127.0.0.1:ANY_PORT). Be sure first the port is not used by another application.
Sometimes the error can be occurred if any directory path is used inside .conf file but actually that directory doesn't exist at all.
Now run the command supervisord.
If the error persists after fixing the above issues and now shows a error like -
another program is already listening on a port that one of our HTTP servers is configured to use
then run the below command to fix this issue:
sudo unlink /var/run/supervisor.sock
If the command above does not work you should check run unlink the file at /tmp/supervisor.sock
Keep in mind that the nginx server can also show some errors and fail to
restart (or start) if any .conf file contains some statement where a socket
is used but actually the socket file doesn't exist or doesn't have enough permission to be executed.
Example: If you write the below code in any nginx file config:
upstream surveyapp_payment_stripe {
server unix:/home/shamim/python_project/another_directroy/gunicorn.sock fail_timeout=0 weight=5 max_fails=3;
}
If the above socket doesn't exist or not have enough permission then some error may be occurred.
Nginx can also show error if any directory path is used here but not exists at all. To run nginx at this time quickly just delete the .conf file or edit it's extension (make another another extension type other than .conf).
Hopefully this explanation will help someone in future.
When I try to go into RStudio Server (1.0.44), I get the following error in the browser:
RStudio Initialization Error
(TypeError) : Cannot read property 'error' of null
This happens before logging in - it has the rotating clock thing for a minute and goes straight into that.
I have tried all sorts of remedies, including restarting the server, rebooting, uninstalling and reinstalling RStudio server, changing the port settings, deleting the .RStudio folder in my home directory, etc. I checked the system log and that didn't seem to have anything relevant. There were a few errors, of course, but nothing after I got the error.
Also, R works fine from the terminal and I have the latest version of both R and RStudio.
Anyone have any ideas?
You probably tried to restart rstudio already, but this is not enough.Follow these steps:
Do a ps -u user where user is one of the user whose session is returning the error in the browser
[root]# ps -u username
PID TTY TIME CMD
19445 ? 00:00:18 rsession
kill the rsession related to it using it's PID.
[root]# kill 19445
start rstudio using sudo rstudio-server start.
Go to the folder contained within the project you were working with last and delete the ProjectName.Rproj file.
restart rstudio using sudo rstudio-server restart
P.S:
If after second step, problem remains, you could remove the .Rproj file using command line: rm directory/of/Rproj/File/ProjectName.Rproj
rm -r .rstudio
sudo rstudio-server suspend-all
worked for me.
I first also moved .RData to a separate folder and upgraded the rstudio server. However, still the problem remained.
I went through a lot of trouble and have finally managed to get it to work again. What ultimately seems to have worked is upgrading to the newest version (1.0.136), deleting all .Rhistory and .Rproj.user files, stopping the server and deleting the .rstudio file in my user profile, and then restarting. I wish I had more info on why it stopped and what fixed it exactly, but at least it's working again. Note that when I upgraded--and before deleting the .rstudio folder (which I had already done a few times), the error message changed to:
Status code 500 returned
So that seems to be the same error--maybe this will help someone else to resolve this problem.
I have a Google Compute Engine VM instance with a Asterisk Server running on it. I get this message when I try to run sudo:
sudo: parse error in /etc/sudoers near line 21
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
Is there a password for root so I can try to change it there? Any suggestions on this?
It looks like you have manually edited the /etc/sudoers file so while you would normally have sudo access, due to the parse error, you won't be able to do this directly.
Here's how to fix this situation.
1. Save the current boot disk
go to to the instance view in Developers Console
find your VM instance and click on its name; you should now be looking at a URL such as
https://console.cloud.google.com/project/[PROJECT]/compute/instancesDetail/zones/[ZONE]/instances/[VM-NAME]
stop the instance
detach the boot disk from the instance
2. Fix the /etc/sudoers on the boot disk
create a new VM instance with its own boot disk; you should have sudo access here
attach the disk saved above as a separate persistent disk
mount the disk you just attached
fix the /etc/sudoers file on the disk
unmount the second disk
detach the second disk from the VM
delete the new VM instance (let it delete its boot disk, you won't need it)
3. Restore the original VM instance
re-attach the boot disk to the original VM
restart the original VM with its original boot disk, with fixed config
How to avoid this in the future
Always use the command visudo rather just any text editor directly to edit the /etc/sudoers file which will validate the contents of the file prior to saving it.
I ran into this issue as well and had the same issue Nakilon was reporting when trying the gcloud workaround.
What we ended up doing was configure a startup script that removed the broken sudoers file.
So in your metadata put something like:
#/bin/sh
rm "/etc/sudoers.d/broken-config-file"
echo "ok" > /tmp/ok.log
https://cloud.google.com/compute/docs/startupscript
As you probably figured out this requires the /etc/sudoers file to be fixed. As nobody has root access to the instance, you will not be able to do this from inside the instance.
The best way to solve this is to edit the disk from another instance. The basic steps to do this are:
Take a snapshot of your disk as a backup (!)
Shutdown your instance, taking care not to delete the boot disk.
Start a new "debugger" instance from one of the stock GCE images.
Attach the old boot disk to the new instance.
In the debugger instance, mount the disk.
In the debugger instance, fix the sudoers file on the mounted disk.
In the debugger instance, unmount the disk
Shutdown the debugger instance.
Create a new instance with the same specs as your original instance using the fixed disk as the boot disk.
The new disk will then have the fixed sudoers file.
Since i bumped into this issue too, if you have another instance or any place where you can run with gcloud privileges, you can run:
gcloud compute --project "<project id>" ssh --zone "europe-west1-b" "<servername>"
I ran this on a server which had gcloud as root, so you login to the other box as root too! Then fix your issue. (if you don't have a box, just spin a micro up with the correct gcloud privileges) saves the hassle of disk stuff etc.
As mentioned in above comments, I am getting the same error like below in gcp VM.
sudo: parse error in /etc/sudoers near line 21
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
To solve this
I have ssh to another vm and become root then I ran gcloud ssh command to our main vm (where you are getting the sudo error.)
gcloud compute --project "<project id>" ssh --zone "europe-west1-b "<servername>"
And BOOM!, now are login as root in the VM.
Now you can access/change the /etc/sudoers file accordingly.
I found this hack better than recreating vm/disks.
Hope this helps to someone!
It is possible to connect to a VM as root from your developers console Google Cloud Shell. Make sure the VM is running, start the shell and use this command:
gcloud compute ssh root#<instance-name> --zone <zone> [--project <project-id>]
where instance-name is found in the Compute Engine VM Instances screen. project-id is optional but required if you are connecting to an instance in a different project from the project where you started the shell.
You can then fix this and other issues that may prevent you from using sudo.
I got a Permission denied error when trying to ssh to the problem instance via gcloud. Using a startup script as mentioned above by #Jorick works. Instructions for it are here. You will have to stop and restart the VM instance for the startup script to get executed. I modified the script slightly:
rm -f /etc/sudoers.d/google_sudoers >& /tmp/startup.log
After the restart, launch an SSH session from the cloud console and check that you are able to view the file contents (with sudo more /etc/sudoers.d/google_sudoers for example). If that works your problem has been solved.
I just worked with Windows 7 before and now I'm working with MAC OS. I cloned my project (it works with Twig and wordpress and I'm using a virtual machine via vagrant) and everything should work but when I enter the website it gives me the following message:
Uncaught exception 'RuntimeException' with message
'Unable to create the cache directory (/vagrant/myProject/cache/c2/94).'
in /vagrant/myProject/wp-content/.../libraries/Twig/Environment.php:1199
I guess it is some kind of problem about permissions but I don't know how to fix it exactly. Any help? Thank you.
As soon as you created a /vagrant directory, I think default permissions are root.
You can try:
sudo mkdir /vagrant/myProject/cache
sudo chown -R $USER:staff /vagrant
And then try again (assuming your current user runs the apache server).
If this does not work, please do:
ls -l /vagrant
and:
ls -l /vagrant/myProject/cache/
And try to set permissions so the cache permissions are the same.