Podman: .vscode-server directory creation in wrong place when remoteUser is defined

[branic]

• VSCode Version: 1.53.0
• Local OS Version: Fedora 33
• Remote OS Version: Python 3 container
• Remote Extension/Connection Type: SSH/Docker/WSL: Podman (version 2.2.1)
• Remote Containers Version: 0.158.0

Steps to Reproduce:

1. Clone project and add development container files (I used the Python 3 environment type)
2. Ensure a "remoteUser" is defined in the devcontainer.json file (I left it at the default of "vscode")
3. Rebuild and reopen the project in container

When the container runs it tests for the existence of and then tries to create the .vscode-server in the root users directory (i.e. /root/.vscode-server) instead of in the directory home directory of the remoteUser (i.e. vscode)

[TRUNCATED]
[2021-02-08T22:24:16.878Z] [PID 35757] [2114 ms] Start: Run in container: uname -m
[2021-02-08T22:24:17.017Z] [PID 35757] [2253 ms] x86_64
[2021-02-08T22:24:17.017Z] [PID 35757] [2253 ms] 
[2021-02-08T22:24:17.017Z] [PID 35757] [2253 ms] Start: Run in container: (cat /etc/os-release || cat /usr/lib/os-release) 2>/dev/null
[2021-02-08T22:24:17.019Z] [PID 35757] [2255 ms] PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
[2021-02-08T22:24:17.020Z] [PID 35757] [2256 ms] 
[2021-02-08T22:24:17.020Z] [PID 35757] [2256 ms] Start: Run in container: cat /etc/passwd
[2021-02-08T22:24:17.022Z] [PID 35757] [2258 ms] Start: Updating configuration state
[2021-02-08T22:24:17.024Z] [PID 35757] [2260 ms] Start: Setup shutdown monitor
[2021-02-08T22:24:17.025Z] [PID 35757] [2261 ms] Forking shutdown monitor: /home/bevans/.vscode/extensions/ms-vscode-remote.remote-containers-0.158.0/dist/shutdownMonitorProcess /run/user/4400/vscode-remote-containers-8df5c00fb5f95cd5a12ff80b44893507117f10a9.sock singleContainer Info /home/bevans/.config/Code/logs/20210208T112310/exthost7/ms-vscode-remote.remote-containers 1612823054764
[2021-02-08T22:24:17.030Z] [PID 35757] [2266 ms] Start: Run in container: test -d /root/.vscode-server
[2021-02-08T22:24:17.031Z] [PID 35757] [2267 ms] 
[2021-02-08T22:24:17.031Z] [PID 35757] [2267 ms] 
[2021-02-08T22:24:17.031Z] [PID 35757] [2267 ms] Exit code 1
[2021-02-08T22:24:17.031Z] [PID 35757] [2267 ms] Start: Run in container: test -d /root/.vscode-remote
[2021-02-08T22:24:17.032Z] [PID 35757] [2268 ms] 
[2021-02-08T22:24:17.032Z] [PID 35757] [2268 ms] 
[2021-02-08T22:24:17.032Z] [PID 35757] [2268 ms] Exit code 1
[2021-02-08T22:24:17.032Z] [PID 35757] [2268 ms] Start: Run in container: set -o noclobber ; mkdir -p '/root/.vscode-server/data/Machine' && { > '/root/.vscode-server/data/Machine/.writeMachineSettingsMarker' ; } 2> /dev/null
[2021-02-08T22:24:17.036Z] [PID 35757] [2272 ms] 
[2021-02-08T22:24:17.036Z] [PID 35757] [2272 ms] mkdir: cannot create directory ‘/root’: Permission denied
[2021-02-08T22:24:17.036Z] [PID 35757] [2272 ms] Exit code 1
[2021-02-08T22:24:17.036Z] [PID 35757] [2272 ms] Start: Run in container: cat /root/.vscode-server/data/Machine/settings.json
[2021-02-08T22:24:17.039Z] [PID 35757] [2275 ms] 
[2021-02-08T22:24:17.039Z] [PID 35757] [2275 ms] cat: /root/.vscode-server/data/Machine/settings.json: Permission denied
[2021-02-08T22:24:17.039Z] [PID 35757] [2275 ms] Exit code 1
[2021-02-08T22:24:17.039Z] [PID 35757] [2275 ms] Start: Run in container: test -d /root/.vscode-server/bin/8490d3dde47c57ba65ec40dd192d014fd2113496
[2021-02-08T22:24:17.040Z] [PID 35757] [2276 ms] 
[2021-02-08T22:24:17.040Z] [PID 35757] [2276 ms] 
[2021-02-08T22:24:17.040Z] [PID 35757] [2276 ms] Exit code 1
[2021-02-08T22:24:17.040Z] [PID 35757] [2276 ms] Start: Run in container: test -d /vscode/vscode-server/bin/x64/8490d3dde47c57ba65ec40dd192d014fd2113496
[2021-02-08T22:24:17.040Z] [PID 35757] [2276 ms] 
[2021-02-08T22:24:17.040Z] [PID 35757] [2276 ms] 
[2021-02-08T22:24:17.040Z] [PID 35757] [2276 ms] Start: Run in container: mkdir -p '/root/.vscode-server/bin' && ln -s '/vscode/vscode-server/bin/x64/8490d3dde47c57ba65ec40dd192d014fd2113496' '/root/.vscode-server/bin/8490d3dde47c57ba65ec40dd192d014fd2113496'
[2021-02-08T22:24:17.043Z] [PID 35757] [2279 ms] 
[2021-02-08T22:24:17.044Z] [PID 35757] [2280 ms] mkdir: cannot create directory ‘/root’: Permission denied
[2021-02-08T22:24:17.044Z] [PID 35757] [2280 ms] Exit code 1
[2021-02-08T22:24:17.047Z] [PID 35757] [2283 ms] Command in container failed: mkdir -p '/root/.vscode-server/bin' && ln -s '/vscode/vscode-server/bin/x64/8490d3dde47c57ba65ec40dd192d014fd2113496' '/root/.vscode-server/bin/8490d3dde47c57ba65ec40dd192d014fd2113496'

devcontainer.json

// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.158.0/containers/python-3
{
	"name": "Python 3",
	"build": {
		"dockerfile": "Dockerfile",
		"context": "..",
		"args": { 
			// Update 'VARIANT' to pick a Python version: 3, 3.6, 3.7, 3.8, 3.9
			"VARIANT": "3",
			// Options
			"INSTALL_NODE": "false",
			"NODE_VERSION": "lts/*"
		}
	},

	// Set *default* container specific settings.json values on container create.
	"settings": { 
		"terminal.integrated.shell.linux": "/bin/bash",
		"python.pythonPath": "/usr/local/bin/python",
		"python.linting.enabled": true,
		"python.linting.pylintEnabled": true,
		"python.formatting.autopep8Path": "/usr/local/py-utils/bin/autopep8",
		"python.formatting.blackPath": "/usr/local/py-utils/bin/black",
		"python.formatting.yapfPath": "/usr/local/py-utils/bin/yapf",
		"python.linting.banditPath": "/usr/local/py-utils/bin/bandit",
		"python.linting.flake8Path": "/usr/local/py-utils/bin/flake8",
		"python.linting.mypyPath": "/usr/local/py-utils/bin/mypy",
		"python.linting.pycodestylePath": "/usr/local/py-utils/bin/pycodestyle",
		"python.linting.pydocstylePath": "/usr/local/py-utils/bin/pydocstyle",
		"python.linting.pylintPath": "/usr/local/py-utils/bin/pylint"
	},

	// Add the IDs of extensions you want installed when the container is created.
	"extensions": [
		"ms-python.python"
	],

	// Use 'forwardPorts' to make a list of ports inside the container available locally.
	// "forwardPorts": [],

	// Use 'postCreateCommand' to run commands after the container is created.
	// "postCreateCommand": "pip3 install --user -r requirements.txt",

	// Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
	"remoteUser": "vscode"
}

NOTE: If I comment out the remoteUser variable in the devcontainer.json so that the container uses the root user, opening the project in the container is successful.

Does this issue occur when you try this locally?: No Does this issue occur when you try this locally and all extensions are disabled?: No

[chrmarti]

Does the vscode user have a home folder specified in /etc/passwd?

[tepene]

I have the same issue under Ubuntu 20.04 with podman 3.0 with the ubuntu and the node container.

Here the truncated output of /etc/passwd

$ cat /etc/passwd
...
vscode:x:1000:1000::/home/vscode:/bin/bash

VSCode Version: 1.53.2 Local OS Version: Ubuntu 20.04 Remote OS Version: Ubuntu container (and node container as well) Remote Container Extension: v0.158.0 Podman Version: 3.0.0

[branic]

The vscode user does have an entry in /etc/passwd:

vscode:x:4400:4400::/home/vscode:/bin/bash

The home directory for the vscode user has also been created:

root ➜ / $ ls -al /home/
total 12
drwxr-xr-x  3 root   root   4096 Feb 15 14:40 .
dr-xr-xr-x 23 root   root   4096 Feb 15 14:44 ..
drwxr-xr-x  4 vscode vscode 4096 Feb 15 14:40 vscode
root ➜ / $ ls -al /home/vscode
total 32
drwxr-xr-x  4 vscode vscode 4096 Feb 15 14:40 .
drwxr-xr-x  3 root   root   4096 Feb 15 14:40 ..
-rw-r--r--  1 vscode vscode  220 Apr 18  2019 .bash_logout
-rw-r--r--  1 vscode vscode 3402 Feb  1 18:05 .bashrc
drwxr-xr-x 15 vscode vscode 4096 Feb 15 14:40 .oh-my-bash
drwxr-xr-x 12 vscode vscode 4096 Feb 15 14:40 .oh-my-zsh
-rw-r--r--  1 vscode vscode  807 Apr 18  2019 .profile
-rw-r--r--  1 vscode vscode 3713 Feb  1 18:05 .zshrc

[branic]

The logfile for rebuilding the remote container contains the line:

Start: Run: podman build -f /tmp/vsch/updateUID.Dockerfile-0.158.0 -t vsc-<XXXX>-6b90a6b25fcf980178bfcceafb62a3c5-uid --build-arg BASE_IMAGE=vsc-<XXXX>-6b90a6b25fcf980178bfcceafb62a3c5 --build-arg REMOTE_USER=vscode --build-arg NEW_UID=4400 --build-arg NEW_GID=4400 --build-arg IMAGE_USER=root /tmp/vsch

Looking that the /tmp/vsch/updateUID.Dockerfile-0.158.0 that is used in the that step reveals that the last step is to set the user to $IMAGE_USER which as can be seen above is set to root.

cat /tmp/vsch/updateUID.Dockerfile-0.158.0
ARG BASE_IMAGE
FROM $BASE_IMAGE

USER root

ARG REMOTE_USER
ARG NEW_UID
ARG NEW_GID
RUN /bin/sh -c ' \
	eval $(sed -n "s/${REMOTE_USER}:[^:]*:\([^:]*\):\([^:]*\):[^:]*:\([^:]*\).*/OLD_UID=\1;OLD_GID=\2;HOME_FOLDER=\3/p" /etc/passwd); \
	eval $(sed -n "s/\([^:]*\):[^:]*:${NEW_UID}:.*/EXISTING_USER=\1/p" /etc/passwd); \
	eval $(sed -n "s/\([^:]*\):[^:]*:${NEW_GID}:.*/EXISTING_GROUP=\1/p" /etc/group); \
	if [ -z "$OLD_UID" ]; then \
		echo "Remote user not found in /etc/passwd ($REMOTE_USER)."; \
	elif [ "$OLD_UID" = "$NEW_UID" -a "$OLD_GID" = "$NEW_GID" ]; then \
		echo "UIDs and GIDs are the same ($NEW_UID:$NEW_GID)."; \
	elif [ "$OLD_UID" != "$NEW_UID" -a -n "$EXISTING_USER" ]; then \
		echo "User with UID exists ($EXISTING_USER=$NEW_UID)."; \
	elif [ "$OLD_GID" != "$NEW_GID" -a -n "$EXISTING_GROUP" ]; then \
		echo "Group with GID exists ($EXISTING_GROUP=$NEW_GID)."; \
	else \
		echo "Updating UID:GID from $OLD_UID:$OLD_GID to $NEW_UID:$NEW_GID."; \
		sed -i -e "s/\(${REMOTE_USER}:[^:]*:\)[^:]*:[^:]*/\1${NEW_UID}:${NEW_GID}/" /etc/passwd; \
		if [ "$OLD_GID" != "$NEW_GID" ]; then \
			sed -i -e "s/\([^:]*:[^:]*:\)${OLD_GID}:/\1${NEW_GID}:/" /etc/group; \
		fi; \
		chown -R $NEW_UID:$NEW_GID $HOME_FOLDER; \
	fi; \
	'

ARG IMAGE_USER
USER $IMAGE_USER

So it looks like either the IMAGE_USER variable should be set to vscode in the podman build step or the Dockerfile should use the REMOTE_USER variable in the last user statement.

[tepene]

When I set the IMAGE_USER to vscode in the Dockerfile with ENV IMAGE_USER vscode the container can be started but the permissions in vscode home directory are wrong. User / Group root is now the owner for all files and folders

vscode ➜ /workspaces/ansible-dev $ ls -all
total 80
drwxrwxr-x 6 root root  4096 Feb 14 17:45 .
drwxr-xr-t 5 root root  4096 Feb 15 18:39 ..
-rw-r--r-- 1 root root    82 Feb 12 10:53 ansible.cfg
drwxrwxr-x 3 root root  4096 Feb 12 10:22 .devcontainer
drwxrwxr-x 8 root root  4096 Feb 15 18:16 .git
-rw-rw-r-- 1 root root   766 Feb 12 09:33 .gitmessage
drwxr-xr-x 2 root root  4096 Feb 12 09:24 group_vars
drwxr-xr-x 2 root root  4096 Feb 12 09:24 host_vars
-rw-r--r-- 1 root root   361 Feb 12 10:52 inventory
-rw-r--r-- 1 root root 36803 Feb 12 09:19 poetry.lock
-rw-r--r-- 1 root root   390 Feb 12 10:21 pyproject.toml
-rw-r--r-- 1 root root   113 Feb 12 10:25 README.md

[chrmarti]

Podman now sets HOME to the container user's home folder. Try setting "containerUser" instead of "remoteUser".

On the updateUID.Dockerfile: The goal there is to preserve the original user, so we minimally interfere with the existing image.

Marking as upstream.

[tepene]

With "containerUser": "vscode" in the devcontainer.json file the container starts. But I still have the issue with the wrong permission set to root:root instead of vscode:vscode.

vscode ➜ /workspaces/ansible-dev $ ls -all
total 80
drwxrwxr-x 6 root root  4096 Feb 14 17:45 .
drwxr-xr-t 5 root root  4096 Feb 18 10:21 ..
-rw-r--r-- 1 root root    82 Feb 12 10:53 ansible.cfg
drwxrwxr-x 3 root root  4096 Feb 18 10:17 .devcontainer
drwxrwxr-x 8 root root  4096 Feb 18 10:15 .git
-rw-rw-r-- 1 root root   766 Feb 12 09:33 .gitmessage
drwxr-xr-x 2 root root  4096 Feb 12 09:24 group_vars
drwxr-xr-x 2 root root  4096 Feb 12 09:24 host_vars
-rw-r--r-- 1 root root   361 Feb 12 10:52 inventory
-rw-r--r-- 1 root root 36803 Feb 12 09:19 poetry.lock
-rw-r--r-- 1 root root   390 Feb 12 10:21 pyproject.toml
-rw-r--r-- 1 root root   113 Feb 12 10:25 README.md

[chrmarti]

I see that with Podman 2.1.1 too. The files have the user as owner on the host side, but root inside the container. This must be a Podman feature.

[tepene]

Maybe the container has to be launched with --userns=keep-id.

"We do recognize that this doesn't really match how many people intend to use rootless Podman - they want their UID inside and outside the container to match. Thus, we provide the --userns=keep-id flag, which ensures that your user is mapped to its own UID and GID inside the container." Source: https://github.com/containers/podman/blob/master/docs/tutorials/rootless_tutorial.md#using-volumes

[chrmarti]

You can add arguments to the podman run command using "runArgs" in the devcontainer.json.

[tepene]

et voilà ! That did the trick.

Added the two lines to the devcontainer.json

"runArgs": ["--userns=keep-id"],
"containerUser": "vscode"

Now the permissions are as expected:

vscode ➜ /workspaces/ansible-dev $ ls -all
total 80
drwxrwxr-x 6 vscode vscode  4096 Feb 18 11:33 .
drwxr-xr-t 5 root   root    4096 Feb 18 11:40 ..
-rw-r--r-- 1 vscode vscode    82 Feb 12 10:53 ansible.cfg
drwxrwxr-x 3 vscode vscode  4096 Feb 18 10:29 .devcontainer
drwxrwxr-x 8 vscode vscode  4096 Feb 18 11:40 .git
-rw-rw-r-- 1 vscode vscode   766 Feb 12 09:33 .gitmessage
drwxr-xr-x 2 vscode vscode  4096 Feb 12 09:24 group_vars
drwxr-xr-x 2 vscode vscode  4096 Feb 12 09:24 host_vars
-rw-r--r-- 1 vscode vscode   361 Feb 12 10:52 inventory
-rw-r--r-- 1 vscode vscode 36803 Feb 12 09:19 poetry.lock
-rw-r--r-- 1 vscode vscode   390 Feb 12 10:21 pyproject.toml
-rw-r--r-- 1 vscode vscode   113 Feb 12 10:25 README.md

Minor pitfall, the runArgs argument makes the container incompatible with a system which runs the devcontainer with docker. Launching the container with docker fails with the error docker: --userns: invalid USER mode.

[branic]

I just had a chance to test this as well and adding the two lines that @tepene listed works for me too.

[mhazhary]

Come from #5738, and use @tepene solutions. I confirm that didn't work for me. I can't even do ls, even sudo ls in the project directory. For a note, I use node development container (16-bullseye) from Microsoft.

[rapgenic]

adding also "--privileged" to the runArgs seems to have fixed the problem for me.

[bytzo]

~~Would it be possible to automatically pass the --userns=keep-id flag if Podman is detected? Currently it is not possible to have a devcontainer.json file that works with both Docker and Podman (when the container user is non-root) since Docker fails with the --userns=keep-id flag.~~

Running Podman with PODMAN_USERNS=keep-id works the same as the --userns=keep-id and avoids Docker failing. While this is one way to support Podman in a devcontainer.json configuration, other solutions may need to be considered. See https://github.com/microsoft/vscode-remote-release/issues/4443#issuecomment-1013563654.

[EirikFA]

I had success using the following settings in devcontainer.json (in addition to "remoteUser": "node", which was already specified) with the 16-bullseye image:

"runArgs": [
  "--userns=keep-id"
],
"containerUser": "node",
"containerEnv": {
  "HOME": "/home/node"
}

[tepene]

@EirikFA At least in my case your config snippet works with podman but fails with docker. Docker does not support --userns=keep-id

[tcitworld]

How would I use this in docker-compose mode, which can't use runArgs?

[tesuvant]

@bytzo would this work for you?

$ tail -1 /etc/containers/containers.conf
env=["BUILDAH_FORMAT=docker", "PODMAN_USERNS=keep-id"]

[bytzo]

@bytzo would this work for you?

$ tail -1 /etc/containers/containers.conf
env=["BUILDAH_FORMAT=docker", "PODMAN_USERNS=keep-id"]

Using the PODMAN_USERNS variable seems to have the same effect as the --userns flag, in addition to not causing Docker to fail! Thanks for pointing this out, I wasn't aware of the option.

However, this makes me wonder how Podman support would make sense with the Remote - Containers extension. Since Podman is rootless by default, many devcontainer.json configurations meant for Docker do not work without changes (such as the default ones, see #2881). In addition to this, there is no easy way to identify which container engines a configuration is compatible with, so unexpected errors caused by using the wrong container engine may be confusing to people unfamiliar with a project. Does it make sense for the extension to automatically account for differences between different container engines? Or should devcontainer.json configurations specify compatible container engines, allowing the extension to select the correct one if installed on the system? There are many ways to go about this, however improving support for container engines other than Docker to fix issues such as this one may be outside of the scope of this issue. Shall discussion around this be taken elsewhere?

[chrmarti]

Looking into this I found that the rewriting of UID and GID (configured with "updateRemoteUserUID" which is on by default) of the container user to match those of the host user is part of what makes --userns=keep-id getting the dev container to work. When the container user does not have the same UID and GID as the host user --userns=keep-id adds an entry in /etc/passwd for the host user with it original name and UID which is not what we want in this case.

Another note is that "remoteUser" (used by the devcontainer.jsons we add to projects) can be used when "HOME" is set because Remote-Containers gives that precedence over the home folder it finds in /etc/passwd for the user:

	"containerEnv": {
		"HOME": "/home/node"
	},

So one possible way of improving this could be to add --userns=keep-id and ignore the HOME env variable when detecting Podman in the Remote-Containers extension.

[heksesang]

Wouldn't an easy fix to make this work with both podman and docker (or any other engine) be to just add the ability to set separate overrides for docker and podman in the devcontainer.json?

{
  "engineOverrides": {
    "docker": {
      "remoteUser": "vscode"
    },
    "podman": {
      "remoteUser": "root"
    }
}

[keestux]

Where can I find the Git repo of remote-containers?

[leeroya]

containerUser

This did work for my use case, thank you @chrmarti. All I needed to do on my Mac was to set: "containerUser": "vscode" in the devcontainer.json

[crispyricepc]

@bytzo would this work for you?

$ tail -1 /etc/containers/containers.conf
env=["BUILDAH_FORMAT=docker", "PODMAN_USERNS=keep-id"]

Where exactly does this need to go? I can get it to work with the flag --userns=keep-id but can't when trying to set the environment variables in this config file

[lbssousa]

I was able to make Dev Containers work transparenlty with Podman (no need to set "runArgs" in devcontainers.json) by providing the following settings under ${HOME}/.config/containers/containers.conf:

[containers]
env = ["BUILDAH_FORMAT=docker"] # Is this really needed?
label = false
userns = "keep-id"

[p-hash]

Just wanted to highlight that setting "containerUser": "vscode" does not help when I try to attach VS Code to existing running container. My user in container stays root. When I set "remoteUser": "vscode" it tries to write to /root and fails.

Let me explain my use case for that. I run Fedora Silverblue. VS Code is installed as flatpak and I want it to connect to existing toolbox container.

• VSCode Version: 1.75.0
• Local OS Version: Fedora Linux 37.20230313.0 (Silverblue)
• Remote OS Version: registry.fedoraproject.org/fedora-toolbox:37
• Remote Extension/Connection Type: SSH/Docker/WSL: Podman (version 4.4.2)
• Remote Containers Version: 0.282.0

[dennybaa]

Same thing I use flatpaked vscode and podman-remote (rootless configuration). Setting "remoteUser": "myuser" is required to exec into the toolbox container as a non-privileged user, while at the same time it's still perfectly possible to do so as root. The later of course it's not what we want.

Vscode sets the user and its permissions correctly to this "myuser" (Say it we make /root writable). But why on earth the extension in such a configuration tries to install and place vscode-server related stuff under /root ?

Btw the bellow settings seem to be relevant to container initialization, setting this in imageConfigs or nameConfigs give no benefits.

"runArgs": [
  "--userns=keep-id"
],
"containerEnv": {
  "HOME": "/home/node"
}

Talking about toolbox containers, they are already initialized with --userns keep-id. So I tried both containerEnv and remoteEnv, they have no effect on an initialized container. Setting HOME is an ugly workaround, because as I mentioned we can can exec into containers under different users... So the workarounds and docs in microsoft/vs do not solve the issue, just mitigate a corner case. Attaching to a properly initialized "rootless" container doesn't work yet unfortunately.

@chrmarti Could you please reveal light if it's an expected behavior.

[nathancarter]

None of the tricks above worked for me. Running podman on an M1 Mac, using Microsoft Node 20-bullseye container. I've tried every subset of the above settings I can think of, but continue to get this error upon an attempt to start the container:

mkdir: cannot create directory '/root': Permission denied
Command in container failed: mkdir -p '/root/.vscode-server/bin' && ln -snf '/vscode/vscode-server/bin/linux-arm64/e7e037083ff4455cf320e344325dacb480062c3c' '/root/.vscode-server/bin/e7e037083ff4455cf320e344325dacb480062c3c'

To be specific, I've heard recommendations for all of these settings:

	"runArgs": [ "--userns=keep-id", "--privileged" ],
	"containerUser": "node",
	"containerEnv": { "HOME": "/home/node" },
	"remoteUser": "node"

I've tried with just some of them in various configurations, but with no success.

[lachlancresswell]

None of the tricks above worked for me. Running podman on an M1 Mac, using Microsoft Node 20-bullseye container. I've tried every subset of the above settings I can think of, but continue to get this error upon an attempt to start the container:

mkdir: cannot create directory '/root': Permission denied
Command in container failed: mkdir -p '/root/.vscode-server/bin' && ln -snf '/vscode/vscode-server/bin/linux-arm64/e7e037083ff4455cf320e344325dacb480062c3c' '/root/.vscode-server/bin/e7e037083ff4455cf320e344325dacb480062c3c'

To be specific, I've heard recommendations for all of these settings:

	"runArgs": [ "--userns=keep-id", "--privileged" ],
	"containerUser": "node",
	"containerEnv": { "HOME": "/home/node" },
	"remoteUser": "node"

I've tried with just some of them in various configurations, but with no success.

The following from here worked for me:

"runArgs": [
  "--userns=keep-id"
],
"containerEnv": {
  "HOME": "/home/node"
}