Temporary permissions issues on launch (detected dubious ownership in repository)

[mjswensen]

What happened?

For the first few minutes after a container starts, the owner of the repository folder is root. At seemingly random, it changes to the correct user (in my case: node for the official Node.js-based dev container by Microsoft).

Below are some commands run from within the container shortly after starting it up. No other commands were run between them. I've highlighted the permission change in yellow:

Here's the text version of the screenshot:

1. git status results in fatal: detected dubious ownership in repository at ...
2. ls -alF shows current working directory owned by root:root
3. Another ls -alF, run perhaps 30-60 seconds after the previous, shows current working directory owned by node:node, as it should be
4. Another run of git status results in no error. (Also the branch name shows in the bash prompt since the permissions are in a corrected state)

What did you expect to happen instead?

The permissions should be correct upon the launching of the editor connected to the container.

How can we reproduce the bug? (as minimally and precisely as possible)

devcontainer.json:

{
  "name": "...",
  "build": { "dockerfile": "./Dockerfile" },
  "customizations": {
    "vscode": {
      "extensions": [
        "angular.ng-template",
        "editorconfig.editorconfig",
        "esbenp.prettier-vscode"
      ]
    }
  },
  "features": {
    "ghcr.io/devcontainers/features/github-cli:1": {}
  }
}

Dockerfile:

FROM mcr.microsoft.com/devcontainers/javascript-node:20
...

1. Set up a git repository with the above container configuration files.
2. Launch the dev container using DevPod
3. Observe the behavior outlined above

Local Environment:

• DevPod Version: v0.5.12
• Operating System: mac
• ARCH of the OS: ARM64

DevPod Provider:

• Local/remote provider: docker

Anything else we need to know?

The IDE used for the container is VS Code for web.

---

Thank you for this awesome tool!

[jzazo]

I think I have encountered a similar problem in the past. In my case, I had to add a custom user (vscode) to my dockerfile, add it to the sudoers group (if you want), and then either you switch user in your dockerfile, or set the user option in the devcontainer.json.

Try adding this to your Dockerfile:

ARG USERNAME=vscode
ARG USER_UID=1000
ARG USER_GID=$USER_UID

RUN groupadd --gid $USER_GID $USERNAME \
    && useradd --uid $USER_UID --gid $USER_GID -m $USERNAME \
    && echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME \
    && chmod 0440 /etc/sudoers.d/$USERNAME

USER $USERNAME

[jzazo]

alternative you may want to add the "ghcr.io/devcontainers/features/common-utils" feature. Not sure if you need both or just one. I use both and it works for me.

[haukex]

I'm having a similar issue, though the permissions don't change after a few minutes.

The devcontainer.json I'm testing this on is here (based on mcr.microsoft.com/devcontainers/python:3.9-bookworm).

In GitHub Codespaces, after a fresh build, the ownership of /workspaces/igbpyutils is vscode:root, and in DevPod, it's root:root (and it doesn't change).

I have to do a sudo chown -R `id -u` /workspaces/* to fix the git error message.

(I'm also wondering why everything is 777 by default?)

[bkneis]

@jzazo @haukex @mjswensen thank you for reporting the issue and providing some information on this. By default devcontainer's use the root user, devpod needs to chown the workspace on your local environment in order for the remote user to edit the files. If you need to use a non root user, as @jzazo mentioned, you need to use the feature "ghcr.io/devcontainers/features/common-utils" and use a remoteUser in your devcontainer.json. I hope this helps!

[haukex]

@bkneis Thanks for the reply. I understand I could try to use features/common-utils, but I'm not sure I understood what you meant by:

devpod needs to chown the workspace on your local environment in order for the remote user to edit the files

Are you confirming that this is an issue with devpod? I.e. it should be chowning the files, but in some cases isn't?

[bkneis]

@haukex apologies for not making that clearer. I believe you need to set the remoteUser in devcontainer.json to node. I think your devcontainer is using this user but you are not specifying it, so when you launch the IDE or SSH it is using root instead of node

[haukex]

@bkneis Thanks for the feedback, I will do some more testing when I have the time and get back to you. One thing I did already test, as mentioned above, is that GitHub Codespaces does behave differently from DevPod in this respect.

[haukex]

@bkneis I did some more testing:

You mentioned ghcr.io/devcontainers/features/common-utils, but the image I was using, mcr.microsoft.com/devcontainers/python:3.9-bookworm, already includes this, in my case a user vscode was being set up with UID:GID 1000:1000, so I don't need to add another user in my own devcontainer.json.

So I did some more digging, and found the issue: I'm using Docker with WSL2 on Win 10, and in my WSL, for some reason my UID and GID were not the default 1000:1000, so they didn't match the UID:GID being used by the default user in the Docker container.

Once I fixed my WSL installation so the UID:GID of the default user were 1000:1000, everything works as expected for me. Thanks for your help and please consider this resolved on my end (though of course I don't know if the OP @mjswensen is still having this issue).

[bkneis]

@mjswensen have you tried using the ghcr.io/devcontainers/features/common-utils to set up the remote user? Or use the dockerfile method as @jzazo mentioned? Did this solve your issue?

[mjswensen]

Thanks for the follow-up!

@mjswensen have you tried using the ghcr.io/devcontainers/features/common-utils to set up the remote user?

No, I haven't—to be honest, since all I do is local development I decided to switch to a simple container runtime (colima) and just use VS Code's remote container extension to manage my devcontainers. But after reading your comments and research in this thread (thanks again @haukex @bkneis) I would bet that the solution you are proposing would work great. Feel free to close this 👍