Hey everyone! I’m having trouble with my n8n setup using Docker Compose. Everything seems to work fine - I can make new workflows, run them, and even delete them. But for some reason, I can’t change the names of my workflows. It’s driving me crazy!
I’ve set up n8n with Postgres using Docker Compose. I’ve checked the environment variables, but I can’t find anything about naming permissions. Am I missing something obvious?
Here’s a simplified version of my docker-compose file:
services:
automation:
image: automationhub/latest
environment:
- ENCRYPTION_KEY=mysecretkey
- DB_TYPE=postgres
- DB_HOST=mydb
volumes:
- automation_data:/data
depends_on:
- mydb
mydb:
image: postgres:latest
environment:
- POSTGRES_DB=automationdb
- POSTGRES_USER=dbuser
volumes:
- db_data:/var/lib/postgresql/data
volumes:
automation_data:
db_data:
Any ideas on what might be causing this? Thanks in advance for your help!
I encountered a similar issue with workflow renaming in my n8n Docker setup. The problem was related to file permissions in the mounted volume. Try checking the permissions of the ‘/data’ directory inside your container. You might need to adjust the ownership or permissions to allow n8n to write to the workflow files.
To troubleshoot, you can exec into the container and inspect the permissions:
docker exec -it <container_name> /bin/sh
ls -l /data
If the permissions look off, you may need to update your Docker Compose file to set the correct user or adjust permissions at runtime. Adding a command to chown the /data directory could help:
command: >
/bin/sh -c "
chown -R node:node /data &&
n8n start"
This ensures n8n has the necessary permissions to modify workflow files. Hope this helps resolve your naming issue!
I’ve dealt with this exact problem in my n8n setup, and I discovered that the workflow names were updating in the database while the user interface continued to show the old names because of aggressive caching. In my case, clearing the browser cache completely resolved the issue temporarily. I then restarted the n8n container using ‘docker-compose down’ followed by ‘docker-compose up -d’ to ensure all components reloaded properly. When that did not suffice, I added the environment variable GENERIC_TIMEZONE with my actual timezone (for example, ‘America/New_York’) to force a more frequent cache reevaluation. If the issue persists, checking the database records directly for name updates might reveal a deeper configuration problem.