N: macOS Sierra ask for firewall after install any Node Version with "n"

[jjdltc]

Similar to #199 (old issue solved) I note that after install "n" and use to switch between versions the firewall ask for permissions (Because I'm using also ExpressJs for an API Rest). The msg is "Do you want the application “node” to accept incoming network connections?"

I try to re install node and it's work normal, but if I switch with "n" (2.1.3), the problem start again.

[SenhorBardell]

Same here

[dustintheweb]

Also have this issue, anyone come up with a fix?

[tinychimp]

Is there any workaround for this issue?

[ptmccarthy]

I'm running into this as well. Anyone found a workaround or fix?

[troy0820]

What version of N do you have? I'm trying to reproduce the error. Since it's macOS sierra, I can't run it in a container to see how it got there.

[ptmccarthy]

I'm running with the latest version of N. Though npm lists it as 2.1.4 while n itself only reports 2.1.3:

$ npm install -g n
/usr/local/bin/n -> /usr/local/lib/node_modules/n/bin/n
[email protected] /usr/local/lib/node_modules/n

$ n --version
2.1.3

Any time I run a version of node that was installed via N, I get the macOS firewall warning about allowing or denying the application:

Unfortunately it does not seem to remember than I have allowed it, since it asks every time I run any node application.

If I remove N and all of its installed versions, and go back to the bundled installer from nodejs.org I don't get the warnings. I'm assuming it's got something to do with signed code, or lack of signed code on N-installed versions?

[beeman]

This issue has been bugging me fore a while now too.

I thought I found the solution by adding node to the firewall using the cli, but it did not change the behavior.

sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/local/bin/node

Quite annoying, especially when you have a watcher that restarts your node server on changes, you have to click away the message each time.

Also, same issue with the n version number here:

❯ npm install -g n@latest
/usr/local/bin/n -> /usr/local/lib/node_modules/n/bin/n
/usr/local/lib
└── [email protected]


❯ n --version
2.1.3

[isiahmeadows]

I'll note that somehow, there was never a similar issue reported with nvm. Just thought it'd be relevant.

[morkro]

Just to keep this active; I am running into the same issue. Installed 2.1.4 but n --version responds with 2.1.3.

[poislagarde]

Same, but I get 2.1.4 from n --version:

$ n --version
2.1.4

[morkro]

The problem has been fixed for me after I restarted macOS. 😅

[brettspeaks]

This isn't an issue with n. It's an issue with the macos firewall getting confused when n re-links /usr/local/bin/node.

I was able temporarily removed the issue by:

1. Set n to node v. 7.6.0
2. Removed all entries in the System Preferences > Security & Privacy > Firewall Options.
3. Restarted machine.
4. Start express server.
5. Re-allow node to accept incoming connections.
6. Stop and restart express server with no popup.

The issue comes back once you switch node versions again using n even if you eventually go back to v7.6.0.

Super weird and very frustrating. Hope this helps anyone traveling down this rabbit hole.

[slhenty]

Had the same problem, solved it this way:

1. open finder and manually copy /usr/local/n/versions/node/<version>/bin/node to /usr/local/bin
2. open firewall options in system preferences and remove any existing entries for node
3. add a firewall option for /usr/local/bin/node

Now, no matter how many times n switches versions, the firewall entry is intact, and no more 'Deny ... Allow' prompts.

Root Cause: Not really sure, but it appears n does an incomplete copy into /usr/local/bin. Unlike a manual copy with Finder, the n copy exhibits the following 'weirdness':

• Firewall options cannot add /user/local/bin/node... it causes a program failure in System Preferences
• If the firewall option is added in response to the 'Deny .. Allow' prompt, then Firewall Options cannot show the Finder for that entry... Finder briefly flashes a window, then reloads.
• the copied file shows a created date of the last time n did the copy, not the original date on the node distribution

It seems n just doesn't copy all the meta information about the node executable. Also, the latest version of n (as of this writing) takes a very long time to switch versions... which along with the created date being reset might imply that n is doing its own byte copy instead of letting the OS do the work. The source for the n script indicates otherwise (issues a cp command), but it's not clear why it takes so long for the copy.

But... once Firewall Options adds at least one good entry for /usr/local/bin/node (e.g. a manually-copied node), then the 'bad' copies n puts there continue to work.

[zachfedor]

i just tried @slhenty's suggestion and it seems to have cleared up the issue

[unipheas]

I just used @slhenty's suggestion and it works now.

[janur]

I used the @slhenty's suggestion but I could not choose (probably just didn't know how) /usr/local/bin/node from firewall UI.
So I used also @beeman's cli suggestion
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/local/bin/node
That sorted it.

[JohnPhoto]

@janur The magic command for navigating to the correct path is cmd+shift+g and insert path to navigate to.. This is the same for finder but works brilliantly even for these "find file" prompts.

[leakon]

Thanks to @slhenty , I fixed this issue.

I just opened Finder to /usr/local/n/versions/node//bin/node, copied node, then pasted to /usr/local/bin, clicked overwrite to replace the existing node.

Then issue was fixed.

Old node will cause Finder to crash when clicking the file, and several seconds later the Finder will recover by itself.

Hope it can help.

[techwes]

I tried the same fix mentioned above but using cp from the Terminal instead of manually in the Finder. This did not work and had the same issues as the copy n does on its own. A symptom of the issue seemed to be the timestamps being changed on the copied version of node. So I looked into it some more and cp has a -p option

 -p   Cause cp to preserve the following attributes of each source file
        in the copy: modification time, access time, file flags, file mode,
        user ID, and group ID, as allowed by permissions.  Access Control
        Lists (ACLs) will also be preserved.

(man page)

I tried doing the copy with the -p option and it seems to fix the issue just like the manual Finder copy. So I propose that n should be updated to use -p option when copying node to /usr/local/bin which should fix this issue.

[JeremyPlease]

I was looking for a quick way to fix this every time I switched versions with n. So, I used the info from @slhenty, @beeman, and @techwes (thanks!) to create a single command:

# remove current entry in firewall
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --remove /usr/local/bin/node && \
# copy current node from n
cp -pf /usr/local/n/versions/node/$(node -v | cut -d 'v' -f 2)/bin/node /usr/local/bin && \
# add to firewall
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/local/bin/node

[isiahmeadows]

@JeremyPlease that looks like it should work moved into n itself... (Not involved with the project, so my opinion is about 90% irrelevant here.)

[jjdltc]

it appears to be solved after:

• Update n to [email protected]
• Check Firewall preferences and delete one node entry that appears to be corrupted (Does not refer to any file when try to check on finder)

Could be a early version of n that create a bad references in the Firewall ¿?

In any case, I didn't get problems with node versions (n) now.

[glenjamin]

I ran into this just now was able to fix it by forcibly signing the node binary as discussed in this stack overflow answer. https://apple.stackexchange.com/a/150711/14941

sudo codesign --force --sign - /usr/local/bin/node

[JacobJT]

@jjdltc I had only just started using n with version 2.1.11 and experienced this issue, so it is not strictly related to old versions of n. I did have node installed prior to using n to manage versions, so it is possible that the issue arises from having any previous version of node installed that wasn't first installed with a newer version of n?

[solepixel]

This is how I fixed this problem without restarting macOS:

First I ran @glenjamin's command:
sudo codesign --force --sign - /usr/local/bin/node

I don't know if it helped, it didn't solve my problem, but maybe it's a combination of that command and what I did, so I'm including it. Then I performed these steps:

1. Open Security & Privacy
2. Click Firewall
3. Unlock to allow changes
4. Click Firewall Options
5. Find node in the list (mine was listed, if it's not, this may not help)
6. Right Click > Show in Finder
7. Find n in the same directory.
8. Drag n into the Firewall window
9. Make sure "Allow incoming connections" is set on n
10. Click OK

Hope that helps someone.

[jcollum]

I've never installed n and I'm seeing this warning all the time. sudo codesign has not helped. The rest of @solepixel's solution doesn't apply since I'm not using n. I am using nvm so this problem seems to be common to both.

[shadowspawn]

I came across an issue about code signing missing for some downloads of node. I don't think this explains the firewall hacks helping described above, but could still be implicated in some problems.

https://github.com/nodejs/node/issues/11936

The command mentioned there for checking the way gatekeeper does and what I see for 8.11.3 is:

$ codesign --verify --deep --strict --verbose=2 `which node`
/usr/local/bin/node: valid on disk
/usr/local/bin/node: satisfies its Designated Requirement

(I have not reproduced the firewall issue so not able to confirm if this is relevant.)

[danielniquet]

The problem has been fixed for me after I restarted macOS. 😅

This was the fix for me also! I was struggling with closing the popup window for 3 days, because I had not restarted the computer...

[Zashy]

I worked this into some local scripts I use for easy reuse. And eventually other people kept asking me, so I made it into a simple set of scripts that always seems to do the trick for this issue. Thought it might be helpful to post since it's just a paste and go sorta deal now.

sudo /usr/libexec/ApplicationFirewall/socketfilterfw --remove $(which node)
sudo codesign --force --sign - $(which node)
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add $(which node)

[shannon-kay]

This is how I fixed this problem without restarting macOS:

First I ran @glenjamin's command:
sudo codesign --force --sign - /usr/local/bin/node

I don't know if it helped, it didn't solve my problem, but maybe it's a combination of that command and what I did, so I'm including it. Then I performed these steps:

1. Open Security & Privacy
2. Click Firewall
3. Unlock to allow changes
4. Click Firewall Options
5. Find node in the list (mine was listed, if it's not, this may not help)
6. Right Click > Show in Finder
7. Find n in the same directory.
8. Drag n into the Firewall window
9. Make sure "Allow incoming connections" is set on n
10. Click OK

Hope that helps someone.

Awesome! This worked great for me! Thank you!

[paxperscientiam]

Two years later, @slhenty still works. I'm using node >12

[initplatform]

These 3 lines definitely work... would be cool if there was a hook somewhere after n switches to a new version so that it could run these or other scripts...

in the absence of that, I added this to my ~/.bash_profile

nfw() {
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --remove $(which node) ;
sudo codesign --force --sign - $(which node) ;
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add $(which node) ;
}

then I just run nfw after switching node versions with n

I worked this into some local scripts I use for easy reuse. And eventually other people kept asking me, so I made it into a simple set of scripts that always seems to do the trick for this issue. Thought it might be helpful to post since it's just a paste and go sorta deal now.

sudo /usr/libexec/ApplicationFirewall/socketfilterfw --remove $(which node)
sudo codesign --force --sign - $(which node)
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add $(which node)

[shadowspawn]

I am assuming this is not an issue with more recent versions of macOS? If the firewall settings are still an issue with later versions, please add a comment letting me know the version of macOS. Thanks.

[jjdltc]

With [email protected] Still the same issue.
I Try:

I worked this into some local scripts I use for easy reuse. And eventually other people kept asking me, so I made it into a simple set of scripts that always seems to do the trick for this issue. Thought it might be helpful to post since it's just a paste and go sorta deal now.

sudo /usr/libexec/ApplicationFirewall/socketfilterfw --remove $(which node)
sudo codesign --force --sign - $(which node)
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add $(which node)

And now work as @Zashy say.

[salomvary]

Had the same issue on macOS 10.14.6 (18G103), the workaround did the job. [email protected]

[somedayrainbows]

@solepixel 's solution worked for me! Thanks!

[nmiticlevi9]

All of the above works, but when you restart the machine, it's still a problem.
macOS 10.15.2, installed with homebrew and N_PREFIX set to $HOME/.n

[jhalborg]

Have the issue on 10.15.2, using @initplatform 's solution

[shadowspawn]

I have reproduced the problem on macOS 10.15.2, but failed to make sense of what the firewall is doing. In particular in a folder with a simple server and the firewall on:

% /usr/local/bin/node .
[prompt -> allow]
server is listening on 3000
^C
%  /usr/local/bin/node .
[prompt -> allow]
server is listening on 3000
^C
% cp /usr/local/bin/node .
% ./node .
server is listening on 3000
[no prompt!]
% codesign --verify -vv /usr/local/bin/node
/usr/local/bin/node: valid on disk
/usr/local/bin/node: satisfies its Designated Requirement

Running the node as installed using the installer from nodejs.org does _not_ cause a firewall prompt.

[shadowspawn]

I may have stumbled on a solution. Deleting the previous node binary before doing the copy seems to be working. (i.e. apparently copying the binary over the top of the existing binary makes the firewall unhappy.)

e.g.

% rm /usr/local/bin/node
% n 12
   installed : v12.14.1 (with npm 6.13.4)
% node .
server is listening on 3000

[shadowspawn]

Deleting the node binary before installing with n is working for me on 10.15.2: either no security prompts if I automatically allow signed applications, or single prompt if I turn that option off.

I am keen to know if this also works for other people, including on older OS.

[shadowspawn]

Hopefully fixed in n 6.3.1
Tested on macOS Catalina 10.15.3

[ourcore]

@shadowspawn I'm not exactly sure what the solution is. I'm running Node 6.9.1 through nvm 0.33.0 on macOS 10.15.3. Unfortunately, upgrading my Node version is not an option. What binary should I delete to prevent the constant prompts? Thank you

[shadowspawn]

@ourcore The fix for n is when changing node versions, to delete the old binary before copying the new binary into place. nvm works differently so this is probably not relevant to your case.

[ourcore]

@shadowspawn Oh, that makes sense. I just found this 'cause of the same error message

[wswoodruff]

Confirming @shadowspawn 's suggestion of deleting /usr/local/bin/node and allowing n to re-create that binary worked for me on Catalina 10.15.4, n version 7.0.0

[hengsok]

I may have stumbled on a solution. Deleting the previous node binary before doing the copy seems to be working. (i.e. apparently copying the binary over the top of the existing binary makes the firewall unhappy.)

e.g.

% rm /usr/local/bin/node
% n 12
   installed : v12.14.1 (with npm 6.13.4)
% node .
server is listening on 3000

this works