N8n continuous restart in docker w/1.05

Describe the problem/error/question

I’ve followed the KB several times for Digital Ocean. I’ve gone so far as to completely clear docker, and I’ve destroyed my droplet and started from scratch. When I run ‘docker compose’, it appears to go through the process and start the containers.

What I see when I then run ‘docker ps’ is:

docker ps -a

19c59d71300d caddy:latest “caddy run --config …” 3 minutes ago Up 3 minutes>80/tcp, :::80->80/tcp,>443/tcp, :::443->443/tcp, 443/udp, 2019/tcp n8n-docker-caddy-caddy-1
ddeffae2f568 n8nio/n8n “tini – /docker-ent…” 3 minutes ago Up 1 second>5678/tcp, :::5678->5678/tcp n8n-docker-caddy-n8n-1

What is the error message (if any)?

When I look at the docker logs, I see this repeating:

Error: Exiting due to an error.
Error: EACCES: permission denied, open ‘/home/node/.n8n/crash.journal’
Error: EACCES: permission denied, open ‘/home/node/.n8n/crash.journal’

Information on your n8n setup

  • n8n version: 1.05
  • Database (default: SQLite): SQLite
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker on Digital Ocean
  • Operating system: Ubuntu 22.04

I also use Docker and have the same symptoms since about 12 hours ago.

app_1 | Error: EACCES: permission denied, mkdir ‘/home/node/.n8n/logs’
app_1 | Code: EACCES

Removing the docker-compose bind setting makes it temporarily possible, but it is inconvenient because it cannot be seen on the log host.
It’s not a perfect solution, so I’d like to hear your opinion

If this is an issue that has occurred since the version was upgraded to 1.0, it seems necessary to refer to this.

I will test a little more on docker-compose and update you. Other people’s opinions are good, too.

Execute Docker Commands
docker run --rm -it --user root -v ~/.n8n:/home/node/.n8n --entrypoint chown n8nio/base:16 -R node:node /home/node/.n8n

Using Docker Compose Files
Adding uesr to a file as follows

        user: root

Of course, if you have any better opinions, please let me know. I just succeeded with user: root.

Just to make sure I understand it correctly. The command alone did not work for you? You still have to run n8n as “root”?

I checked in Breaking changes in the migration guide of version 1.0!
The link was referenced above.

Feel free to welcome any better comments!

Hey @Supka,

You shouldn’t need to run as root in 1.0 we made the change to the node user instead, The command should have changed the folder permissions so that the node user has access to them.

After you ran the command and before you added the user to the compose file what was your console output? Can you also share the other env options you have set?

Contents of my Docker Compose file that I used often
There is nothing special about “.env”, so please understand.
And please understand that some personal information will be deleted.


version: '3'
    image: docker.n8n.io/n8nio/n8n
    network_mode: bridge
    #user: root
      - "5678:5678"
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - DB_TYPE=postgresdb
      - N8N_ENCRYPTION_KEY=***
      - NODE_ENV=production
      - WEBHOOK_URL=https://${DOMAIN_NAME}/
      - N8N_LOG_LEVEL=debug
      - N8N_LOG_OUTPUT=console,file
      - ${DATA_FOLDER}/.n8n:/home/node/.n8n
      #- type: bind
      #  source: ${DATA_FOLDER}/.n8n
      #  target: /home/node/.n8n
    restart: always

Container restarts dozens of times as follows
docker ps -a

204ace9832d0 docker.n8n.io/n8nio/n8n "tini -- /docker-ent…" " 3 minutes ago Restarting (1) 54 seconds ago app_1

docker-compose logs -f

Attaching to app_1
app_1 | Error: EACCES: permission denied, mkdir '/home/node/.n8n/logs'
app_1 | Code: EACCES
app_1 | Error: EACCES: permission denied, mkdir '/home/node/.n8n/logs'
app_1 | Code: EACCES
app_1 | Error: EACCES: permission denied, mkdir '/home/node/.n8n/logs'
app_1 | Code: EACCES
app_1 | Error: EACCES: permission denied, mkdir '/home/node/.n8n/logs'
app_1 | Code: EACCES

Of course, I used the same yml file without any problems in the previous version.
The system consists of AWS’ Elastic Beanstalk, but it does not seem to have much to do with the current situation.
Also, my system was restarted about 19 hours ago, and I estimate that docker pull in the yml file worked as latest

Is your data_folder something like /root/.n8n

Oh! I’m sorry. /root/n8n here.
Most of the information was referred to here, and I think it was DB information that changed.

I wonder if that is the problem, Is the container being launched as the root user or a different user?

I’ll probably do it as root when I’m configuring the environment in beanstalk.
And what I wrote above is also the result of executing the “docker-compose up -d” command directly from the root authority.

I’ll look for something else just in case!

I used the same yml file and ran it with root privileges.
It is estimated that elasticbeanstalk will be the same.

I’m sorry. I hid some personal information

Does the logs folder already exist in your data path?

It is automatically created if it means a host, not a container.
Because I’m the root
I think /home/node/.n8n/logs is the path to the container, not the host.

For your information, /home/node/.n8n/logs did not appear inside the container when the container-based n8n was driven.

Since yesterday, my testing has revealed it is a permissions issue. If I include user=root in docker-compose.yml n8n starts and operates as before.

I’ve attempted to adjust permissions of the .n8n and local_files directories, but this had no apparent effect.

Is there a different place to put the compose and data config?

Hi, how should i put “user=root” in the docker-compose.yml? Thank you.

This is by no means official, it’s simply what I did to make it appear to work. I’m assuming I’ve done something wrong at this point. YMMV.

What I did was put ‘user=root’ right after the image line in the docker-compose.yml file.

1 Like

I now have it working without the root user in docker-compose.yml.

The issue is in the permissions of the .n8n and local_files subdirectories. I had to chown these two directories to my user. Then I verified a new workflow survived a docker restart.


1 Like