How do I change owner/permission to 505 for uid and 507 for gid.
I had tried:
chmod 505:507 file/folder
but it failed.
If you're trying to change the owner/group, then you should use chown command instead, e.g.
chown -v 505:507 file/folder
Also note that to change the ownership, you need to run as root or prefix the command with sudo.
The chmod is for changing the file/folder permissions.
Related
I'm trying to save a file called app.js on a folder called js.
Vs Code pop up this:
Failed to save 'app.js': Unable to write file 'vscode-remote://wsl+ubuntu-18.04/js/app.js'
(NoPermissions (FileSystemError): Error: EACCES: permission denied, mkdir '/js')
I tried:
sudo chown -R user /mnt/c/Users/myUser/Documents/myFolder/proyectFolder
but I still can't save this file.
Try this, fixed it for me
sudo chown -R username path
Example:
sudo chown -R emanuel /home/emanuel/test/
In the SSH terminal:
Recommended :
sudo chmod -R 777 folder_name_where_your_file_exists
or
sudo chmod -R 755 folder_name_where_your_file_exists
this works for me
sudo chown -R $USER:$USER /home/
TLDR;
If you're using a docker container, avoid making files from within the container because the owner and group permissions may cause problems with your editor (in my case VS Code)
I was running docker container for a Django project from Windows Terminal and using VS Code to edit my code.
It is a Linux file (since everything in Linux is a file) permission problem that arises because the files don't have proper user and/or group permissions. So VS Code tries to tell us that.
The problem I found only happened when I created files from within my docker container.
I would run docker exec ... bash
make new files using touch /path/to/file from the container bash
then try to edit those files on VS Code (say urls.py) only to get the scary permissions error preventing the file from saving.
I suspect that making files from within the container embellishes those files with different owner and group settings than your system would default to if you just ran the commands locally (not in the container).
Changing the file permissions with chown -hR and chgrp -hR would do the trick but to avoid the error altogether I stopped making files from within the container.
Try activating polling:
This worked for me during I tried using wsl.
The below is for individual file:
sudo chown yourUserNAme filename
For an entire directory it will be (when you write ls to terminal, you should see your directory to execute this command):
sudo chown yourUserNAme dirName
For recursive (i.e files and folders inside a folder):
sudo chown -R yourUserNAme dirName
Note: yourUserNAme is, if you do pwd under any Documents, you will see the path: /home/jhon/Documents. Here user is jhon.
Run VS Code as administrator and it will fix the problem.
https://answers.microsoft.com/en-us/windows/forum/all/error-in-vs-code-destination-directory-and-says/e70dc626-6b12-4791-a960-8b704e57098d
Install the extension Save as Root in Remote SSH in VS code.
While saving press Ctrl + Shift + P.
This open the command palette.
Search Save as Root
It is a Linux user permissions problem.
you should use the command:
sudo chown -R $USER:$USER.
I am trying to run multiple mongod instances on the same centos machine with different config files.
I am getting following error while running the instance as a service:
sudo service mongod1 start
/var/lib/mongo1: boost::filesystem::status: Permission denied: "/var/lib/mongo1/mongod.lock"
I have added the permissions for the /var/lib/mongo1 using:
sudo chmod -R 600 /var/lib/mongo1
I also tried with 700, 755 and 777 at the end but nothing seems to work.
mongod:mongod is the owner of the folder /var/lib/mongo1
Any help is appreciated.
I know this is really late but I was struggling with this for days and just now found the fix. That being said for future users running into this issue the solution if you're using SELinux is to check the context of the default mongodb path against your own to make sure they are the same by executing
ls -dZ /var/lib/mongo/
the output should look something like this
drwxr-xr-x. mongod mongod system_u:object_r:mongod_var_lib_t:s0 /var/lib/mongo/
if it's not then you can copy it by doing
chcon -R --reference=/var/lib/mongo /your/path
the source can be found here
Maybe the lock file is missing? Which might explain why chmod isn't having the desired effect...
Try:
touch /var/mongo1/mongod.lock
chown mongod:mongod
chmod 600 /var/mongo1/mongod.lock
important :
Don't try to restart mongo using sudo as it tries to change the user to root where as /var/lib/mongodb owner is mongod:mongod
Please remember that Directories needs to have execute permission, but the files within the directories do not need to execute permission.
The following 2 commands worked for me
$ sudo chmod -R 770 /var/lib/mongo1
$ sudo find /var/lib/mongo1 -type f -exec chmod 660 {} \;
This will first give everything under /var/lib/mongo1 execute permission, and then return all the normal files to having only read and write, but not execute.
I believe I ended up mixing up permissions at /etc/ssl directories tree as the last modification was made on 18th November and a day after I could not get my PostgreSQL to work.
When I type in
sudo service postgresql start
I get
FATAL: could not access private key file “/etc/ssl/private/ssl-cert-snakeoil.key”: Permission denied
Checking permissions
~$ sudo -i
~$ ls -la /etc/ssl/private
drw-r----- 2 root ssl-cert 4096 Nov 18 21:10 .
-rwxrwxrwx 1 postgres postgres 1704 Set 4 11:26 ssl-cert-snakeoil.key
Checking group composition
~$ id postgres
uid=114(postgres) gid=127(postgres) groups=127(postgres),114(ssl-cert)
Also I noticed that my ssl-cert-snakeoil.pem file at /etc/ssl/certs/ doesn't have a symlink. I don't know if this makes any difference...
Please, help me sort this out.
Thanks.
Edit: Should it be posted on serverfault instead?
Try adding postgres user to the group ssl-cert
Run the below code to fix your issue:
# > It happened to me and it turned out that I removed erroneously the postgres user from "ssl-cert" group, set it back with
sudo gpasswd -a postgres ssl-cert
# Fixed ownership and mode
sudo chown root:ssl-cert /etc/ssl/private/ssl-cert-snakeoil.key
sudo chmod 740 /etc/ssl/private/ssl-cert-snakeoil.key
# now postgresql starts! (and install command doesn't fail anymore)
sudo /etc/init.d/postgresql start
courtsey to GabLeRoux
Check the output of
$ sudo -u postgres
$ cd /etc/ssl/private
$ ls
If the response is "Permission denied" do
$ chown postgres:ssl-cert /etc/ssl/private/
$ chown postgres:postgres /etc/ssl/private/ssl-cert-snakeoil.key
Only thing that will work if you have changed permissions for /etc/ssl/private
mkdir /etc/ssl/private-copy; mv /etc/ssl/private/* /etc/ssl/private-copy/; rm -r /etc/ssl/private; mv /etc/ssl/private-copy /etc/ssl/private; chmod -R 0700 /etc/ssl/private; chown -R postgres /etc/ssl/private
Copy this whole command (It's a one line code).
If this doesn't work for you, ckeck your postgres user groups by groups postgres and make sure your postgres user have ssl-cert root postgres (Order doesn't matter).
Now lets check your file permissions on ssl/private :
$ ls -la /etc/ssl/
> drwx------ 2 postgres root private
If this is not the output change your permissions with sudo chmod -R 700 /etc/ssl/private and for owners chown -R postgres:root /etc/ssl/private
//Now check permissions on ssl-cert-snakeoil.key,
//which will be inside your **private** directory.
$ ls -la /etc/ssl/private/ssl-cert-snakeoil.key
> -rwx------ 1 postgres root /etc/ssl/private/ssl-cert-snakeoil.key
I was suffering from this issue when attempting to start Postgresql on a remote docker instance. I eventually tracked down the crazy solution here. Basically you have to recreate the directories, chown on it's own doesn't work:
mkdir /etc/ssl/private-copy; mv /etc/ssl/private/* /etc/ssl/private-copy/; rm -r /etc/ssl/private; mv /etc/ssl/private-copy /etc/ssl/private; chmod -R 0700 /etc/ssl/private; chown -R postgres /etc/ssl/private
This error was preventing my PostgreSQL server from running locally.
The following worked for me:
sudo chown postgres:postgres /etc/ssl/private/ssl-cert-snakeoil.key
sudo chmod 600 /etc/ssl/private/ssl-cert-snakeoil.key
Also make sure that /etc/ssl/private has enough permissions.
Some programs can be incredibly pedantic and cost you valuable hours. By running journalctl after sudo systemctl start postgresql I'd see various errors like:
FATAL: could not load private key file "/etc/ssl/private/ssl-cert-snakeoil.key": Permission denied
FATAL: private key file "/etc/ssl/private/ssl-cert-snakeoil.key" must be owned by the database user or root
FATAL: private key file "/etc/ssl/private/ssl-cert-snakeoil.key" has group or world access
DETAIL: File must have permissions u=rw (0600) or less if owned by the database user, or permissions u=rw,g=r (0640) or less if owned by root.
I couldn't make it with work sudo chmod root:root, so I had to settle for sudo chmod postgres:postgres.
EDIT
I haven't tried it, but running deleting and regenerating the snakeoil certificate might work as well:
make-ssl-cert generate-default-snakeoil --force-overwrite
(You may have to run it with sudo, don't know.)
Try setting permissions on the .key file to 600. Postgres doesn't like key files with group or world permissions set. You may also need to change the owner to postgres, though I'm not sure about that.
I am running the postgres server in WSL, and I was facing the error with the ssl-cert file. I managed to make it work by changing the owner of the file to the postgres user I had created, adding the expected user and group IDs to the user as required of the application (111 and 116, respectively, as gleaned from helpful error messages), and voila, I have an active server from within WSL.
sudo useradd postgres
sudo usermod -u 111 -g 116 -a -G ssl-cert postgres
sudo chown postgres /etc/ssl/private/ssl-cert-snakeoil.key
After running the above, there were two more files the user running the server (postgres for me) needed permission to access, both residing in /var/postgresql. I used sudo chown -- twice more to give ownership to postgres. Running sudo service postgresql start will tell you which files you'll need to transfer ownership of through any error messages.
I had other certificates under /etc/ssl/private and hence, changing permissions recursively was out of question.
I tried adding postgres user to ssl-cert group that didn't help either.
I modified the permission of /etc/ssl/private to 716, basically saying that anyone else other than root (user) and ssl-cert (group) can read and execute the directory.
sudo chmod 716 /etc/ssl/private
Then, I modified the ownership of ssl-cert-snakeoil.key
sudo chown postgres:postgres /etc/ssl/private/ssl-cert-snakeoil.key
This worked for me, basically a combination of the answers by #devops and #Noushad
I have a simple script that is unzipping a file to a mounted Windows share. It is normally launched as a Postfix alias when a new email arrives, but even when I run it as root I get a permission denied error.
The script is doing this:
if ( </tmp/*.zip> ){
unzip '</tmp/*.zip>' => '</mnt/win/#1.txt>'
or die "unzip failed: $UnzipError\n";
}
As root I can copy files to /mnt/win without a problem, but when this script is launched by Postfix it fails with permission denied.
/etc/fstab looks like:
//srvr1/tmp /mnt/win cifs credentials=/root/.smbcredentials,iocharset=iso8859-1,sec=ntlm 0 0
ls -ld looks like:
drwxr-xr-x 2 root root 196608 Jul 15 17:24 /mnt/win
Files produced by the script are nobody/nogroup, but I'm not sure how I change the permissions of /mnt/win to allow nobody/nogroup to read/write.
cmhod -R ugo+RW /mnt/win
Also gives permission denied. Is there a way to change permissions in /etc/fstab to allow nobody/nogroup?
You need to use this command to change the permissions of folder & files inside it.
sudo chmod -R R+X /mnt/win
If you want to change the user of the file as well which is nobody/nogroup rightnow, you can use this commands :
sudo chown -R username.username /mnt/win/
Here you can choose any user's name e.g. mine is mukesh
sudo chown -R mueksh.mukesh /mnt/win/
I used the following command to change the permissions of the usr directory from root
root> chmod -R 777 /usr
Now when I try to use the sudo command it gives the following error:
sudo: must be setuid root
On googling, I found that this error happens if /usr is chowned and I need to reinstall Ubuntu. But am I getting this error for chmod? Is there anyway to fix this problem without reinstalling?
To setuid /usr/bin/sudo: chmod +s /usr/bin/sudo.
But you changed ALL file/directory attributes in /usr recursivly (-R). You really should try some rescue mode. I don't think you'll have any chance to repair it.