Fix the “Error: EACCES: permission denied, mkdir ‘/home/node/.n8n’” when running n8n in Docker inside an LXC on Proxmox VE

docker compose down

volumes:
  - ./n8n_data:/home/node/.n8n

sudo chown -R 1000:1000 ./n8n_data

ls -ld ./n8n_data

drwxr-xr-x 2 1000 1000 4096 Sep 26 10:12 ./n8n_data

docker compose up -d

docker logs -f n8n

n8n ready on http://0.0.0.0:5678

Verification

1. Confirm that the container is running.

   Explanation: docker ps lists all containers that are currently in the Up state. The n8n service should appear with a status like Up X minutes.

   docker ps
   

2. Access the n8n web interface from a browser.

   Explanation: By default n8n listens on port 5678 inside the container, and the compose file typically maps that to the same port on the host. Open http://<proxmox-host-ip>:5678 (replace <proxmox-host-ip> with the IP address of your Proxmox node or the LXC’s IP if you forwarded the port). You should see the n8n setup or login screen.

3. Ensure no permission errors appear in the logs.

   Explanation: Run docker logs n8n (without -f to get a static output) and scan for the string EACCES or permission denied. There should be none.

   docker logs n8n
   

4. Test data persistence.

   Explanation: Create a simple workflow, stop the stack with docker compose down, then start it again with docker compose up -d. After the container is healthy, open the workflow you created; it should still be present.

Troubleshooting the Most Common Failures

• Container still exits immediately after up
  If you still see the EACCES error, double‑check that you changed ownership of the exact directory referenced in the compose file. A common mistake is to chown a parent folder or a differently named folder. Run ls -l in the directory containing the compose file to confirm the folder name and its ownership.

• Permission denied on sub‑folders inside the data directory
  If the top‑level directory is owned correctly but you still get errors about sub‑folders (for example, .n8n/database), run the chown command again with the -R flag to ensure recursion applied to all nested items.

• UID/GID mismatch because the image changed
  The official n8n image uses the node user (UID 1000, GID 1000) as of the time of writing, but you should verify this for the specific tag you are using. Consult the image’s Docker Hub page or the official n8n documentation for the exact user IDs. If they differ, substitute the correct numbers in the chown command.

• Docker inside LXC shows shifted IDs
  In an unprivileged LXC the host’s UID 0 is mapped to a high range inside the container, but permission checks on bind‑mounts still use the host’s ownership. The fix described above works regardless of the mapping because we align the host‑side ownership with the container’s expected UID/GID. No additional LXC configuration is required.

• Accidentally removed data while troubleshooting
  If you deleted the host directory thinking it would be recreated, you will lose any persisted workflows or credentials. Always back up the ./n8n_data folder (or whatever you named it) before experimenting with rm -rf or similar destructive commands.

Conclusion

By ensuring that the host‑side directory used for n8n’s persistent data is owned by UID 1000 and GID 1000, you eliminate the Error: EACCES: permission denied, mkdir '/home/node/.n8n' that occurs when the image runs as the non‑root node user inside Docker. The procedure takes only a few minutes, requires no changes to the compose file, and preserves all existing data. Once the container is up, you can access the n8n UI at port 5678 and begin building automations.

For future deployments, make it a habit to set the correct ownership immediately after creating any bind‑mount folder that a non‑root image will write to. If you prefer to avoid manual steps, you can run the container as root (user: "0:0") but this reduces the security isolation that the node user provides. Refer to the official n8n Docker documentation for the most up‑to‑date user IDs and any changes to the image’s default user.

Frequently Asked Questions

Why does the error only appear when Docker runs inside an LXC on Proxmox?

The n8n image expects to write to /home/node/.n8n as the node user (UID 1000). In an unprivileged LXC the host’s UID 0 is mapped to a different range inside the container, but permission checks on bind‑mounts still follow the host’s ownership. If the host folder is owned by root, the node user lacks write rights, causing the mkdir to fail.

Can I fix the problem by changing the compose file instead of the host folder?

Yes. You could add user: "0:0" to the n8n service to run the container as root, which would bypass the permission check. However, this runs the container with full privileges inside the LXC and is not recommended for production environments where isolation matters.

What if I want to use a named volume instead of a bind mount?

Named volumes are managed by Docker and are created with the correct ownership for the image’s user, so the permission error does not occur. To switch, replace the bind‑mount line in the compose file with something like - n8n_data:/home/node/.n8n and declare the volume under the volumes: top‑level key. Remember that named volumes are less transparent for direct host‑side backups.

How do I find the exact UID/GID that the n8n image uses for my specific tag?

Check the image’s Docker Hub page or the official n8n documentation for the node user details. You can also inspect the image directly with docker run --rm <image> id (replace <image> with the full image reference) to see the UID and GID reported inside the container.

Some links on this page may be affiliate links. If you buy through them we may earn a commission at no extra cost to you. See our affiliate disclosure.

ShareXLinkedInFacebookReddit