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.

[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
n@2.1.4 /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
└── n@2.1.4


❯ n --version
2.1.3

[dead-claudia]

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

[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.

[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.

[JohnLindahlTech]

@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.

[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

[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

[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.

[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)

[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)

[salomvary]

Had the same issue on macOS 10.14.6 (18G103), the workaround did the job. n@6.0.1

[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

[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