Error on cloneUserNs permissions

đź’¬ Self Hosted Retool
1

My goal: Deploy Retool without temporal

Setup

I’m following the tutorial to self host Retool using the AWS EC2 tutorial. I’m using:

  • the version of Retool that comes from cloning your repo, as of yesterday
  • docker 3.253.6-stable
  • Ubuntu 24.04.3 LTS

I would like not to use Temporal. I am using Aurora instead, as in the tutorial, you mention the below.

Retool recommends using a separate datastore for the Workflows Queue in production. Consider using AWS Aurora Serverless V2 configured to an ACU (cpu) provision ranging from 0.5 to 8 ACU.

The tutorial also instructs users to use default values in the configuration during set up, and so I have done this.

The issue

I run sudo docker compose up -d and all 11 containers are marked as running. However, when I try http://<your-ec2-ip-address>/auth/signup I get:

The connection to the server was reset while the page was loading.

My EC2 has HTTP port open, which I can see when I scan with nmap.

I have tried to dig into the logs with sudo docker logs --tail=100 retool-onpremise-master-code-executor-1 in docker and I see:

Error when executing code in sandbox. Is the container configured with privileged and cloneUserNs permissions? If you do not need code sandboxing, set CONTAINER_UNPRIVILEGED_MODE='true' environment variable

However, the code executor block in my compose.yml has privelged: true and I have set CONTAINER_UNPRIVILEGED_MODE='true' in docker.env.

Please could you advise on how best to fix this issue?

1 Like
3

Hi @mdeo,

Thank you for sharing those details. Firstly, I just want to confirm that if you are not going to connect to temporal that you are ok with not being able to use workflows.

Secondly, on the connection reset error, there are a couple possibilities as to why that is happening.

The signup page may be trying to hit a backend service which is failing or crashing. If some essential service (e.g., MAIN_BACKEND or API) depends on workflows/Temporal and can’t find it, it might be failing early.

The code-executor sandbox error you saw may hint at the code-executor container not correctly starting/sandboxing, which could block initial setup.

If you attempted to “comment out” workflow/Temporal containers but left environment variables pointing at them (or mis-configured your docker.env), then one of the containers might be failing or stuck, causing network resets.

Make sure all containers that are required for login/signup are healthy (especially api/backend, jobs-runner, code-executor if you have it, and your Postgres database). Check docker compose ps and docker logs for errors. The code-executor error you saw suggests one container is misbehaving.

You said you set CONTAINER_UNPRIVILEGED_MODE='true' and gave privileged: true to code-executor. That usually is sufficient for the sandbox. But check that the container actually restarted cleanly and that this error is not repeated often. Possibly sandboxing still failing, causing resource starvation or crash.

Since you’re using Aurora instead of local Postgres (as you wrote), ensure connections from your EC2 container to Aurora are fully reachable (security groups, network, VPC, etc.). Because if your database is unreachable, the backend could fail to start fully — leading to the reset. I know you said your EC2 opened HTTP, but check database connectivity too.

For next steps, along with what I wrote above, I would also advise the follow steps:

  • Restart the stack: docker compose down && docker compose up -d (or sudo docker compose ...).
  • Tail logs of the key containers: docker logs -f <backend_container>, docker logs -f <jobs-runner_container>. Look for errors during startup.
  • Try hitting /auth/signup again. If still “connection reset”, check EC2 instance logs (docker, kernel, firewall) to see if container is listening on port 3000 (or whatever port), maybe try curl http://localhost:3000/auth/signup from inside the container host.

Let me know if the other containers are throwing any errors and be certain there are no WORKFLOW_TEMPORAL_* variables in docker.env :+1:

5

Hi @Jack_T ,

Thanks for coming back to me.

Here’s some more info about what I’ve done since posting my original response:

  • Removed all WORKFLOW_TEMPORAL_* variables in retool-onpremise-master's docker.env

  • Ran curl ``http://localhost:3000/auth/signup from inside the host and saw:

    • curl: (56) Recv failure: Connection reset by peer

  • Checked the logs for my db, and EC2. Both look to be healthy

  • Ran sudo docker compose down && sudo docker compose up -d

    • When tailing the logs for retool-onpremise-master-code-executor-1 I got the same error as before:

      Error when executing code in sandbox. Is the container configured with privileged and cloneUserNs permissions? If you do not need code sandboxing, set CONTAINER_UNPRIVILEGED_MODE='true' environment variable.

  • Set CONTAINER_UNPRIVILEGED_MODE='true' in retool-onpremise-master's compose.yml and ran sudo docker compose down && sudo docker compose up -d

    • I tailed the logs for retool-onpremise-master-code-executor-1 and this gives me:

      Code executor container is specified to run in unprivileged mode (ALLOW_UNSAFE_CODE_EXECUTION=true) but the user running container is not the expected user, retool_user (uid 1001) in retool_user_group (gid 1001)

    • I also saw the below in tailing the logs for retool-onpremise-master-postgres-1:

    • 2025-11-04 15:46:29.501 UTC [6628] ERROR:  duplicate key value violates unique constraint "agents_model_unit_prices_stripePriceId_key"