running daytona server as root may mean the workspace files are owned by root

Is your feature request related to a problem? Please describe.

I'm not yet sure how I got here, but, I installed and ran daytona as a service one my headless system sudo'd as root, and later added it as the only profile on my notebooks.

from one notebook, I created a workspace, and connected to it from vscode - which seemed fine, BUT I can't save, because the files are owned by root, but my ide is connected as the daytona user.

Describe the solution you'd like magic should work :)

Describe alternatives you've considered I've considered reading the docs :)

Additional context

[sven@p1gen4:~/src/daytona]$ ./daytona code

 Opening the project 'daytona' from workspace 'daytona' in VS Code

FATA[0019] exit status 255                              

[sven@p1gen4:~/src/daytona]$ ./daytona create https://github.com/SvenDowideit/dockerfiles
 WORKSPACE   | ✓ Request submitted
 WORKSPACE   | ✓ Creating workspace dockerfiles (21275987fd4e)
 dockerfiles | Creating project dockerfiles
 dockerfiles | Pulling image...
 dockerfiles | Pulling from daytonaio/workspace-project
 dockerfiles | Digest: sha256:add38a473e9f16a4c077765872e4c0e6ee98862486337599e9e24b44be162235
 dockerfiles | Status: Image is up to date for daytonaio/workspace-project:latest
 dockerfiles | Image pulled successfully
 dockerfiles | Cloning into '/workdir/21275987fd4e-dockerfiles'...
 dockerfiles | Pulling image...
 dockerfiles | Pulling from daytonaio/workspace-project
 dockerfiles | Digest: sha256:add38a473e9f16a4c077765872e4c0e6ee98862486337599e9e24b44be162235
 dockerfiles | Status: Image is up to date for daytonaio/workspace-project:latest
 dockerfiles | Image pulled successfully
 WORKSPACE   | ✓ Workspace creation complete. Pending start...
 WORKSPACE   | ✓ Starting workspace
 dockerfiles | Project dockerfiles created
 dockerfiles | Starting project dockerfiles
 dockerfiles | Downloading Daytona binary from https://api-2e1be86b-c9d0-4d83-96e3-6e83fe30233b.try-us.daytona.app/binary/v0.21.3/daytona-linux-amd64
 WORKSPACE   | ✓ Workspace dockerfiles started
 dockerfiles | Project dockerfiles started
 dockerfiles | Installing server to /usr/local/bin
 dockerfiles | Starting Daytona Agent
 dockerfiles | Repository already exists. Skipping clone...
 dockerfiles | No post create commands to run
 dockerfiles | Running post start commands...
 dockerfiles | Starting ssh server on port 2222...

   Workspace       dockerfiles                                                                                                                                  

   ID              21275987fd4e                                                                                                                                 

   Editor          VS Code                                                                                                                                      

   State           RUNNING                                                                                                                                      

   Branch          master                                                                                                                                       

   Repository      github.com/SvenDowideit/dockerfiles.git                                                                                                      

 Run 'daytona code' when you're ready to start developing

[sven@p1gen4:~/src/daytona]$ ./daytona code

 Opening the project 'dockerfiles' from workspace 'dockerfiles' in VS Code

and then from the vscode terminal:

daytona ➜ ~/dockerfiles $ ls -la
total 176
drwxr-xr-x 40 root    root    4096 Jul 10 10:59 .
drwxr-x---  1 daytona daytona 4096 Jul 10 11:13 ..
drwxr-xr-x  2 root    root    4096 Jul 10 10:59 ambassador
drwxr-xr-x  2 root    root    4096 Jul 10 10:59 apache
drwxr-xr-x  2 root    root    4096 Jul 10 10:59 apt-cacher-ng

Hi @SvenDowideit, thanks for the detailed issue!

We are aware of this and, unfortunately, there's nothing we can do here. We missed the case where the server is ran as root, but as you can se here, we provide notice when adding a remote docker target.

The issue here is that, once we clone the repo, we attempt to remap the UID and GID so that the ownership inside the container is correct. This can not be done when the files are owned by root.

As part of solving this issue we should detect that the user ran the server as root and inform the user of the caveat (+ add this to the docs as a warning as well).

If you believe there is a way around this, we're happy to hear your suggestions.

P.S. The same problem would occur if you attempt to open a devcontainer (using the VS Code extension) from a folder owned by root.

ok, yup, this is complicated - in the process, I now know that the git repository is cloned into the daytona server user's ~/.config/daytona/providers/docker-provider ... dir structure, which in my build system's case is root, because i was thinking ala the docker daemon, that at some point, multiple (trusted) people from different user accounts might access the same server.

(For other readers, I was wrong in thinking that way - for now :) )

so - (sorry, digging up old memories), which I needed to do something similar, I instead leaned into cloning the repository into a non-bind-mapped Docker volume - and then controlling the file ownership very tightly.

I don't (yet) know if this is the case for daytona, but if daytona code sessions all run in a container that is set up as user 1000:1000, then I'd avoid the root user's home dir, use a named docker volume (docker volume create daytona-workspace style), and clone into that as user 1000 (daytona).

I'm sure there are other corner cases too - this kind of thing is never as simple as I just made it out to sound like :)

mmm, I really do want to double down on the "please don't put non- small non-configuration files into ~/.config" - it makes backups and network filesystems much harder - whereas the /var/lib/docker/volumes dir is going to be ugly :)

(mmm, I am only playing on my Linux box atm, I wonder how much harder OSX and Windows will be in practice)

PPS: for those playing along, I chown -R 1000:1000 ~/.config/daytona/providers/docker-provider/21275987fd4e/21275987fd4e-dockerfiles and my ide sessions are happy :) (don't do this unless you're not worried)

We have https://github.com/daytonaio/daytona/issues/726 opened to allow users to configure named volumes instead of writing to the fs. This might help with this issue.

but if daytona code sessions all run in a container that is set up as user 1000:1000

This is not always the case since users have the freedom to setup a devcontainer which has a user of a different UID/GID so it complicates things.

I suggest we implement the root check for now and update the docs + when we tackle the named volumes config, things might clear up for root.

mmm, I really do want to double down on the "please don't put non- small non-configuration files into ~/.config" - it makes backups and network filesystems much harder - whereas the /var/lib/docker/volumes dir is going to be ugly :)

Yes, I agree. We will definitely have to discuss and change where we keep daytona-related files.

daytonaio / daytona

running daytona server as root may mean the workspace files are owned by root #749