I have a postinstall script in my package.json file for a node module, that locates a file within the node module and copies it to another directory. if I run the post install script by itself, it executes without issue. However, when I make a tarball of the module and try to install it in another repo, I get a permission denied and exit status 126 message. I tried simplifying the file to a single console.log("foo") line and it still fails to execute. I have manually checked all permissions the target directory and all its parent directories; they are read-write for everyone (Mac). Has anyone encountered this?
I hadn't found this thread until it showed up as related to my posted question, but this solved my problem.
npm install - how to run build scripts with sufficient permissions?
Thanks to Pascal Belloncle
Related
As the title suggests I am receiving the error
/usr/bin/env: node: Permission denied
when trying to run
npm run build
for my react app. The following link is the leadup to this point with all that I've done and tried, not to be included here for the sake of not duplicating questions Error with react-scripts in npm run build.
Additionally, I have viewed this posting, Getting Error /usr/bin/env: node : Permission Denied, and it was unhelpful to me.
Any help is much appreciated.
I was working in a dockerized node environment and noticed that the mounted source code directory had different ownership (running the container as root) from host environment. Changing the ownership using:
chown -R root:root .
made the error go away for me!
The issue ended up being a matter of file ownership. Root was the owner of many things for the project rather than my profile. Simply changed the ownership from root to me.
For me, re-installing node with NVM solved the issue:
Install nvm
nvm install 14
nvm use 14
you should running command as super user sudo npm run build
For anyone else hitting this, there is another avenue of investigation. There might be another factor affecting execute permissions. There's an exec flag on drive mounts to enable script execution (neat safety feature for automounted usb sticks!). So if your code is on a drive that you've mounted, you need that option set to run scripts on it. Tell-tale signs are the permissions on the script being correct (appropriate user, group and execute bits set), but it still complaining about the shebang line (1st line) being the permission denied. Also, if you type mount, you might see noexec set on the mount point where your source code is (it may not show here if exec is set). How your mount is set up varies greatly, but a place to start is your /etc/fstab.
I've installed nodejs as described here.
Everything works fine when I ssh to the server myself. But I've created a script that deploys my application and call it via bitbucket pipelines. Everything else works fine (composer install, php artisan migrate etc.), except npm install. The error message is
./deploy: line 26: npm: command not found
In bitbucket-pipelines.yml I call my script like this:
- step:
script:
- ssh user#ip_address ./deploy
When I call the script by myself everything works. The problem is only with bitbucket pipelines. I have no clue why this happens :(.
Running which composer revealed that at least composer command is not getting picked up from your assumed location i.e., ~/composer dir. Instead, it was found in /opt/cpanel/composer/bin/composer.
which npm returned the following:
no npm in (/usr/local/cpanel/3rdparty/lib/path-bin:/usr/local/jdk/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/X11R6/bin:/root/bin:/opt/bin:/opt/cpanel/composer/bin:/home/handmast/.local/bin:/home/handmast/bin)
Now since you are able to manually run the command npm, you just need to figure about the path from where npm is running and ensure that the path is explicitly added to the user's ~/.bashrc file and things should work fine. You need to do this because as per your observation, ssh is not able to find it.
export PATH=$PATH:/path/to/npm/binary
Note: To avoid any confusion, just remember that while adding the path to your binary, you just have to add the path to the directory where npm resides. Don't add npm at the end. For example, following is incorrect way:
export PATH=$PATH:/home/handmast/bin/npm
Correct way is this:
export PATH=$PATH:/home/handmast/bin
For AWS EC2 (Amazon Linux) launch configuration, I have set some userdata having some sequence of commands which looks like below.
#!/bin/bash -exv \n",
"#Execute Init resource\n",
"whoami\n",
"pwd\n",
"npm -v\n",
Upon instance startup, user data is executing fine and native commands like "whoami" are giving correct output in cloud-init-output.log but it is giving error for npm command with error message like "npm command not found".
But, when I ssh to the instance and try executing some npm commands, it is working fine.
Could some one please guide me in solving this?
Thanks
The user data is executed as root. It is possible the path to npm is not in root's PATH. Specify the full path to npm and it should work.
The reason it works when you ssh is because npm is available in your PATH.
#helloV's answer works fine. Thanks to #helloV.
Still, I tried to find more about PATH issues of root user during instance startup and I found out that nvm.sh of NVM (Node version manager) package in my AMI extends the PATH to add path for 'npm' and 'node'.
This nvm.sh is triggered from .bash_profile -> .bashrc
One thing was clear that .bash_profile of root user was not executed before user data script execution during instance startup. So I sourced .bash_profile in my user data script and now further npm commands in user data script are working fine.
Found out nvm.sh details in https://github.com/creationix/nvm/issues/381
Thanks to Ben Creasy.
Hope this helps.
I'm just new to node and npm and this is frustrating.
Well it's almost all said in the title.
On a Windows 10 x64 using a NON elevated prompt, all npm commands shows:
EEXIST: file already exists, mkdir 'c:\Users\Josep\AppData\Roaming\npm'
at Error (native)
Even npm -v shows it twice before the version number.
Not hapening in an elevated prompt. version numbers differ in an elevated and a user prompt.
Double checked PATH variable. Same on two cmd windows.
Node version 6.10.0
NPM Versions: 4.3.0 at elevated prompt and 3.10.10 at a user prompt.
For me, just adding --force solved it.
I had similar issue, solved it by removing .npmrc file, located at c:\Users\<USER>\ location.
I believe it was caused by running earlier npm config set in wrong location.
Kudos to this comments thread.
In my case remove white space from folder name.
Try reinstalling node and npm for the non-admin account. If that's not an option, you can use the portable version:
Download from http://nodejs.org/dist/
Extract the archive.
Open cmd and cd to the extracted folder.
Run nodevars.bat.
It will set PATH and other things so you can now use node from this folder.
I also had this problem. Just delete npm folder, it will be created again. This problem is due to user privileges.
this is because you have same file in node_modules/Cypress/bin and node_modules/.bin, which is cypress(type=file).
Remove cypress(type=file) from node_modules/.bin, this will resolve the issue.
it happened to me, I had a space in my folders path C:\Users\Jhon Doe, should be C:\Users\JhonDoe.
Microsoft has a bit more information about how this can happen: https://learn.microsoft.com/en-US/troubleshoot/windows-client/user-profiles-and-logon/renaming-user-account-not-change-profile-path
For me, cd ios && pod install && cd .. fixed it.
I had the same issue and was able to resolve it on Windows by running the cmd prompt as Admin.
Go to the folder where you have installed Cypress. For example D:\cypressautomation --> then go to "node_modules" --> and then ".bin" folder. Here in this folder, if there is any file named "cypress", then just delete it (before deleting I think cypress needs to be closed). Reopen the cypress. This worked perfectly fine for me.
In my case. edid like below
※one more, check white space from folder name.
I'm using Gulp to compile some assets on a simple standalone WordPress theme project.
When I run my gulp task that compiles some LESS files I get the following error:
stream.js:94
throw er; // Unhandled stream error in pipe.
^
Error: EPERM, chmod '/Users/harryg/Sites/sites/wordpress/wp-content/themes/samarkand-2/assets/css/main.min.css'
When I run it as sudo the task executes without problem.
Thinking it was a permissions error I chmod'd the entire theme folder and its contents to 777 but this doesn't solve the problem. I have gulp installed globally which may be the issue but I'm not sure how to solve.
EDIT
Even if I run the local gulp I get the same error. I.e. running node_modules/.bin/gulp from my project folder produces the same EPERM error.
`sudo chown -R `whoami` sites/wordpress/wp-content/themes/samarkand-2`
should fix it. Or whatever directory you want to start from. This is no dangerous and might come because of you node-installation. It's pretty common and should be fixed in general after running installs with npm#3.X.X
While #cwelske gives a "hacky" workaround in his answer, the link he provides to the bug report provides a nicer fix for Gulp 3: use vinyl-fs.
npm install vinyl-fs --save-dev
Modify your gulpfile to use VFS:
Add to your requires block: var vfs = require('vinyl-fs');
Modify your output pipe: .pipe(vfs.dest('./output'));
The reason I was facing this error is because the files were owned by a more generic group and user so that multiple team members could work on the project together. Obviously Ubuntu doesn't allow you to chmod someone else's files. I suspect the OP is in a similar situation (the web-server might own the files).
If you do not require this kind of setup, your other option is to change the files to be owned by your user, something like:
sudo chown -R me:me .
Setting file permissions to 777 are not going to help you, because unless you own the file, you cannot chmod it without sudo. (Hence it works when you run gulp as sudo.)
gulp 3.x has a bug that makes it want to chown all files regardless if it already has all required permissions or not. It is supposedly fixed in gulp 4.
The linked bug contains a nice workaround if you know that the files have the correct permissions: Simply replace fs.chmod with an empty function in your gulpfile.js:
var fs = require('fs');
if (1) fs.chmod = function (a, b, cb) {
cb(0);
}