updateRemoteUserUID has no effect

[PhilDay-CT]

I'm running a dev container created from a base Ubuntu 24:04 image with and additional user account

$ cat Dockerfile 
FROM ubuntu:24.04
ARG USERNAME=guest
RUN useradd -m $USERNAME 
USER $USERNAME
CMD bash

$ docker buildx build --file Dockerfile  -t usertest:1.0.0 --load .
...
 => sending tarball                                                                                                                                                                             0.2s
 => importing to docker                                                                                                                                                                            0.0s

$ docker run -it usertest:1.0.0 bash
guest@c430c4b72d70:/$ id
uid=1001(guest) gid=1001(guest) groups=1001(guest)
guest@c430c4b72d70:/$ 
exit

On my host system my user id is 1000

$ id
uid=1000(phil) gid=1000(phil) groups=1000(phil),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),134(lxd),135(sambashare),999(docker)

Using this with the following devcontainer.json I was expecting the updateRemoteUserUID option to update the UID/GID to match my local UID/GID - which as per (https://containers.dev/implementors/json_reference/) I need to avoid permission issues in the mount, but it doesn't happen.

{
  "image": "usertest:1.0.0",
  "remoteUser": "guest",
  "containerUser": "guest",
  "updateRemoteUserUID": true
}

When I open a terminal in VSCode in the Docker the id is still set to guest

$ id
uid=1001(guest) gid=1001(guest) groups=1001(guest)

• VSCode Version:
  Version: 1.90.2
  Commit: 5437499feb04f7a586f677b155b039bc2b3669eb
  Date: 2024-06-18T22:33:48.698Z
  Electron: 29.4.0
  ElectronBuildId: 9728852
  Chromium: 122.0.6261.156
  Node.js: 20.9.0
  V8: 12.2.281.27-electron.0
  OS: Linux x64 6.5.0-35-generic snap

• Local OS Version:

$ uname -a
Linux ct-1 6.5.0-35-generic #35~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue May  7 09:00:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.4 LTS
Release:	22.04
Codename:	jammy

• Remote OS Version:
  ubuntu:24.04

$ uname -a
Linux 7558979553bb 6.5.0-35-generic #35~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue May  7 09:00:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

• Remote Extension/Connection Type: Containers/WSL/Server
  Containers

Steps to Reproduce:

See above for a simple Docker build that shows the issue. You need to ensue that the host uid and uid in the docker image don't match.

Generally - when using any docker image where the uid in the image does not match the uid in the container.

[davidchisnall]

We started seeing this issue after upgrading our dev container base from Ubuntu 22.04 to 24.04. The 22.04 base image has no existing users and so creating a non-root user gives a UID of 1000, with 24.04 there's an ubuntu user with UID 1000 so our UID is 1001. This has probably been broken for a while but was hidden by the fact that all of the people using our dev container on Linux use the first interactive user ID, which happened to match the user in the container.

We can work around it somewhat by forcing the UID of the user in the container to 1000, but that is just masking the problem.

[cadojo]

I have run into this issue on Ubuntu and MacOS hosts. I think this will particularly affect MacOS users, because MacOS assigns users to the staff group which is a different ID than the user ID, and the user ID is not 1000 or 1001 by default, as it is in Ubuntu. It seems that updateRemoteUserId has no effect.

[GuillaumeQuenneville]

I encountered the same issue, my host uid/gid was 1000/1001. I added

FROM mcr.microsoft.com/devcontainers/cpp:1-ubuntu-24.04

# Workaround for remoteuser id issue
# https://github.com/microsoft/vscode-remote-release/issues/10030
RUN usermod -u 2000 ubuntu && groupmod -g 2000 ubuntu
...

to the top of the devcontainer Dockerfile as a temporary workaround.

[chrmarti]

We don't update the UID when there already is a user with that UID. In this case Ubuntu 24.04 already has a user with UID 1000, so the UID 1001 user can't be updated to use UID 1000.

@samruddhikhandale This might be tricky to work around in the CLI because it might encounter various base images. Maybe we can work around it in our base images either by removing the ubuntu user or by updating its UID and GID to one that is unlikely to cause a conflict.

[GuillaumeQuenneville]

There are instructions in the advanced section for creating non-root users. https://code.visualstudio.com/remote/advancedcontainers/add-nonroot-user. It has a section on editting the UID/GID when creating an image https://code.visualstudio.com/remote/advancedcontainers/add-nonroot-user#_change-the-uidgid-of-an-existing-container-user but not if the base-image includes conflicting accounts. At the moment, suggestions that pop up when you search

dev containers eaccess permission
or
dev containers uid and gid don't match

in a search engine don't direct to this documentation and the results that do aren't very useful (other than this issue popping up). Maybe the documentation can be updated to mention these terms for SEO.

[samruddhikhandale]

@samruddhikhandale This might be tricky to work around in the CLI because it might encounter various base images. Maybe we can work around it in our base images either by removing the ubuntu user or by updating its UID and GID to one that is unlikely to cause a conflict.

When noble was released, we had a long discussion regarding how to handle it and we ended up with a collective decision of letting the vscode user be 1001 for noble distro and letting focal and jammy have vscode:1000

Sharing the couple of reasons we thought this was the right way -

• We can rename the user, however, we can not be confident if this would always work. Let’s say there are configuration files which references to ubuntu user, then things will start breaking post renaming. Renaming feels a risky change as we cannot guarantee that this will always work for 100% of the time.
• We expect that the majority of the users use the username to identify the user instead of the id. Hence, this should impact very few users as opposed to the renaming of the user
• As vscode:1000 remains intact for focal and jammy and only changes for noble. Hence, the community can take their sweet time (if needed) to switch to noble . Also, vscode always had the id set to 1000, however, we did not mention it anywhere that the id will remain constant. Hence, the community is majorly assuming that the id will not change. However, this is not a breaking change that will impact the current folks.
• Also, we will be waiting until 24.04.1 is released to switch the ubuntu tag to latest . Hence, this would not break the community until they decide to update their distro

@chrmarti It's been three months since we released base images with ^, not sure what's the best way is to handle it. We can still make changes given the fact that noble is not yet latest for the base image. Also, we have seen devcontainers/images#1056

Let me know what you think!

[chrmarti]

Given that this breaks our fix for the workspace file ownership mismatch on Linux (the UID updater) for local UID 1000, I suggest we reconsider our options. We decided to keep the ubuntu user unchanged under the assumption that this would avoid interfering with the base image's setup. I think we probably just delete this user as suggested in devcontainers/images#1056 and then create the vscode user as before (UID 1000 will be reused in this case).

Some background on the ubuntu user: https://bugs.launchpad.net/cloud-images/+bug/2005129

[samruddhikhandale]

We decided to keep the ubuntu user unchanged under the assumption that this would avoid interfering with the base image's setup.

Yes, that was definitely our thoughts there.

I think we probably just delete this user as suggested in devcontainers/images#1056 and then create the vscode user as before (UID 1000 will be reused in this case).

Makes sense, thanks!

[chrmarti]

Continuing in devcontainers/images#1056. Thanks.