Repository navigation
ghcr.io/devcontainers/features/git:1 changes mode of /tmp to 755 causing "mkdir: cannot create directory ‘/tmp/.X11-unix’: Permission denied" #1480
Description
Adding feature ghcr.io/devcontainers/features/git:1 causes the mode of /tmp in the container to be changed to 0755.
This is my devcontainer.json
{
"name": "myproj",
"build": {
"dockerfile": "Dockerfile",
"context": ".."
},
"features": {
"ghcr.io/devcontainers/features/git:1": {}
}
}and this is the Dockerfile
ARG VARIANT="3.11"
FROM mcr.microsoft.com/vscode/devcontainers/python:0-${VARIANT}
RUN ls -la /tmp
It might also be important to mention that I'm using podman. I don't have docker at hand, so I don't know if that plays a role in this bug.
When I do a "Reopen in Container" in vscode I eventually get this error:
...
[1/3] STEP 1/2: FROM mcr.microsoft.com/vscode/devcontainers/python:0-3.11 AS dev_container_auto_added_stage_label
[1/3] STEP 2/2: RUN ls -la /tmp
total 0
drwxrwxrwt. 1 root root 36 Jun 8 2023 .
dr-xr-xr-x. 1 root root 24 Sep 13 19:23 ..
drwxr-xr-x. 1 root root 0 Jun 8 2023 build-features-src
drwxr-xr-x. 1 root root 66 Jun 8 2023 dev-container-features
--> 77f2db5530a2
...
[38726 ms] Start: Run in container: test -e /tmp/.X11-unix/X0
[38727 ms]
[38727 ms]
[38727 ms] Exit code 1
[38727 ms] Start: Run in container: mkdir -p '/tmp/.X11-unix'
[38729 ms]
[38729 ms] mkdir: cannot create directory ‘/tmp/.X11-unix’: Permission denied
[38730 ms] Exit code 1
[38733 ms] Command in container failed: mkdir -p '/tmp/.X11-unix'
[38733 ms] mkdir: cannot create directory ‘/tmp/.X11-unix’: Permission denied
[38734 ms] Exit code 1When this happens, before canceling, I can "exec" into the container from another terminal and look at /tmp in the container.
$ podman exec -t -i jovial_sutherland /bin/bash
root ➜ / $ ls -ld /tmp/
drwxr-xr-x. 1 root root 80 Sep 13 19:23 /tmp/Somewhere/somehow the mode of /tmp got changed.
If I drop the git feature the problem does not happen.
Metadata
Metadata
Assignees
Labels
No labels
Activity
v-Kaniska244 commentedon Sep 17, 2025
Hello Kees Bakker (@keestux) ,
Thank you for reporting this issue. I could see that you are using a very old dev container image as the base image for your dev container
mcr.microsoft.com/vscode/devcontainers/python:0-3.11. That could very well be the reason behind this issue with git feature you reported.Would you kindly use latest images such as
mcr.microsoft.com/vscode/devcontainers/python:2-3.11ormcr.microsoft.com/vscode/devcontainers/python:2-3.11-bullseyeand see if the issue persists?keestux commentedon Sep 17, 2025
Unfortunately that didn't make a difference.
I must say, debugging this problem is extremely difficult, at least for me it is.
v-Kaniska244 commentedon Sep 18, 2025
Hello Kees Bakker (@keestux),
Would you kindly share the complete log for this scenario with both
show container logandshow previous log options? That would be help us a great deal to investigate this further.Also you are using python pre-built dev container image which already includes the git feature in its dev container configuration. So you shouldn’t need to install it all over again.
keestux commentedon Sep 18, 2025
Hey @Kaniska244
I cannot (yet) show you any logging, but hold on.
What I have been doing since yesterday is to use
@devcontainers/clito go through multiple edit-build-test cycles. Instead of loading features from the web I copied a feature from thesrctree of this repo and placed it in a subdirectory of the.devcontainer. I worked my way through stripping theinstall.shof the "feature". The start situation is when the build container has a1777for/tmp. And finally ended up with aninstall.shthat led to a container with mode755for/tmp.What I now have is this:
The files are really small, here they are
With this setup I did:
npm install @devcontainers/clinpx devcontainer up --workspace-folder .npx devcontainer exec --workspace-folder . /bin/bash -c 'ls -ld /tmp/'The output of the last command is:
Next, delete all commands from
install.shto getRebuild the container (first cleanup the previous images and container). Run the
lsagain. I then getkeestux commentedon Sep 18, 2025
In the
install.sh, anything written to/tmpseems to be sufficient to avoid the755mode. This works too:keestux commentedon Sep 18, 2025
I can provide the output of the
npx devcontainer up --workspace-folder .. There is no difference between the good and bad case, except if theinstall.shwrites something to stdout.Let me know if you still want that log.
Yokutto commentedon Sep 18, 2025
Hi Kees Bakker (@keestux),
I'm digging about this issue with related issues that I found. I have noted that
podmanis a common factor between these issues, and specifically the podman above version5.5.0, can you please confirm if that is your case?Maybe this isn't related to podman at all, but I find pretty weird that this started happening to me in the latest versions of podman, specially since they changed
/tmpbehavior on 5.6.1 and 5.5.0keestux commentedon Sep 19, 2025
Yes, correct. I'm using podman version 5.6.1 (on Fedora 42)
Ah, interesting.
keestux commentedon Sep 21, 2025
Where can I find the source code of devcontainers? Where can I report (podman) issues for devcontainers?
v-Kaniska244 commentedon Sep 22, 2025
Hello Kees Bakker (@keestux) ,
I am checking on this.Will try to update by end of this week.
v-Kaniska244 commentedon Sep 29, 2025
Updated in devcontainers/images#1556 (comment)
NahsiN commentedon Mar 7, 2026
I'm running into a similar issue as OP. My devcontainer.json:
Using podman version 5.7.1, I end up with similar permission error logs
I've also seen a similar issue posted on reddit
kafumanto commentedon Mar 9, 2026
Hi! Thanks Kees Bakker (@keestux) for the great analysis!
The problem still persists today, with Podman 5.8.0 and VSCode 1.110.1.
In my case, the problem occurs when using the Debian 12 base image with the java feature (with only the Debian 12 base image it works):
{ "name": "Debian + Java 21", "image": "mcr.microsoft.com/devcontainers/base:debian-12", "features": { "ghcr.io/devcontainers/features/java:1": { "version": "21" } } }The workaround (for me, and for the java feature) is to force
/tmpto be a tmpfs with mode 1777:{ // ... "runArgs": [ "--tmpfs=/tmp:rw,exec,nosuid,nodev,mode=1777" ] }sineme commentedon Apr 15, 2026
I am using docker and also have issues with
/tmpdocker version
error log excerpt
I use
mcr.microsoft.com/devcontainers/base:2-trixieas the base of my devcontainer andI get the error when I add one of the following features in
devcontainer.json. If I remove them the build runs fineghcr.io/devcontainers/features/common-utils:2featuresused to work but I probably should've removed itghcr.io/rails/devcontainer/features/rubycommon-utilsghcr.io/devcontainers/features/git:1works fine howeverdevcontainer.json
Dockerfile
compose.yaml
georglauterbach commentedon Jul 12, 2026
I am hitting this issue too; it seems to be related to using
features. When I am not usingfeatures, it seems to work. Without having checked, I assume the devcontainer CLI adjusts/tmp/for Features in a way that causes privilege issues. If someone here is better at Typescript than I am, please quickly check https://github.com/devcontainers/cli to see whether something is being done with/tmp/.Mounting a
tmpfsas described in #1480 (comment) does indeed solve the issue for now, but I'd like to know what the actual culprit it so I don't have to supply suchrunArgsevery time.chore: enable using Podman for Dev Container
chore: enable using Podman for Dev Container