[Bug]: permission issues accessing the workspace folder

[m9e]

Is there an existing issue for the same bug?

• [X] I have checked the troubleshooting document at https://docs.all-hands.dev/modules/usage/troubleshooting
• [X] I have checked the existing issues.

Describe the bug

When starting with the -e SANDBOX_USER_ID=$(id -u) syntax, the sandbox is created with an /etc/passwd like:

pn:x:1000:1000::/home/pn:/bin/bash
messagebus:x:100:102::/nonexistent:/usr/sbin/nologin
openhands:x:1001:0::/home/openhands:/bin/bash

But the parent container has openhands as uid 1000

as a result, the sandbox has permission denied on the workspace folder.

I am running it ~identical to the example in the readme:

export WORKSPACE_BASE=$(pwd)/workspace

docker run -it --pull=always \
    -e SANDBOX_RUNTIME_CONTAINER_IMAGE=ghcr.io/all-hands-ai/runtime:0.9-nikolaik \
    -e SANDBOX_USER_ID=$(id -u) \
    -e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
    -v $WORKSPACE_BASE:/opt/workspace_base \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -p 3000:3000 \
    --add-host host.docker.internal:host-gateway \
    --name openhands-app-$(date +%Y%m%d%H%M%S) \
    ghcr.io/all-hands-ai/openhands:0.9

and the executing user is id 1000 on the host system

the /etc/passwd from the openhands app container is:

   messagebus:x:100:101::/nonexistent:/usr/sbin/nologin
sshd:x:101:65534::/run/sshd:/usr/sbin/nologin
openhands:x:42420:42420::/home/openhands:/bin/bash
enduser:x:1000:42421::/home/enduser:/bin/bash

in the relevant part.

Current OpenHands version

0.9 - image id 2d5ad156203d

Installation and Configuration

docker run -it --pull=always -e SANDBOX_RUNTIME_CONTAINER_IMAGE=ghcr.io/all-hands-ai/runtime:0.9-nikolaik -e SANDBOX_USER_ID=1000 -e WORKSPACE_MOUNT_PATH=/path/to/my/workspace -v /path/to/my/workspace:/opt/workspace_base -v /var/run/docker.sock:/var/run/docker.sock -p 3001:3000 --add-host host.docker.internal:host-gateway --name openhands-app-20240917130226 ghcr.io/all-hands-ai/openhands:0.9

Model and Agent

• model: azure oai gpt4o
• agent: default (codeactagent?)

Operating System

ubuntu 22.04 lts server

Reproduction Steps

No response

Logs, Errors, Screenshots, and Additional Context

No response

[m9e]

[m9e]

as a note, the agent is trying to do work in /tmp but that's not very helpful since it won't persist

[mamoodi]

I'm not sure if it's the same issue but multiple people did run into permission issues on Discord using Ubuntu as well so would be good to get some eyes on this. Thanks for bringing it up.

[scott-r-lindsey]

I'm seeing the same issue

    |03:18:44 - openhands:INFO: client.py:685 - Runtime client initialized.
    |03:18:44 - openhands:INFO: client.py:687 - Starting action execution API on port 44623
    |INFO:     Started server process [15]
    |INFO:     Waiting for application startup.
    |03:18:44 - openhands:WARNING: client.py:160 - UID 1000 is not unique. Incrementing UID and retrying...
    |03:18:44 - openhands:INFO: browser_env.py:58 - Starting browser env...

id -u returns "1001", so we can't edit files. Seems like you need a step in your docker file that rewrites the user ids to match the host machine, but for some reason the opposite is happening.

[mamoodi]

Thanks again for bringing up this issue and these logs. I think the cause has been identified and they are trying to see how to approach this. Seems like the sandbox container used has a conflicting UID.

[mamoodi]

@m9e or @scott-r-lindsey, can you delete docker images associated with OpenHands and run the app replacing 0.9 in two places with "main" please?

export WORKSPACE_BASE=$(pwd)/workspace

docker run -it --pull=always \
    -e SANDBOX_RUNTIME_CONTAINER_IMAGE=ghcr.io/all-hands-ai/runtime:main-nikolaik \
    -e SANDBOX_USER_ID=$(id -u) \
    -e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
    -v $WORKSPACE_BASE:/opt/workspace_base \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -p 3000:3000 \
    --add-host host.docker.internal:host-gateway \
    --name openhands-app-$(date +%Y%m%d%H%M%S) \
    ghcr.io/all-hands-ai/openhands:main 

And see if this solves the issue?

[scott-r-lindsey]

@mamoodi right on the money, tyvm

$ id -u
1000