Developer Error Fix Hub: EACCES, ENOENT, CORS, 502 and More 2026

What you see

Error: EACCES: permission denied, open '/etc/myapp/config.json'
    at Object.openSync (node:fs:603:3)
    at Object.readFileSync (node:fs:471:35)

Why it happens

Your Node process reached for a path the OS won’t let it touch. Almost always it’s one of two things. Either the file belongs to somebody else (root, usually) while your process runs as a different user. Or the permission bits just lock you out, picture mode 600 owned by root. That’s the whole story most days.

Fix

1. Grab the path that’s failing. The error hands it to you (/etc/myapp/config.json in this case).
2. See who owns it and what the bits are with ls -la /etc/myapp/config.json. First column is the bits. Third is the owner. That’s all you’re reading here.
3. Fix the bits if you’re meant to have access anyway. Give the owner read with chmod u+r /etc/myapp/config.json, or just open it up with chmod 644.
4. Fix the ownership when the file landed under the wrong account: sudo chown $USER:$USER /etc/myapp/config.json.
5. Stop reaching for sudo on reflex. Most of the time this is nothing but a Node app trying to write into a folder some other user created. Put the writable folder somewhere in the user’s home, leave it there. And please, don’t chmod 777 a system path just to make the pain stop. I’ve watched that decision come back to bite people.
6. If it’s an npm global install: EACCES on /usr/lib/node_modules means point npm at a folder under ~/.npm-global rather than running sudo npm install -g. Drop ~/.npm-global/bin on your PATH and you’re set. No root, ever again.

What you see

Error: ENOENT: no such file or directory, open './config/local.json'
    at Object.openSync (node:fs:603:3)

Why it happens

The path you handed Node doesn’t point at a real file. What gets me most often? A relative path that quietly leans on the current working directory, which is never the same under a systemd service as it was on my laptop. After that it’s the boring stuff. A typo in the filename, a file that never made it into the deploy bundle. Or a symlink dangling off into nowhere.

Fix

1. Print the path Node actually resolved right before the call that blows up: console.log(require('path').resolve('./config/local.json')). Then go check where the file really sits. Nine times out of ten they don’t match, and there’s your bug.
2. Go absolute with path.join(__dirname, 'config', 'local.json'). __dirname is the folder of the source file itself, so it couldn’t care less what the runtime cwd happens to be. This is the fix I lean on, probably too much.
3. If it only breaks on the server run ls -la in the systemd service’s working directory and see if the file is even there. More often than you’d think, the build pipeline just left it behind.
4. When the file is genuinely allowed to be missing wrap the read in try/catch and fall back to a default, or check fs.existsSync() first instead of letting it throw.
5. Watch for stray whitespace in paths you build at runtime. A filename pulled from a CSV loves to drag along a trailing space or a newline. Trim it before it ever reaches the fs call. Skip that and you’ll lose an hour glaring at two strings that look identical.

What you see

Error: listen EADDRINUSE: address already in use :::3000
    at Server.setupListenHandle [as _listen2] (node:net:1740:16)

Why it happens

Something else is already parked on the port you wanted. Usually it’s a previous run of your own app that didn’t die cleanly. Sometimes it’s a totally different service squatting there (a Docker container, or some other framework’s dev server you forgot was running). Or a zombie nodemon left breathing after a hot reload. Whatever it is, the port’s taken, and the kernel won’t hand the same one out twice.

Fix

1. Find out who’s holding it. On Linux/macOS I run lsof -iTCP:3000 -sTCP:LISTEN -n -P. On Windows it’s netstat -ano | findstr :3000, and then you chase down the PID it prints.
2. Kill the squatter: kill -9 <PID> on Linux/macOS, or taskkill /F /PID <PID> on Windows.
3. Or just move. When 3000 is forever contested, this is the quickest unblock in dev: PORT=3001 node server.js. Get on with your day.
4. Reuse the socket on startup if leftover sockets after a crash are your real problem. Plenty of frameworks expose a reusePort or exclusive option (SO_REUSEADDR under the hood) for precisely this.
5. Sometimes you just wait. After a crash the kernel can park a TCP socket in TIME_WAIT for up to two minutes. Nothing’s broken. It just hasn’t let go yet. If you can pick the port at startup, bind to 0.0.0.0:0 and take whatever free one it gives you. Otherwise, go grab a coffee.

What you see

Access to fetch at 'https://api.example.com/users'
from origin 'https://app.example.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

Why it happens

Here’s the part that trips everyone up. Your request probably worked fine. The browser just refused to hand the cross-origin response back to your page, because the server never sent an Access-Control-Allow-Origin header matching where the page came from. CORS lives in the browser, not the server. So the API got your call, built a perfectly good response, and the browser dropped it on the floor before a single line of your JavaScript ever laid eyes on it.

Fix

1. Prove it from the server side first by curling the API yourself: curl -i -H "Origin: https://app.example.com" https://api.example.com/users. No Access-Control-Allow-Origin header in the response? There’s your answer.
2. Fix it at the server when it’s yours. Send the header back for the right origin, and drop * the moment credentials are in play. Express: app.use(cors({ origin: 'https://app.example.com', credentials: true })). Nginx: add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always;.
3. Don’t forget the preflight on anything that isn’t a simple request. The browser fires an OPTIONS first, and it has to come back carrying Access-Control-Allow-Methods and Access-Control-Allow-Headers. A 404 on that OPTIONS call surfaces as the exact same CORS error, which is maddening right up until the second you spot it.
4. Can’t touch the API? Proxy around it. Serve /api/* from the same origin as your app and let nginx proxy_pass through to the real host. Now the browser thinks the whole thing is same-origin, and CORS never enters the conversation. It’s how I handle third-party APIs I don’t own.
5. Whatever you do, don’t launch the browser with web security switched off, and don’t slap Access-Control-Allow-Origin: * on a response that’s carrying credentials. Both of those “work,” and both are how you quietly ship a security hole to production.

What you see

Could be a bare Nginx page reading “502 Bad Gateway”. Could be one of Cloudflare’s branded 502 screens. Could be a plain HTTP 502 landing on a fetch in your console. Same problem, different clothes.

Why it happens

A 502 means the proxy parked in front of your app (Nginx, Apache, Cloudflare, an ELB, take your pick) either got garbage back from the upstream or got nothing at all. The list of usual suspects is short. Your app crashed and the socket’s closed. Or your app’s alive but slow, and the proxy gave up waiting. Or the two are talking straight past each other, the proxy speaking HTTP/1.1 at a process that only answers in HTTP/2 cleartext. The proxy itself is rarely the villain here. It’s just the one carrying the bad news.

Fix

1. First, is the upstream even up? From the proxy box itself, curl -i http://127.0.0.1:8080/health. If that fails right there, stop staring at Nginx. The bug’s in your app.
2. Read the proxy’s error log. Nginx drops it in /var/log/nginx/error.log, and the line tells you flat-out what went wrong: connection refused, a timeout, upstream closed prematurely. Second place I always look.
3. Bump the timeout when the upstream works but takes its sweet time: proxy_read_timeout 60s; in Nginx, or the Apache equivalent.
4. Get the protocols on the same page. If the upstream is HTTP/2, either make the proxy talk HTTP/2 to it, or keep the upstream serving HTTP/1.1 too. Classic trap here: Cloudflare’s “Always Use HTTPS” pointed at a plain-HTTP origin spins up a neat little 502 loop.
5. Hunt the restart loop. When a systemd unit keeps falling over, systemctl status shows the restart count climbing. A service that dies every few seconds throws 502s that flicker in and out and slowly drive you up the wall. Fix the crash. Not the proxy.

What you see

Traceback (most recent call last):
  File "main.py", line 1, in <module>
    import requests
ModuleNotFoundError: No module named 'requests'

Why it happens

Python walked its import path and the module simply wasn’t on it. The one that bites me constantly? I install the package in one place and run Python from another. Pip drops it in the global site-packages while my code runs inside a venv, or the reverse. Then there’s two Python versions on the same box reading from different site-packages, or the occasional typo in the module name. And the circular import where a module reaches for itself before it’s done loading. That covers nearly every case I’ve ever hit.

Fix

1. Pin down which Python you’re actually running: python --version plus which python (where python on Windows). It has to be the interpreter inside your venv. If it isn’t, well, you’ve already found the problem.
2. Activate the venv before you install or run anything: source venv/bin/activate on Linux/macOS, venv\Scripts\activate on Windows.
3. Install into that exact interpreter with python -m pip install requests. I always reach for the python -m pip form. It guarantees pip lands the package in the same Python you’re about to run, and there’s no guessing involved.
4. Make sure it took: python -c "import requests; print(requests.__file__)". The path it prints tells you exactly which site-packages the module came from.
5. Double-check the name, because install name and import name don’t always line up. pillow imports as PIL. beautifulsoup4 as bs4. opencv-python as cv2. That mismatch has cost me more hours than I’d care to admit out loud.

What you see

Uncaught (in promise) SyntaxError: Unexpected token '<', "<!DOCTYPE "...
is not valid JSON

Why it happens

You called JSON.parse on something that isn’t JSON. That leading < (usually a full <!DOCTYPE html>) gives it away: the server sent back HTML while your code sat there expecting JSON. What’s really going on, almost every single time, is a 4xx or 5xx underneath. The API hit an error, handed back its branded HTML error page, and your code cheerfully called .json() on it without so much as glancing at the status code. The parser throws. But the parser isn’t your bug.

Fix

1. Actually look at what came back before you parse it. Open the Network tab, find the failing request, read the response body. If it’s HTML? Congratulations, the server returned an error and you just found it in ten seconds.
2. Gate on the status code before .json() ever runs: if (!response.ok) throw new Error(`HTTP ${response.status}`). This one line would have headed off most of the cases I’ve seen.
3. Trust the Content-Type. Only reach for .json() when it starts with application/json. Otherwise grab response.text() and throw something a human can actually read.
4. Recheck the URL. A 404 on a wrong path will often serve your SPA’s index.html instead of the API JSON, which is exactly why the body reads like a webpage. Confirm in the Network tab that the URL matches what the API really exposes.
5. Suspect an auth redirect. An expired session loves to answer a JSON fetch with a login page in HTML. Catch the 401, or the redirect chain, and handle it before you hand anything off to the parser.

What you see

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR! While resolving: my-app@1.0.0
npm ERR! Found: react@18.2.0
npm ERR! Could not resolve dependency:
npm ERR! peer react@"^17.0.0" from some-legacy-lib@2.3.4

Why it happens

Since npm 7 the resolver actually enforces peer dependencies instead of shrugging them off. It spots a package insisting on React 17 while you’re shipping React 18, decides the two can’t share a roof, and bails rather than install a tree it reckons is broken. The real reason underneath is usually pretty mundane. A dependency that’s gone stale. A typo in some version range in your package.json. Or two transitive deps that flat-out disagree about which peer they want.

Fix

1. Name the troublemaker. The error literally tells you which package (some-legacy-lib@2.3.4) and what it’s fighting over. Go check whether the registry has a newer version that’s made its peace with your React.
2. Bump it: npm install some-legacy-lib@latest. Most maintenance releases have already caught up to the current major of React, so this often just ends the whole thing right there.
3. If the package is dead, walk away from it. A maintained fork, or a different library doing the same job, beats wrestling something nobody’s touched in two years.
4. Force it only when you’ve earned the right: npm install --legacy-peer-deps skips the check entirely. I reach for this rarely. Only when I’m dead certain the peer warning is just wrong, and even then I leave a note in the README saying why, so future-me doesn’t sit there panicking.
5. Don’t trust an old lockfile. A stale package-lock.json can pin a transitive that stopped being compatible ages back. rm package-lock.json node_modules && npm install rebuilds the whole thing clean, and honestly that alone clears it more often than it has any right to.