- Newest
- Most votes
- Most comments
I'm thinking it might be a permission issue. This is because the command that fails uses a CWD for a subdirectory of node_modules/ that's only root writeable:
[root@ip-10-0-0-227 dist]# pwd -P
/tmp/deployment/application/node_modules/nodent-runtime/dist
[root@ip-10-0-0-227 dist]# ls -la
total 20
drwxr-xr-x 2 root root 4096 Jun 28 20:59 .
drwxr-xr-x 4 root root 4096 Jun 28 20:59 ..
-rw-r--r-- 1 root root 6294 Jun 28 20:58 index.js
-rw-r--r-- 1 root root 455 Nov 16 2017 README.md
Also, while it fails when run via EB, it works just fine when I run it on the EC2 instance myself.
What I do is I set the $PATH to include node as before, change the working dir to:
/tmp/deployment/application/node_modules/nodent-runtime
and then run
"node build.js"
.
It creates the
"./dist/index.js"
file with no errors inside of
"node_modules/nodent-runtime/dist"
..again, this is only writeable by root.
I'm not sure if EB logins to the EC2 instance using root; tailing /var/log/secure doesn't say.
I may have to use some eb config file to set that node directory to world writeable, or owned by whatever user is used to deploy, before this build step runs, I'm thinking. Any hints on that?
Edited by: V. Miller on Jun 28, 2019 2:11 PM
I've tried using an .ebextension config file to set the directory permisssion, but I suspect the command runs at the wrong time. At least, it doesn't solve the issue.
container_commands:
01_change_permissions:
command: chmod 777 /tmp/deployment/application/node_modules/nodent-runtime/dist
It may also be a red herring, as that directory is recreated, along with the index.js file, after each deploy. Which begs the question why build.js reports that it's failing, unless it's trying to overwrite the file and failing.
Still at a loss.
That should've been "commands", not "container_commands".
It was indeed a permissions issue, but various tactics of setting the /temp/ directory owner or permissions did not help. However, I was finally able to address the issue by creating a .npmrc file with these contents:
unsafe-perm=true
Relevant content
- asked 9 months ago
- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 10 months ago