chrmarti
commented
5 months ago Could you try with "containerUser": "vscode"?
Open stewartadam opened 5 months ago
chrmarti
commented
5 months ago Could you try with "containerUser": "vscode"?
stewartadam
commented
5 months ago remoteUser defaults to containerUser, would you also like me to set "remoteUser": "root" in conjunction with container user?
I'm happy to but then it's no longer rootless.
chrmarti
commented
5 months ago Only use "containerUser": "vscode". I'm suggesting that because Docker mounts volumes using the container's user.
With "rootless" are you referring to Docker's rootless mode? That shouldn't be affected by the choice of users inside the container, these should all be mapped to unprivileged users outside the container if I understand correctly.
stewartadam
commented
5 months ago I just tried with "containerUser": "vscode" and unfortunately the same issue. The volumes get mounted owned by root.
[6305 ms] Start: Starting container
[6306 ms] Start: Run: docker run --sig-proxy=false -a STDOUT -a STDERR --mount source=/Users/stewartadam/redacted,target=/workspace,type=bind --mount type=volume,src=0rsrv5j7ppticj9tcnk16p3nh9f0565um7elg38mari18hn4332a-azclidata,dst=/home/vscode/.azure --mount type=volume,src=0rsrv5j7ppticj9tcnk16p3nh9f0565um7elg38mari18hn4332a-pfdata,dst=/home/vscode/.promptflow --mount type=volume,src=vscode,dst=/vscode -l devcontainer.local_folder=/Users/stewartadam/redacted -l devcontainer.config_file=/Users/stewartadam/redacted/.devcontainer/devcontainer.json -e PDM_PYTHON=/workspace/.venv/bin/python -u vscode --entrypoint /bin/sh vsc-wellington-40fc677e53982b90ade450f8bd172cce797d1f0699436c03f035d421f77ef623-features -c echo Container started
Container started@chrmarti is there any more info I can help provide? You can find a repro here: https://github.com/stewartadam/devcontainer-repro
workspace-3.11vscode ➜ /workspace (main) $ ls -ld ~/.promptflow
drwxr-xr-x 2 root root 4096 Jun 24 23:14 /home/vscode/.promptflow
workspace-3.11vscode ➜ /workspace (main) $ Make sure the volume does not exist yet, I think it applies the ownership only when it first creates the volume.
Someone found a way to do it without changing containerUser: https://github.com/microsoft/vscode-remote-release/issues/7690#issuecomment-2159043850
stewartadam
commented
4 months ago I've tried with fresh volumes, the ownership is still incorrect.
The trick in that comment does work but then requires you setup a customer Dockerfile for the devcontainer. It doesn't work out of the box with a base image and requires the dockerfile be modified for each mount.
stewartadam
commented
4 months ago This issue also appears to break being able to setup a volume for VSCode Extensions by mounting /home/vscode/.vscode-server as a volume as noted here, because mkdir ~/.vscode-server/bin is run before any of the command hooks that can be used to fix the permissions:
JaneSmith
commented
1 month ago Did you ever find a solution to this? I have the same problem. I'm on Linux using the VS Code Flatpak and Podman, and if I set a volume mount it gets owned by root. The user in the container is "node", so I can't do anything with the mounted files. The only solution I've found so far is to set remoteUser to root, which then allows me to access the mounted directory, but it seems very hacky...
Edit: Yeah, this doesn't seem like a great solution... Now all the files created by VS Code, are inaccessible on the host, as they're owned by a different user/group (100000). I have to manually chown them back. Very annoying.
stewartadam
commented
1 month ago On my Debian base image passwordless sudo appears to work, so my workaround was adding a sudo chown $USER:$USER command to a postCreateCommand script and hard coding each of the volume paths I setup in devcontainer.json.
Not pretty but it works.
reynoldsbd
commented
2 weeks ago Same issue here, using VS Code on Windows + WSL2. Seems like devcontainer tooling totally skips UID/GID remapping for volumes.
The workaround worked for me, although oddly the $USER env var doesn't appear to be set. Perhaps a quirk of the base image I'm using. Here is what I ended up with:
// .devcontainer/devcontainer.json
{
// ...
"postCreateCommand": {
"fixVolumePerms": "sudo chown -R $(whoami): /path/to/volume"
}
}
icariantk
commented
2 weeks ago Same issue here, using VS Code on Windows + WSL2. Seems like devcontainer tooling totally skips UID/GID remapping for volumes.
The workaround worked for me, although oddly the
$USERenv var doesn't appear to be set. Perhaps a quirk of the base image I'm using. Here is what I ended up with:// .devcontainer/devcontainer.json { // ... "postCreateCommand": { "fixVolumePerms": "sudo chown -R $(whoami): /path/to/volume" } }
You just saved me a lot of time. Right to the point, thanks.
reynoldsbd
commented
2 weeks ago @chrmarti the following docs from the VS Code website are technically impacted by this issue:
https://code.visualstudio.com/remote/advancedcontainers/persist-bash-history
If a user's UID on the host is anything but 1000, then the "persist bash history" docs would be broken, because there would be a mismatch between the initial UID applied to the volume mount (1000) and the remapped UID applied by devcontainer tooling.
Should we update the docs to mention this issue and/or include the workaround? Or would it make sense to go deeper and try to fix the root issue?
chrmarti
commented
2 weeks ago @reynoldsbd I will add the workaround to the documentation. Thanks!
The root issue seems to be that Dev Containers often use a non-root user while the container user is root and Docker makes the container user the owner of new volumes. We have considered changing the container user to be the non-root user in the base images we provide, but that would potentially cause issues with scripts (e.g., daemons) that are run as part of the entrypoint. (E.g., container features can add to the entrypoint.)
The solutions I can think of essentially boil down to the solution you suggest above (https://github.com/microsoft/vscode-remote-release/issues/9931#issuecomment-2450277846). There is also the option of creating the mount folder with the correct owner in the Dockerfile and Docker will then use that for the new volume, but your suggestion is easier to apply by the user and doing this automatically might not always be expected.
vs-code-engineering[bot]
commented
1 week ago This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!
stewartadam
commented
1 week ago ?
chrmarti
commented
1 week ago Another idea is that a feature's entrypoint runs as part of the containers entrypoint and can be used to adjust permissions after the container started.
E.g., adding a local feature to the devcontainer.json:
"features": {
"./local-features/chown": {}
},.devcontainer/local-features/chown/devcontainer-feature.json:
{
"id": "chown",
"version": "1.0.0",
"entrypoint": "chown -R node:node /path/to/mountpoint"
}.devcontainer/local-features/chown/install.sh is required, but can be empty:
#!/bin/sh
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 10 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
When a
remoteUseris specified, I don't believe this is presently a way currently to use volume mounts that mount outside /home/vscode due to the ensuing permission issues.This is frustrating because for Python packaging for example, it's important the container have its own volume for
.venvinstead of re-using the hosts'.venv, which might contain binary extensions compiled for the different OS.Information
Steps to Reproduce
Setup a basic rootless devcontainer.json (in this case remoteUser is
vscode):Expected results
Volume permissions are automatically adjusted to match the configured
remoteUser, or a root-user entrypoint is available so that the permissions can be adjusted.Actual results
Volume is mounted using the parent folder permissions (in this case, root:root). All lifecycle script hooks (e.g.
postCreateCommand) are run underremoteUserand therefore the volume mount cannot be used and its permissions cannot be changed without removing rootless.Does this issue occur when you try this locally?: N/A Does this issue occur when you try this locally and all extensions are disabled?: Yes