When the container is running with a non-root user, does not have a UID of 1000, and is not named vscode, node, or codespace, the install script fails to set correct permissions on the node installation.
For example, say you're using Docker for mac and the container is running a user called app with a UID of 501. The node installation will proceed as root, which results in a dev container with a broken node installation (for the app user).
The code in question is seen here:
|
if [ "${USERNAME}" = "auto" ] || [ "${USERNAME}" = "automatic" ]; then |
|
USERNAME="" |
|
POSSIBLE_USERS=("vscode" "node" "codespace" "$(awk -v val=1000 -F ":" '$3==val{print $1}' /etc/passwd)") |
|
for CURRENT_USER in "${POSSIBLE_USERS[@]}"; do |
|
if id -u ${CURRENT_USER} > /dev/null 2>&1; then |
|
USERNAME=${CURRENT_USER} |
|
break |
|
fi |
|
done |
|
if [ "${USERNAME}" = "" ]; then |
|
USERNAME=root |
|
fi |
|
elif [ "${USERNAME}" = "none" ] || ! id -u ${USERNAME} > /dev/null 2>&1; then |
|
USERNAME=root |
|
fi |
A workaround is to set username in the feature options, which is undocumented:
"features": {
"ghcr.io/devcontainers/features/node:1": {
"version": "18",
"username": "app"
}
}There is a _DEV_CONTAINERS_IMAGE_USER build arg passed to Dockerfile-with-features. If this build arg could be set as an environment variable when the feature install.sh is run, it could be used to determine the correct user without the "automatic" behavior that is currently used. This approach would require some changes outside of the install script itself (devcontainer cli?).
When the container is running with a non-root user, does not have a UID of
1000, and is not namedvscode,node, orcodespace, the install script fails to set correct permissions on the node installation.For example, say you're using Docker for mac and the container is running a user called
appwith a UID of501. The node installation will proceed as root, which results in a dev container with a broken node installation (for theappuser).The code in question is seen here:
features/src/node/install.sh
Lines 38 to 52 in 188f1ef
A workaround is to set
usernamein the feature options, which is undocumented:There is a
_DEV_CONTAINERS_IMAGE_USERbuild arg passed to Dockerfile-with-features. If this build arg could be set as an environment variable when the feature install.sh is run, it could be used to determine the correct user without the "automatic" behavior that is currently used. This approach would require some changes outside of the install script itself (devcontainer cli?).