Closed SvenDowideit closed 4 weeks ago
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.
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
and then from the vscode terminal: