Error: listen EACCES: permission denied :::8059 in my azure web app running on Windows using Node JS

Question

I have started running into an issue with a couple of my azure web apps. I get the included error message when I am building in the Kudu debug console. We are running around 50 different web apps and I had never seen this bug until about a week ago. I have it showing on 3 web apps now. They have all worked fine previously. I have tried building with npm run start and with node index.js. I have tried a variety of different PORT numbers and get this error about 90% of the time. The exception to this is the first time I have ever built on that web app. I have tried using the Stop button then the start button to clear the cache in case that was the issue. I really need to figure out what the real issue is and get it fixed ASAP. Any help you might have would be greatly appreciated!

events.js:291

  throw er; // Unhandled 'error' event  
  ^  

Error: listen EACCES: permission denied :::8059
at Server.setupListenHandle [as _listen2] (net.js:1316:16)
at listenInCluster (net.js:1364:12)
at Server.listen (net.js:1450:7)
at Function.listen (C:\home\site\wwwroot\node_modules\express\lib\application.js:618:24)
at Object.\

Answer 1

Hi @Dave Rushton ,

Apologies for the delayed response. It's difficult to ascertain the root cause without additional information regarding the environment. But here are some mitigation steps you can take for the future.

1. Utilize the WEBSITES_PORT application setting and inject that value as an environment variable into your application.
2. Enable Always On on the app service. This will ensure your application never has to warm up and rebind the port to forwarding requests.
3. Node on Windows will utilize iisnode for hosting your app in Windows. I would advise switching to a Linux environment; not saying that iisnode is the issue but it's one less thing to worry about when hosting your app

Since you stated everything was working fine, it could be a transient issue. However, one thing to compare the app service environment version between the ones that are failing and the ones that are successfully running. If there's a correlation, comment down below and I'll take a closer look.