Debug the runtime

Diagnose file and permission errors

Resolve the effective process user, path, ownership, mode, parent directories, and mount state before changing permissions.

10 minute lesson

~~~

EACCES, EPERM, ENOENT — file errors look alike from inside the application, but the causes live in different places. Before touching any permission, establish four facts: who the process runs as, which path it actually opened, what the permissions along that path are, and which filesystem the path lands on.

The rule most people miss: a process needs permission on the file and traversal permission on every parent directory. A world-readable file inside a 700 directory owned by someone else is unreachable, and the error message blames the file.

Inspect one failing path

Inspect one failing path:

id
namei -l /srv/app/data/report.json
stat /srv/app/data/report.json
findmnt /srv/app/data

id shows the effective user and groups — check it for the service account, not for yourself. namei -l is the underused gem: it walks the path one component at a time and prints the owner and mode of each:

f: /srv/app/data/report.json
drwxr-xr-x root root /
drwxr-xr-x root root srv
drwxr-x--- root deploy app        <- www-data is not in "deploy"
drwxr-xr-x app  app  data
-rw-r--r-- app  app  report.json

The file itself is readable, but the app directory blocks anyone outside the deploy group. That is the whole diagnosis, in one command.

findmnt catches the other class: the path sits on a read-only mount, a container volume that never got mounted, or a network filesystem that remaps ownership. stat confirms the exact mode and owner, and whether the “file” is actually a symlink pointing somewhere else.

Reproduce as the real user

Run the failing operation as the actual service account:

sudo -u www-data cat /srv/app/data/report.json

If that reproduces the application error, you have a minimal case. Fix it narrowly: change only the ownership or mode needed by that operation — add the service user to the right group, or grant group read on one directory.

Do not use recursive chmod 777. It makes the error vanish by destroying the ownership model, it exposes data to every account on the machine, and it guarantees the real misconfiguration is still there, now invisible.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →