I tried to use SSL by Node.js but it doesn't work because permission denied.
try {
var TLSoptions = {
key: fs.readFileSync("/etc/letsencrypt/live/domain.work/privkey.pem"),
cert: fs.readFileSync("/etc/letsencrypt/live/domain.work/cert.pem")
};
https.createServer(TLSoptions, app).listen(port, host, function() {
console.log("TLS Website started.")
}); catch(e) {
console.log(e)
}
=>
{ Error: EACCES: permission denied, open '/etc/letsencrypt/live/domain.work/privkey.pem'
at Object.fs.openSync (fs.js:663:18)
... (Librarys dump)
errno: -13,
code: 'EACCES',
syscall: 'open',
path: '/etc/letsencrypt/live/domain.work/privkey.pem' }
So I tried re-make files of *.pem.
rm -f /etc/letsencrypt/live
rm -f /etc/letsencrypt/archive
rm -f /etc/letsencrypt/renewal
sudo ./letsencrypt-auto certonly -a standalone -d domain.work
and check file authority.
/etc/letsencrypt/live/domain.work$ ls -lsa
total 12
4 drwxr-xr-x 2 root root 4096 Jan 3 21:56 .
4 drwx------ 3 root root 4096 Jan 3 21:56 ..
0 lrwxrwxrwx 1 root root 37 Jan 3 21:56 cert.pem ->
../../archive/domain.work/cert1.pem
0 lrwxrwxrwx 1 root root 38 Jan 3 21:56 chain.pem ->
../../archive/domain.work/chain1.pem
0 lrwxrwxrwx 1 root root 42 Jan 3 21:56 fullchain.pem ->
../../archive/domain.work/fullchain1.pem
0 lrwxrwxrwx 1 root root 40 Jan 3 21:56 privkey.pem ->
../../archive/domain.work/privkey1.pem
/etc/letsencrypt/archive/domain.work$ ls -lsa
total 24
4 drwxr-xr-x 2 root root 4096 Jan 3 21:56 .
4 drwx------ 3 root root 4096 Jan 3 21:56 ..
4 -rw-r--r-- 1 root root 1789 Jan 3 21:56 cert1.pem
4 -rw-r--r-- 1 root root 1647 Jan 3 21:56 chain1.pem
4 -rw-r--r-- 1 root root 3436 Jan 3 21:56 fullchain1.pem
4 -rw-r--r-- 1 root root 1708 Jan 3 21:56 privkey1.pem
but It is not resolved and I cannot find any mistakes and problems.
How to resolve this problem?
When you use sudo to issue the certificates, they will be owned by root.
Since node is not run as root, and the permissions on the certificate folder do not allow them to be opened by anyone except the owner, your node app cannot see them.
To understand the solution, let us assume node is running as the user nodeuser
You can get your user on ubuntu by using : whoami or ps aux | grep node
Solution #1 (temporary):
You could switch the owner of the certificates to your node user.
$ sudo chown nodeuser -R /etc/letsencrypt
However, this may break any other items that look at the cert, such as Nginx or Apache.
It will also only last till your next update, which is no more than 90 days.
On the other hand, whatever script you have that renews the cert can also set the owner.
Solution #2 (do not do this):
Run node as root.
sudo node index.js
This will run node as a root user, which means that the terribly insecure surface of node can access everything on your system. Please don't do this.
Solution #3 (do not do this either):
Open the certificates to everyone.
The certificates are stored in /etc/letsencrypt/archive/${domain}/cert1.pem, and are linked to from /etc/letsencrypt/live/${domain}/cert1.pem.
All folders in both of these paths are +x, meaning that all users on the system can open the folders, with the exception of the "live" and "archive" folders themselves.
You can make those open as well by changing their permissions.
$ sudo chmod +x /etc/letsencrypt/live
$ sudo chmod +x /etc/letsencrypt/archive
This is bad as it allows access from other unexpected sources. Generally opening folders to everyone is a bad idea.
Solution #4 (do this):
On the other hand, you can create a limited group, and allow the permissions to only be opened for them.
// Create group with root and nodeuser as members
$ sudo addgroup nodecert
$ sudo adduser nodeuser nodecert
$ sudo adduser root nodecert
// Make the relevant letsencrypt folders owned by said group.
$ sudo chgrp -R nodecert /etc/letsencrypt/live
$ sudo chgrp -R nodecert /etc/letsencrypt/archive
// Allow group to open relevant folders
$ sudo chmod -R 750 /etc/letsencrypt/live
$ sudo chmod -R 750 /etc/letsencrypt/archive
That should allow node to access the folders with the certs, while not opening it to anyone else.
You should then reboot or at least logout and in after these changes.
(Many changes to permission and groups require a new session, and we had issues with PM2 until reboot.)
On ec2 instance you can do sudo reboot.
Should something go wrong and you want to revert to original settings follow this
// Delete Group
$ sudo groupdel nodecert
// Reset Permission
$ sudo chown -R :root /etc/letsencrypt/live
$ sudo chown -R :root /etc/letsencrypt/archive
// Check Permissions
$ sudo ll /etc/letsencrypt/
I'm not familiar with Node.js, but it's clearly the same permissions problem as with PostgreSQL. So the same solution should work fine. This allows you to leave the permissions on /etc/letsencrypt as they are :
copy the certificates to your Node.js directory
chown the copied files to your "node" user
You can have a script doing that in /etc/letsencrypt/renewal-hooks/deploy which will be called everytime you renew your certificates.
Example /etc/letsencrypt/renewal-hooks/deploy/10-certbot-copy-certs :
#!/bin/bash
domain=domain.work # using your example name
node_dir=/path/to/cert_copies
node_user=nodeuser
cp /etc/letsencrypt/live/$domain/{fullchain,privkey}.pem "$node_dir"/
chown $node_user "$node_dir"/*.pem
This worked for me:
Copy all pem files that you need into the root folder of your project:
sudo cp /etc/letsencrypt/live/www.your-domain.com/privkey.pem /home/your-username/your-server-directory/privkey.pem
Read the files like so:
.createServer(
{
key: fs.readFileSync("privkey.pem"),
cert: fs.readFileSync("cert.pem"),
},
Grant permissions:
sudo chown your-username -R privkey.pem
I was using ec2-user on Amazon Linux 2 instance and had the same problem. This worked for me:
sudo chown ec2-user -R /etc/letsencrypt
The above top answer by #SamGoody didn't work for me since it didn't set all the group permissions. It worked after I setup the nodecert group as he suggested like this
$ sudo addgroup nodecert
$ sudo adduser nodeuser nodecert
$ sudo adduser root nodecert
and then did
$ sudo nautilus
and clicked down to /etc/letsencrypt then right clicked "Properties" and changed the group permissions manually to nodecert "Access files" in the following two folders and their domain name subfolders
/etc/letsencrypt/live
/etc/letsencrypt/archive
Also changed group permissions manually to nodecert "Read-only" for all contained files and symlinks.
I'm using Oracle Linux 5.7 x86 on Virtual Box 5.1.8 Window 10 x64. I have shared a host folder Temp with VM and can access it and trying to copy its contents to VM but stuck at;
[root#localhost ~]# cd /downloads
[root#localhost downloads]# cp /media/sf_Temp/*.zip
cp: target `/media/sf_Temp/V25347-01.zip' is not a directory
[root#localhost downloads]#
I guess I'll need to change the permissions of shared folder to 777 (drwxrwxrwx) but cannot. Is chmod 777 /media/sf_Temp right command for this?
[root#localhost sf_Temp]# ls -ld /media/sf_Temp
drwxrwx--- 1 root vboxsf 12288 Oct 25 20:46 /media/sf_Temp
[root#localhost sf_Temp]# ls -ld /downloads
drwxrwxrwx 2 root root 4096 Oct 26 19:14 /downloads
[root#localhost sf_Temp]#
You are already root, you don't need any other permissions.
cp command needs two arguments, one for target file/folder, one for destination.
cp origfile newfile
http://www.computerhope.com/unix/ucp.htm
I have added the following to the file /etc/sudoers using the visudo command:
nick ALL=(ALL:ALL) ALL
But when I log in as nick and attempt something like mkdir .ssh I get:
mkdir: cannot create directory ‘.ssh’: Permission denied
Likewise, I cannot save files I have edited.
Running ls -la from the home directory gives me:
drwxr-xr-x 5 nick nick 4096 Apr 7 19:07 .
drwxr-xr-x 3 root root 4096 Apr 7 17:32 ..
-rw-r--r-- 1 nick nick 220 Aug 31 2015 .bash_logout
-rw-r--r-- 1 nick nick 3771 Aug 31 2015 .bashrc
drwx------ 2 nick nick 4096 Apr 7 18:29 .cache
drwxr-xr-x 2 root root 4096 Apr 7 19:07 .nano
-rw-r--r-- 1 nick nick 675 Aug 31 2015 .profile
Which if I'm not mistaken is showing that I have no write access to anything. (Correct me if I'm wrong. I'm only passingly familiar with UNIX permissions.)
Why can't this user do anything despite being given full permissions in sudoers?
UPDATE:
This problem fixed itself. I do not know what the problem was but it was no longer a problem when I logged on a couple days later.
For the record, I was attempting to configure a fresh DigitalOcean server running Ubuntu 15.10 x64. My local computer is a MacBook running El Capitan.
My guess is that the remote server restarted or somehow otherwise incorporated the change automatically in the interim. I had already tried running sudo reboot producing no results, so I'm still not sure how this could be.
I was also experiencing some local WiFi connection dropping at the time but as my SSH connection seemed to be operational I'm not sure if this could be related.
I'm also not an expert to Linux, but to me it seems like you have to use sudo mkdir .ssh instead of mkdir .ssh. You allowed your user to behave like root(who has rights to write to directory), but for doing that you have to use sudo command.
Here is the simple explanation of how it works(with pictures): https://www.garron.me/en/linux/visudo-command-sudoers-file-sudo-default-editor.html
Here is the serious documentation: https://help.ubuntu.com/community/Sudoers
I messed up the symbolic links of my libblas.so.3
I get the error message:
sudo update-alternatives --list libblas.so.3
update-alternatives: error: cannot stat file '/usr/lib/libblas/libblas.so.3': Too many levels of symbolic links
When I do:
ls -l /usr/lib/libblas/libblas.so.3:
lrwxrwxrwx 1 root root 30 Nov 23 15:15 /usr/lib/libblas/libblas.so.3 -> /etc/alternatives/libblas.so.3
Then, again:
ls -l /etc/alternatives/libblas.so.3
lrwxrwxrwx 1 root root 29 Nov 25 14:36 /etc/alternatives/libblas.so.3 -> /usr/lib/libblas/libblas.so.3
Any help to get ot of this situation would be very much appreciated. I do not know if it is enough information. If not, let me know and I try to provide more. Thanks.
I guess the problem is that /usr/lib/libblas/libblas.so.3 links back to etc/.., however it should point to the actual file. How can I do that?
I had to remove the link in the alternatives directory:
sudo rm /etc/alternatives/libblas.so.3
Then, I recreated the link, but pointnig to a real library file. For that I chose the corresponding one from the atlas package:
sudo ln -s /usr/lib/atlas/atlas-base/libblas.so.3 /etc/alternatives/libblas.so.3
I have a directory cyanspring with a nohup.out file.
drwxr-xr-x 12 usr1 usr1 4096 Aug 20 13:59 cyanspring
Owner of the file is able to read it:
[root#lw414 usr1]# sudo -u usr1 ls -l cyanspring/nohup.out
-rw-r--r-- 1 usr1 usr1 30617 Aug 20 14:00 cyanspring/nohup.out
When I try to read it with another user, I get Permission denied.
[root#lw414 usr1]# sudo -u zabbix ls -l cyanspring/nohup.out
ls: cannot access cyanspring/nohup.out: Permission denied
If i go inside the directory, I am able to read the file with the same user who had "Permission Denied".
[root#lw414 usr1]# cd cyanspring
[root#lw414 cyanspring]# sudo -u zabbix ls -l nohup.out
-rw-r--r-- 1 usr1 usr1 30617 Aug 20 14:00 nohup.out
Absolute path doesn`t work as well.
I thought it doesn`t matter where you try to access the file from as long as you have the link and permissions. Can anybody give me a hint where I am wrong? Could it be because of outer folders permissions?
You got "Permission denied" because user zabbix does not have search permission to lachesis directory.
This can be fixed by starting this command from lachesis directory:
sudo chmod go+x .
Permissions are calculated for each directory beginning from current directory if you give relative path, or beginning from root, if you give absolute path.