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

The Node.js process tried to read, write or execute a path the operating system does not let it touch. The two everyday causes are: the file or directory is owned by another user (often root) and the current process runs as a different user; or the file’s permission bits exclude the current user (mode 600 owned by root, for example).

Fix

1. Identify the path that fails. The error message gives it (here /etc/myapp/config.json).
2. Check the actual permissions and owner with ls -la /etc/myapp/config.json. The first column shows the bits, the third the owner.
3. Fix the bits if your user should have access. Add read for the owner with chmod u+r /etc/myapp/config.json, or open it to everyone with chmod 644.
4. Fix the ownership if the file belongs to the wrong user: sudo chown $USER:$USER /etc/myapp/config.json.
5. Avoid running with sudo as a habit. Most EACCES errors come from a Node app that needs to write to a folder created by a different user. Move the writable folder to the user’s home, do not chmod 777 a system path.
6. npm install global error: if EACCES hits /usr/lib/node_modules, configure npm to use a folder under ~/.npm-global instead of running sudo npm install -g. Add ~/.npm-global/bin to your PATH.

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 Node.js was asked to open does not resolve to an actual file. The classic root causes are a relative path that depends on the current working directory (which can differ between development and a systemd service), a typo in the filename, a missing file in the deployment bundle, or a symlink that points nowhere.

Fix

1. Print the resolved path before the failing call: console.log(require('path').resolve('./config/local.json')). Compare with where the file actually lives.
2. Use absolute paths with path.join(__dirname, 'config', 'local.json'). __dirname is the directory of the source file, immune to the runtime cwd.
3. Verify deployment if the error only happens on the server: ls -la the working directory of the systemd service and confirm the file is present. The build pipeline may have excluded it.
4. Handle missing files gracefully when expected: wrap with a try/catch and fall back to a default, or check with fs.existsSync() before reading.
5. Watch for trailing whitespace in dynamic paths: a filename read from a CSV often has a stray space or newline; trim before passing to the fs call.

What you see

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

Why it happens

The port your server tried to bind to is held by another process. The most common cases are a previous run of the same Node app that did not shut down cleanly, a different service on the same port (Docker, another framework’s dev server), or a zombie process kept alive by nodemon during hot reload.

Fix

1. Find what holds the port. On Linux/macOS: lsof -iTCP:3000 -sTCP:LISTEN -n -P. On Windows: netstat -ano | findstr :3000 then look up the PID.
2. Kill the rogue process: kill -9 <PID> (Linux/macOS) or taskkill /F /PID <PID> (Windows).
3. Use a different port as a quick mitigation: PORT=3001 node server.js, especially in dev when port 3000 is contested.
4. Free the port with SO_REUSEADDR at server startup: some frameworks expose a reusePort or exclusive option to handle leftover sockets after a crash.
5. Wait for TIME_WAIT after a crash on a TCP server: the kernel can hold the socket in TIME_WAIT for up to two minutes. Bind to 0.0.0.0:0 for a free random port if you can pick at startup, otherwise wait.

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

The browser refused to expose the cross-origin response to the page because the server did not return an Access-Control-Allow-Origin header matching the page origin. CORS is enforced by the browser, not by the server: the request often reached the API and produced a response, but the browser dropped that response on the floor before it reached your JavaScript.

Fix

1. Confirm the server side by curling the API: curl -i -H "Origin: https://app.example.com" https://api.example.com/users. Check for an Access-Control-Allow-Origin header in the response.
2. Fix the server if you control it. Add the response header for the right origin (avoid * when credentials are used). Express: app.use(cors({ origin: 'https://app.example.com', credentials: true })). Nginx: add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always;.
3. Handle pre-flight for non-simple requests: the browser sends an OPTIONS first, which must return Access-Control-Allow-Methods and Access-Control-Allow-Headers. A 404 on OPTIONS produces the same CORS error.
4. Use a reverse proxy if you cannot change the API: serve /api/* from the same origin as the app, and let nginx proxy_pass to the real API host. The browser then sees a same-origin request.
5. Do NOT disable web security in the browser or set Access-Control-Allow-Origin: * when credentials are involved. Both are reliable ways to ship a security bug.

What you see

Either a plain HTML page from Nginx saying “502 Bad Gateway”, a Cloudflare branded page with error 502, or a fetch in the browser console returning HTTP 502.

Why it happens

A reverse proxy in front of your app (Nginx, Apache, Cloudflare, an ELB) received an invalid response from the upstream, or the upstream did not respond at all. The three usual causes are: the upstream process crashed and the socket is closed; the upstream is up but too slow and the proxy timed out waiting; or there is a protocol mismatch (the proxy speaks HTTP/1.1 to a process that only speaks HTTP/2 cleartext).

Fix

1. Check the upstream is alive: curl -i http://127.0.0.1:8080/health from the same machine as the proxy. If this fails, the bug is in the upstream.
2. Read the proxy error log: Nginx writes to /var/log/nginx/error.log. The line says exactly what failed (connection refused, timeout, upstream closed prematurely).
3. Raise the proxy timeout if the upstream is slow but works: proxy_read_timeout 60s; in Nginx, or the equivalent in Apache.
4. Match the protocols. If the upstream is HTTP/2, ensure the proxy speaks HTTP/2 to it or that the upstream also serves HTTP/1.1. Cloudflare’s “Always Use HTTPS” plus an HTTP origin produces a 502 loop.
5. Watch the upstream restart loop. If your systemd unit crashes, systemctl status shows the restart count. A constantly restarting service produces intermittent 502s; 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

The Python interpreter could not find the module on its import path. The classic causes are: the package is not installed in the active environment (you installed it globally but you run in a venv, or the reverse); two Python versions on the same machine pull from different site-packages; a typo in the module name; or a circular import where the module references itself before it is fully loaded.

Fix

1. Confirm which Python you run: python --version and which python (or where python on Windows). The output should match the interpreter inside your venv.
2. Activate the venv before installing or running: source venv/bin/activate (Linux/macOS) or venv\Scripts\activate (Windows).
3. Install into the right environment: python -m pip install requests. The python -m pip form guarantees pip targets the same interpreter you are about to run.
4. Verify the install: python -c "import requests; print(requests.__file__)". The printed path tells you which site-packages the module came from.
5. Check the spelling: PyPI package pillow imports as PIL; beautifulsoup4 imports as bs4; opencv-python imports as cv2. The install name and the import name are not always the same.

What you see

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

Why it happens

JSON.parse was called on a string that is not JSON. The string almost always starts with < or <!DOCTYPE html>, which means the server returned HTML where the client expected JSON. The most common cause is a 4xx or 5xx error where the API returns its branded error page in HTML, while the client code calls .json() on the response without checking the status code first.

Fix

1. Inspect the response before parsing. In the browser Network tab, find the failing request and look at the response body. If it is HTML, the server returned an error.
2. Check the status code before calling .json(): if (!response.ok) throw new Error(`HTTP ${response.status}`).
3. Read the Content-Type header: only call .json() if it starts with application/json. Otherwise use response.text() and surface a meaningful error.
4. Fix the URL: a 404 on a wrong path often returns the SPA’s index.html instead of an API JSON. Confirm the URL in the Network tab matches what the API actually exposes.
5. Beware of authentication redirects: an expired session can return a login HTML page for a fetch that should be JSON. Detect a 401 or a redirect chain and handle it before parsing.

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

npm 7+ enforces peer dependencies. The resolver sees a package that demands React 17 while your project ships React 18, and refuses to install. The legitimate causes are an outdated dependency in the tree, a typo in your package.json version constraint, or two transitive dependencies that disagree on a peer.

Fix

1. Identify the offender: the error names the package (some-legacy-lib@2.3.4) and the conflict. Search for an updated version on the npm registry that supports your React version.
2. Upgrade the dependency: npm install some-legacy-lib@latest. Most maintenance updates target the current major React.
3. Replace with an alternative if the package is abandoned: a maintained fork or a different library that does the same job.
4. Force resolution as a last resort: npm install --legacy-peer-deps skips the check. Use only when you know the peer warning is wrong (rare). Document why in the project README.
5. Audit the lockfile: an old package-lock.json can lock in a transitive that is no longer compatible. rm package-lock.json node_modules && npm install rebuilds clean.