Open jhrmnn opened 1 year ago
@chrmarti May I know if you are able to repro this?
Hi I am having the same issue.
Apparently this is something not stable to use since the instructions page throws a 404 now.
My experience was when creating the volume for the first time it kinda worked but every subsequent build it created a .obsolete
file in the ~/.vscode-server/extensions
directory.
I have been following the now-missing "avoid extension reinstalls" guide, and my extensions have been completely unstable over the past week or so. My main question: What is the new guidance for avoiding extension reinstalls?
To be more specific, in my case, seemingly at random, after startup several extensions are missing and their installation page displays the following warning:
⚠️ This extension is disabled in this workspace because it is defined to run in the Remote Extension Host. Please install the extension in 'Dev Container: project_name' to enable. Learn More
and the "Dev containers" startup shell shows
[13141 ms] Extension 'ms-python.python' v2022.20.2 is already installed. Use '--force' option to update to latest version or provide '@<version>' to install a specific version, for example: 'ms-python.python@1.2.3'.
[13152 ms] Extension 'ms-python.vscode-pylance' v2023.1.30 is already installed. Use '--force' option to update to latest version or provide '@<version>' to install a specific version, for example: 'ms-python.vscode-pylance@1.2.3'.
Sometimes this happens after reloading the window. The random nature of the problem makes it really hard to reproduce reliably.
For me, I noticed it seems to alternate. If the extension is installed, it will get uninstalled. If it is not installed, it will attempt to install. That said, the workaround by the issue author seems to work.
We cache VSIXs in a vscode
volume to improve performance. Not sure why the manual mounting of the extensions folder no longer works.
I'm also experiencing issues with avoiding extension re-installs. Up until a couple weeks ago, everything seemed to work fine with the following setup:
docker-compose:
- vscode-extensions:/home/vscode/.vscode-server/extensions
- vscode-insider-extensions:/home/vscode/.vscode-server-insiders/extensions
Dockerfile:
RUN mkdir -p /home/$USERNAME/.vscode-server/extensions \
/home/$USERNAME/.vscode-server-insiders/extensions \
&& chown -R $USERNAME \
/home/$USERNAME/.vscode-server \
/home/$USERNAME/.vscode-server-insiders
devcontainer.json:
"extensions": [
"ms-python.python",
"ms-python.pylint",
"ms-python.vscode-pylance",
...
]
At some point no extensions would install when I rebuilt the container, until I changed the way extensions were defined in devcontainer.json:
"customizations": {
"vscode": {
"extensions": [
"ms-python.python",
"ms-python.pylint",
"ms-python.vscode-pylance",
...
Now the extensions will install upon rebuild, but the caching does not work. It seems to install them every time.
The following works for me:
{
"image": "ubuntu:latest",
"mounts": [
"source=vscode-extensions,target=/root/.vscode-server-insiders/extensions,type=volume"
],
"customizations": {
"vscode": {
"extensions": [
"dbaeumer.vscode-eslint"
]
}
}
}
Could you append your log from when you rebuild the container? (F1
> Dev Containers: Show Container Log
)
I can get you the log later, one thing I did notice is that with a fresh build after removing the volume mounts:
/home/vscode/.vscode-server/extensions
<-- exists
/home/vscode/.vscode-server-insiders/extensions
<-- does not exist
I have been following the now-missing "avoid extension reinstalls" guide, and my extensions have been completely unstable over the past week or so. My main question: What is the new guidance for avoiding extension reinstalls?
To be more specific, in my case, seemingly at random, after startup several extensions are missing and their installation page displays the following warning:
⚠️ This extension is disabled in this workspace because it is defined to run in the Remote Extension Host. Please install the extension in 'Dev Container: project_name' to enable. Learn More
and the "Dev containers" startup shell shows
[13141 ms] Extension 'ms-python.python' v2022.20.2 is already installed. Use '--force' option to update to latest version or provide '@<version>' to install a specific version, for example: 'ms-python.python@1.2.3'. [13152 ms] Extension 'ms-python.vscode-pylance' v2023.1.30 is already installed. Use '--force' option to update to latest version or provide '@<version>' to install a specific version, for example: 'ms-python.vscode-pylance@1.2.3'.
Sometimes this happens after reloading the window. The random nature of the problem makes it really hard to reproduce reliably.
Any updates / movement on this? This is driving me insane also. Upon build/rebuilds... extensions defined in the devcontainer.json seem to install randomly. On one build, a few are always missing... and it's completely random which ones those are. There's no consistent way to ensure all of them are being installed.
@code-n-go I'm having this problem too. After the latest update (Aug. 23), every time I reload a remote container window I need to reinstall the python extension.
I just put in some time to minimize my devcontainer.json
and produce some logs.
I was even able to reproduce the problem without the bind mount, so perhaps in my case it's not even the cache which is responsible.
Here's my devcontainer.json
:
{
"image": "ubuntu:latest",
"extensions": [
"ms-python.python",
"ms-python.vscode-pylance",
"ms-python.flake8",
"ms-python.isort",
"ms-toolsai.jupyter",
"ms-azuretools.vscode-docker",
"ms-vsliveshare.vsliveshare",
"donjayamanne.githistory",
"eamodio.gitlens",
"github.copilot",
"exiasr.hadolint",
"jnoortheen.xonsh",
]
}
Note that I can't seem to reliably trigger the failure, so it's really painstaking to reduce the list of extensions I'm installing.
In this case the Jupyter extension didn't install.
The part of the logs which looks likely relevant is:
[2023-08-11T12:03:43.347Z] [12:03:43] Extracting extension completed. ms-toolsai.jupyter-renderers
[2023-08-11T12:03:43.402Z] [12:03:43] Marked extension as uninstalled ms-toolsai.jupyter-keymap-1.1.2
[2023-08-11T12:03:43.422Z] [12:03:43] Marked extension as uninstalled ms-toolsai.vscode-jupyter-slideshow-0.1.5
[2023-08-11T12:03:43.423Z] [12:03:43] Rollback: Uninstalled extension ms-toolsai.jupyter-keymap
[12:03:43] Rollback: Uninstalled extension ms-toolsai.vscode-jupyter-slideshow
[12:03:43] Rollback: Uninstalled extension ms-toolsai.jupyter-renderers
[2023-08-11T12:03:43.438Z] [12:03:43] Marked extension as uninstalled ms-toolsai.jupyter-renderers-1.0.17
@chrmarti, I hope this satisfies your previous request for logs, even if in my case it doesn't directly relate to the cache?
I want to revitalize this thread, as I think I'm seeing the same behavior. I've got a non-root user (vscode
) and I'm already persisting the user profile as a volume:
"mounts": [
"source=profile-${localEnv:USER}${localEnv:USERNAME}-${devcontainerId},target=/home/vscode,type=volume" // persistent (named) volume for user profile
],
This works as-expected (in that it persists the user home folder), but per the Tips and Tricks::Persisting User Profile, I would also like to have my VS Code data in an anonymous volume, such that it gets destroyed on rebuild.
When I try to add the anonymous volume as
"mounts": [
"source=profile-${localEnv:USER}${localEnv:USERNAME}-${devcontainerId},target=/home/vscode,type=volume", // persistent (named) volume for user profile
"target=/home/vscode/.vscode-server,type=volume" // ephemeral volume for user-space VS Code extensions and dotfiles
],
I get permissions errors during container build/open when VS Code attempts to create the /home/vscode/.vscode-server/bin
directory. I'm guessing this is a permissions issue, potentially related to the UID/GID rewrite?
@jonbackhaus same thing.
I really would like to know which option works currently
Did you found out?
[13168 ms] Start: Run in container: test -d '/home/vscode/.vscode-server'
[13170 ms]
[13170 ms]
[13171 ms] Start: Run in container: test ! -f '/home/vscode/.vscode-server/data/Machine/.writeMachineSettingsMarker' && set -o noclobber && mkdir -p '/home/vscode/.vscode-server/data/Machine' && { > '/home/vscode/.vscode-server/data/Machine/.writeMachineSettingsMarker' ; } 2> /dev/null
[13175 ms]
[13176 ms] mkdir: cannot create directory ‘/home/vscode/.vscode-server/data’: Permission denied
[13178 ms] Exit code 1
[13179 ms] Start: Run in container: cat /home/vscode/.vscode-server/data/Machine/settings.json
[13186 ms]
[13186 ms] cat: /home/vscode/.vscode-server/data/Machine/settings.json: No such file or directory
[13186 ms] Exit code 1
[13186 ms] Start: Run in container: test -d '/home/vscode/.vscode-server/bin/dc96b837cf6bb4af9cd736aa3af08cf8279f7685'
[13187 ms]
[13187 ms]
[13187 ms] Exit code 1
[13187 ms] Start: Run in container: test -d '/vscode/vscode-server/bin/linux-x64/dc96b837cf6bb4af9cd736aa3af08cf8279f7685'
[13189 ms]
[13189 ms]
[13189 ms] Start: Run in container: mkdir -p '/home/vscode/.vscode-server/bin' && ln -snf '/vscode/vscode-server/bin/linux-x64/dc96b837cf6bb4af9cd736aa3af08cf8279f7685' '/home/vscode/.vscode-server/bin/dc96b837cf6bb4af9cd736aa3af08cf8279f7685'
[13191 ms]
[13191 ms] mkdir: cannot create directory ‘/home/vscode/.vscode-server/bin’: Permission denied
[13191 ms] Exit code 1
[13192 ms] Start: Run: docker rm -f 0f0da4067df3d23322a925e228886874fd645d62680d86b3eaaaee32339dbd56
[13212 ms] Command in container failed: mkdir -p '/home/vscode/.vscode-server/bin' && ln -snf '/vscode/vscode-server/bin/linux-x64/dc96b837cf6bb4af9cd736aa3af08cf8279f7685' '/home/vscode/.vscode-server/bin/dc96b837cf6bb4af9cd736aa3af08cf8279f7685'
[13213 ms] mkdir: cannot create directory ‘/home/vscode/.vscode-server/bin’: Permission denied
[13214 ms] Exit code 1
[13282 ms] Container server terminated (code: 137, signal: null).
Named volumes get their UID/GID initially set to the container user which is root in this case. Anonymous volumes appear to always be owned by root initially (unless I'm missing something). You could change the ownership manually or try to do it in the container's entrypoint.
Named volumes get their UID/GID initially set to the container user which is root in this case. Anonymous volumes appear to always be owned by root initially (unless I'm missing something). You could change the ownership manually or try to do it in the container's entrypoint.
Do you have a code sample example?
Okay. I managed to fix this in our custom development container build. Here's the excerpt from the Dockerfile
:
## configure build
ARG USERNAME=vscode
ARG USERHOME_PATH="/home/${USERNAME}"
## configure environment
USER ${USERNAME}
## configure VS Code ephemeral volume
ARG VSCODE_SERVER_PATH="${USERHOME_PATH}/.vscode-server"
VOLUME [ "${VSCODE_SERVER_PATH}" ]
RUN set -eux; \
sudo mkdir -p "${VSCODE_SERVER_PATH}" ; \
sudo chown ${USERNAME}:${USERNAME} "${VSCODE_SERVER_PATH}"
Per the container details, the /home/vscode/.vscode-server
directory is now a volume mount.
Note: with this implementation, there's no need to also add an anonymous mount in the devcontainer.json
specification.
Do you think it would be possible to do that without a Dockerfile?
Do you think it would be possible to do that without a Dockerfile?
Off the top of my head, it might be possible with an entrypoint
that sets the ownership and an anonymous mount in the devcontainer.json
file?
You could also have a minimal Dockerfile that starts with your image and makes the ownership changes on the fly. That would be self-contained in the sense that you wouldn't need to build and maintain a separate "custom" image.
No idea how to do that alone for now
Thanks for your guidance :heart:
I think I will give up until their docs actually work
I put together a quick example showing how to specify the volume and permissions in the Dockerfile
: https://github.com/jonbackhaus/docker-vscode-devcontainer-example
What's the status here @chrmarti? We are currently facing this issue in the company that I am working for and we'd very much appreciate knowing how to solve it. I tried the approach of manually creating the directory with the correct permissions and mounting a volume there, but this did not work.
We are using a container that is started by root ("containerUser": "root"
), but the remoteUser
is not root
.
UPDATE: I got it to work now. The VOLUME
directive does not work for us. One has to set up the permission in the Dockerfile
:
[!WARNING]
This comment was updated; please re-read!
RUN <<EOM
mkdir -p "${HOME}/.vscode-server"
chown -R "${USER}:${USER}" "${HOME}/.vscode-server"
mkdir -p "${HOME}/.cache"
chown -R "${USER}:${USER}" "${HOME}/.cache"
EOM
and then use volumes to mount to these directories in .devcontainer/devcontainer.json
:
{
// Persist the VS Code extension cache
"source": "cache-vscode_extensions",
"target": "<HOME>/.vscode-server/extensions",
"type": "volume"
},
{
// Persist the `${HOME}/.cache` directory
"source": "cache-home_cache",
"target": "<HOME>/.cache",
"type": "volume"
},
This seems to do the trick for us.
I recently realized that mounting a volume tp ~/.vscode-server
is definitely not desirable! You should mount to ~/.vscode-server/extentsions
while adjusting the permissions for ~/.vscode-server
!
See my updated comment.
It's the same problem for me. I'm facing a problem when using the volume mount for the directory /home/vscode/.vscode-server/extensions
. This will produce a new problem. Now, the home/vscode/.vscode-server
owner will be root
as it was created by the root
user, not the vscode
user. So the process failed as it tried to edit a folder that is owned by root.
Is there any way to change the VS Code extension location to a different location to avoid the permission problem??
I think the actual issue should be solved instead of looking for workarounds: this functionality needs to work out of the box.
The fact that this issue is open for over two years now is not a good sign. When will this be tackled?
Important
I recently realized that mounting a volume tp
~/.vscode-server
is definitely not desirable! You should mount to~/.vscode-server/extentsions
while adjusting the permissions for~/.vscode-server
!See my updated comment.
@georglauterbach -- can you elaborate on why it's not desirable to store the entire ~/.vscode-server
directory in an ephemeral volume (when running as a non-root user)?
@georglauterbach -- can you elaborate on why it's not desirable to store the entire
~/.vscode-server
directory in an ephemeral volume (when running as a non-root user)?
When storing the whole directory, the devcontainer.json
's IDE-specific settings
are not updated because they remain cached in the volume. The result is that updates to settings
are not applied on container restart.
At least this is what I observed.
@georglauterbach -- can you elaborate on why it's not desirable to store the entire
~/.vscode-server
directory in an ephemeral volume (when running as a non-root user)?When storing the whole directory, the
devcontainer.json
's IDE-specificsettings
are not updated because they remain cached in the volume. The result is that updates tosettings
are not applied on container restart.At least this is what I observed.
I am having this exact issue also, I can update the extensions array but that does not do anything. Is there any way to clear all of this cache manually so when I edit the devcontainer, we get the desired output.
@georglauterbach -- can you elaborate on why it's not desirable to store the entire
~/.vscode-server
directory in an ephemeral volume (when running as a non-root user)?When storing the whole directory, the
devcontainer.json
's IDE-specificsettings
are not updated because they remain cached in the volume. The result is that updates tosettings
are not applied on container restart.At least this is what I observed.
I am having this exact issue also, I can update the extensions array but that does not do anything. Is there any way to clear all of this cache manually so when I edit the devcontainer, we get the desired output.
As I said in https://github.com/microsoft/vscode-remote-release/issues/7690#issuecomment-2261169813, mount the volume to ~/.vscode-server/extensions
, not to ~/.vscode-server
. This should install all cached extensions from the cache and new extensions from the internet.
For those using a combination of a Dockerfile
, compose
file, and devcontainer.json
, here is the solution. Thanks to this comment, I was able to get this combination working.
Dockerfile
# Assuming that you have `HOME`, `USERNAME` & `UID` ARG set.
USER root
RUN mkdir -p "${HOME}/.vscode-server" "${HOME}/.cache"; \
chown -R "${USERNAME}:${UID}" "${HOME}/.vscode-server" "${HOME}/.cache"
USER ${USERNAME}
compose.yaml
services:
<your-service>
environment:
- USERNAME=${USERNAME}
- GID=${GID}
# Other configurations
volumes:
- home-cache:/home/${USERNAME}/.cache:cached
- vscode-server-extensions:/home/${USERNAME}/.vscode-server/extensions:cached
env_file:
# USERNAME & GID should be in this file.
- ./.env
volumes:
home-cache:
vscode-server-extensions:
devcontainer.json
"service" : "<your-service>",
"dockerComposeFile" : ["path/to/your/compose.yaml"],
"containerUser": "$USERNAME",
"updateRemoteUserUID": true,
"customizations": {
"vscode": {
"extensions": [
"<your_extensions>"
]
}
},
In the meantime, I also found those settings
It's very annoying that we can't specify "all"
These are global defaults, though, and not specific to a project.
Indeed, there is currently no way to set this setting other than for the whole user
Does this issue occur when all extensions are disabled?: Does not apply
Steps to Reproduce:
.vscode-server/extensions
mount.What works:
.vscode-server/extensions
, create a volume for the whole.vscode-server
directory. This works, but I don't know if it won't break other things.