I am little confused. I got a super simple workflow in place. A webhook that posts to telegram. I am running 0.52.0 where it stopped working.
Starting the workflow with curl works just fine
{"message":"Workflow got started."}
But the telegram message never arrives.
To debug this I started the workflow from n8n and provide the HTTP request to the test webhook. Again the workflow starts - but I see an error message popup now:
"No encryption key got found to decrypt the credentials!"
I didn’t change anything but using an updated docker image.
Opening the credentials all looks OK.
Yes, I am running the image with docker compose with a directory mounted for the data.
Turns out the database is in read-only mode. The config file has the same permissions as the database. This also means n8n should be able to read the key but gives a wrong error message.
But the bottom line is - that is indeed a big change. And frankly speaking I am not sure if there is a good solution. The docker image does not share the users with the host. Only root is the same for both systems.
The only option I see would be to switch to a docker volume for the data - which I am really not such a big fan of.
Meh.
Were there database changes lately? I am thinking of rolling back to at least get a working system again.
The last one before the change I think was 0.51.0 . But very strange. I extra tested it before and it worked fine for me. Can you please test with that old version and then get back to me if that one works fine. If it does, I start to release also a docker-image with the old Dockerfile that people have something to used that uses root as before.
I was honestly not a big fan of that change as such issues were exactly what I did fear. It caused me already a lot of time and headaches. Rolling back would probably also not be a good idea. Better to stick with it now than having to do something like that later again. Very sorry for the issues!
I reverted back to 0.51.0 and I can confirm - all working again.
Of course running non-root is better. Finding an exploit for the app and getting out of the container seems like more theoretical scenario though. Maybe provide another image tagged as non-root. That seems to be the common way of doing this.
Another option would be to give clear instructions to get the volume mounted correctly. Maybe all it needs is the correct uid.
A none-root one does not really make any sense. After all, if I do that, all people will just keep on using the “wrong” insecure one. People by default select the version one (like 0.51.0) or latest. They will never start with 0.51.1-non-root. So if I have that one and 3 people end up using it, where is the point. The default image should be the secure one. And if people use it from the get-go, all will be fine.
Also just tested again, for me it works totally fine. I also did not hear from any other users that they had problems. Wonder why it does not work for you. Actually, should you also be able to fix it by simply changing the access right of the mounted files or not?
Well, I am just stating the status quo. A good portion of the prominent images still seem to be running as root and people created non-root versions. If you don’t want to maintain two images - I can totally understand that. Especially if it’s the better thing to do anyway.
But then - please document the uid that is being used.
I got it working by changing permissions. Maybe I had tighter permissions on the mount point than others. But right now the files n8n is creating are owned by a user that should not own them. Unless I am missing something, that’s because of the non-root uid used. It’s two systems with two different uid schemes after all.
I guess from now on, the only way to not to interfere with or depend on the host is to use data volumes.