Two file errors show up across every language, and they're the most fixable errors there are — because the message hands you the exact path it choked on. ENOENT means the file isn't there; EACCES means it's there but you're not allowed to touch it. Read the path, and the fix is usually one action in the File Manager.
| At a glance | |
|---|---|
| ENOENT | No such file or directory — wrong name, wrong folder, or it doesn't exist |
| EACCES | Permission denied — the file exists but can't be read/written/run |
| First move | Read the path in the error — that's exactly where your code looked |
The verbatim errors
ENOENT — the file wasn't found:
# Node
Error: ENOENT: no such file or directory, open '/home/container/config.json'
# Python
FileNotFoundError: [Errno 2] No such file or directory: 'config.json'EACCES — the file exists, but access was denied:
# Node
Error: EACCES: permission denied, open '/home/container/locked.txt'
# Python
PermissionError: [Errno 13] Permission denied: 'locked.txt'Read the path — it's not a guess
The single most useful part of these errors is the path. That's the exact location your program looked at, and decoding it solves most cases on its own.
Your files live in /home/container (the root folder in the File Manager), and that's your program's working directory. So a relative path resolves from there:
open("config.json")→/home/container/config.jsonreadFileSync("data/db.sqlite")→/home/container/data/db.sqlite
If the path in the error isn't where you thought your file was, that mismatch is the bug.
ENOENT — what's actually wrong
| Cause | Fix |
|---|---|
| The file genuinely isn't there | Upload or create it in the File Manager at the path shown |
Wrong name or case — Config.json ≠ config.json |
Linux is case-sensitive; rename so it matches your code exactly |
| It's in a subfolder | Either move it to the root, or point your code at subfolder/file |
| A folder in the path doesn't exist | Writing to data/db.sqlite fails if data/ isn't there — Create folder first |
| Your entry file is missing | If the whole app won't start on ENOENT, it's a different problem — see When your server won't start |
💡 Tip: Case sensitivity catches people migrating from Windows or macOS, where
README.TXTandreadme.txtare the same file. On the Falix container they are two different files.
EACCES — what's actually wrong
EACCES is about permissions, not existence. The file is there; the runtime just isn't allowed to do what it asked.
-
A file you can't read or write. Its permission bits don't grant access. Select it in the File Manager, use the Permissions (chmod) action, and give it read/write.
-
A binary that lost its execute bit. This is the common one for the Go, Deno, and Lua applications, whose startup runs
./app,./deno, or./luvit. If that file was uploaded without the execute bit, the start fails:/bin/bash: line 1: ./app: Permission deniedand from inside Node, spawning it looks like
Error: spawnSync /home/container/app EACCES. Fix: select the file → Permissions (chmod) → tick execute, then restart. -
A directory you can't enter. Same fix on the folder — it needs the execute bit to be traversable.
🎯 Good to know: Uploading over SFTP usually preserves the execute bit from your machine; a drag-and-drop upload of a fresh binary may not. Either way, the File Manager's Permissions action sets it in seconds.
Prevention
- Keep data files where your code expects them — at the root, or a folder you actually create. Don't assume a subfolder exists; create it (or have your code create it) before writing.
- Match names exactly, case included, between your code and the files on the server.
- Fix the execute bit once, right after uploading a binary, so the Go/Deno/Lua app can launch it.