n8n · troubleshooting · reproduced on n8n 2.41.3, 30 September 2026

n8n EACCES: permission denied

EACCES: permission denied, open '/home/node/.n8n/config' means the n8n process cannot write its own data folder. The official image runs n8n as the non-root user node. When the folder mounted at /home/node/.n8n belongs to someone else, typically root after a mkdir or sudo on the host, n8n cannot create its config file or its database. Fix: change the owner of that folder to the container’s user, or use a named volume, which Docker sets up with the right owner.

The three messages this covers

Message	When	What to do
`Error: EACCES: permission denied, open '/home/node/.n8n/config'`	First start on a new folder, or any start where the config file cannot be read	Give the container user ownership of the folder mounted at /home/node/.n8n
`QueryFailedError: SQLITE_READONLY: attempt to write a readonly database`	Start gets as far as “n8n ready on ::, port 5678”, then exits	Same folder, same fix. database.sqlite (and its -wal / -shm files) must be writable
`Permissions 0644 for n8n settings file …/.n8n/config are too wide. Changing permissions to 0600..`	Start, when the config file is readable by others	Nothing: 2.41.3 fixes the mode itself and carries on. It is not an error

We produced all three on n8n 2.41.3, installed from npm on Node 24, by removing write permission from a test .n8n folder, its config file and its database in turn, on 30 September 2026. The messages above use the Docker path; ours showed the local path instead. We did not reproduce them inside the Docker image. The Docker details below come from n8n’s Dockerfile.

What the log looks like

A new, empty folder that the process cannot write. n8n first announces it will create a key, then fails to save it:

No encryption key found - Auto-generating and saving to: /home/node/.n8n/config
Error: Failed to load command "start"
Error: EACCES: permission denied, open '/home/node/.n8n/config'

A folder whose config is fine but whose database is read-only gets further before it stops:

n8n ready on ::, port 5678
…
QueryFailedError: SQLITE_READONLY: attempt to write a readonly database
Exiting due to an error.

Both mean the same thing: the user n8n runs as does not own the files. Check before you change anything:

# which uid:gid does the container run as?
docker run --rm --entrypoint id n8nio/n8n

# who owns the host folder you mount? (bind mounts only)
ls -ln ./n8n_data

The fixes

Bind mount: give the folder to the container’s user

If you mount a host directory (-v ./n8n_data:/home/node/.n8n or a path under volumes: in Compose), the container sees the host’s ownership unchanged. Change it to the uid and gid that id printed. For the node user in the official Node.js images that is 1000, per their best-practices guide. Then start again:

sudo chown -R 1000:1000 ./n8n_data   # use the uid:gid from `id` above
docker compose up -d

Change the owner, not the mode. chmod 777 makes the folder writable, but n8n keeps its encryption key in that folder’s config file. On 2.41.3 it also tightens a world-readable config back to 0600 itself, logging “Permissions 0644 … are too wide. Changing permissions to 0600..”.

Or use a named volume, as n8n’s docs do

n8n’s documented docker run creates a named volume and mounts that instead of a host path:

docker volume create n8n_data
docker run -it --rm --name n8n -p 5678:5678 \
  -v n8n_data:/home/node/.n8n n8nio/n8n

Docker populates a new, empty volume from the image directory it is mounted over. Its docs say “Docker copies the directory's contents into the volume”. Here that directory is the /home/node/.n8n that n8n’s Dockerfile creates and hands to node (mkdir -p /home/node/.n8n; chown -R node:node /home/node). If you are moving from a bind mount, copy the old folder’s contents in, and fix ownership as above. That folder holds your encryption key, and losing it means credentials that can no longer be decrypted.

Not in Docker

The same messages on an npm or systemd install mean the service user cannot write ~/.n8n (or N8N_USER_FOLDER). This happens after running n8n once with sudo, which leaves root-owned files behind. chown -R the folder back to the user the service runs as.

If n8n starts but reports “Mismatching encryption keys” or “Credentials could not be decrypted” after you moved the folder, see n8n encryption key errors. The self-hosted n8n guide walks through the volume, the Compose file and the environment variables around it.

Sources and last verified

Reproduced on n8n 2.41.3 on 30 September 2026; the Dockerfile and docs were read on the same day. If n8n’s docs and this page disagree, n8n wins. Write to support@flowtemplates.app and we will re-verify.

n8n source — docker/images/n8n/Dockerfile (USER node; /home/node/.n8n created and chowned to node) — checked 2026-09-30
n8n Docs — Docker installation (the n8n_data volume at /home/node/.n8n, N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS) — checked 2026-09-30
Docker Node.js images — Best practices, “Non-root User” (the node user and its uid) — checked 2026-09-30
Docker Docs — Volumes, “Populate a volume using a container” — checked 2026-09-30

Frequently asked questions

Why does n8n say “EACCES: permission denied, open '/home/node/.n8n/config'”?

Because the process cannot read or create its settings file. The official image runs n8n as a non-root user, node, per the USER node line in n8n’s Dockerfile. If the directory you mount at /home/node/.n8n belongs to root or another user, n8n cannot write its config there. On a new folder the log first says “No encryption key found - Auto-generating and saving to: …/.n8n/config”, and the save is what fails.

What user ID does the n8n container run as?

The user is node, per the Dockerfile. The official Node.js images give that user uid 1000, per their best-practices guide. n8n’s current base image is built on Docker’s hardened Node image, though, so check yours instead of assuming: docker run --rm --entrypoint id n8nio/n8n prints the uid and gid the container actually runs as. Use those numbers in the chown.

Should I just run the container as root to make it go away?

No. It works, but it throws away the reason the image drops root in the first place, and it creates files in your volume owned by root. The next time you run the image normally, as node, you hit the same EACCES on those files. Fix the ownership once instead.

Why does a named Docker volume not have this problem?

Docker’s docs say that when a container creates a new volume over a directory that already has content in the image, “Docker copies the directory's contents into the volume.” n8n’s Dockerfile creates /home/node/.n8n and hands /home/node to node, so a fresh named volume starts from a directory the image prepared for that user. A bind mount of a host folder is used as it is on the host, with the host’s ownership. n8n’s own docker run example uses docker volume create n8n_data rather than a host path. If a named volume still gives EACCES, it was probably created or written by another container or user first; check it with ls -ln from a throwaway container.

Does “Permissions 0644 … are too wide” need fixing?

Not on 2.41.3. When we made the config file world-readable, n8n logged “Permissions 0644 for n8n settings file … are too wide. Changing permissions to 0600..”, changed the mode itself and started normally. If it cannot change the mode, the source logs “Could not ensure settings file permissions”, and N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false turns the check off.