Skip to content

typescript-node:22 (at least) has wrong /tmp permissions #1556

Closed
Closed
typescript-node:22 (at least) has wrong /tmp permissions#1556
Assignees
v-Mathiyarasyv-Kaniska244

Description

@robynrox
robynrox
opened on Sep 18, 2025

Actual:

$ ls -ld /tmp
drwxr-xr-x. 1 root root 892 Sep 18 15:40 /tmp

Expected:

$ ls -ld /tmp
drwxrwxrwt. 1 root root 892 Sep 18 15:40 /tmp

It can be corrected at runtime with sudo chmod 1777 /tmp.

It causes an error when devcontainer.json features contains "ghcr.io/devcontainers/features/java:1": {"version": "21"} at least.

Activity

  1. Yokutto commented on Sep 18, 2025

    @Yokutto
    Natan (Yokutto)
    on Sep 18, 2025

    Hi,

    Can you give more details about your issue? I would like to know specifically what kind of container runtime are you on, if its docker or podman

    Thanks

  2. robynrox commented on Sep 18, 2025

    @robynrox
    robynrox
    on Sep 18, 2025
    Author

    Yes of course, this system is running podman on a Linux host. I have actually worked around the problem for my use case. Thanks

  3. Kaniska (v-Kaniska244)
    self-assigned this
    on Sep 22, 2025
  4. v-Mathiyarasy
    self-assigned this
    on Sep 23, 2025

  5. v-Kaniska244 commented on Sep 24, 2025

    @v-Kaniska244
    Kaniska (v-Kaniska244)
    on Sep 24, 2025
    Contributor

    Hello Natan (@Yokutto) , Hello robynrox ,

    In order to get better understanding on this, would you kindly let me know if you are encountering this issue while builing the container for the first time or during rebuild of the container?

  6. Yokutto commented on Sep 24, 2025

    @Yokutto
    Natan (Yokutto)
    on Sep 24, 2025

    Hi @Kaniska244,

    This happens in all cases for me: building for the first time, rebuilding, and rebuilding without cache. It only works for devcontainers that I created more than a month ago (which maybe used a less recent podman version)

    I really appreciate you taking the time to deal with this. While I would love to see a "workaround fix" in this project for the recent changes made by Podman to the /tmp folders, I still think this isn’t an issue with devcontainers at all

    If you are willing to continue debugging this, can we create a unified issue/thread related to it, so we can close duplicates?

    Thanks!

  7. robynrox commented on Sep 24, 2025

    @robynrox
    robynrox
    on Sep 24, 2025
    Author

    Dear @Kaniska244, for me it is not happening any more. I tested first-time build and rebuild.

    I don't remember updating anything and my uptime is 16 days but I think I must have run an update. I don't see what other explanation there could be. Actually I remember podman desktop complaining that there were two versions of podman on my system so I uninstalled podman desktop using bazaar recently which is most likely the relevant change.

    I'm happy to run anything to check the version. The version of podman I am running is v5.6.0 and it's in /usr/sbin which I think is one of my immutable directories. There's some stuff about /tmp changes in https://github.com/containers/podman/releases so it seems likely to me to be an issue there. I can try reinstalling podman desktop to see if I can repro?

  8. v-Kaniska244 commented on Sep 26, 2025

    @v-Kaniska244
    Kaniska (v-Kaniska244)
    on Sep 26, 2025
    Contributor

    Hello robynrox , Hello Natan (@Yokutto) ,

    Thank you for your patience. PFB the details of my investigation so far.

    Summary
    This issue is caused by a recent buildah change that forces mount target directory permissions to 700, which breaks certain workflows when using the latest podman (5.6.0 / 5.6.1).

    Root Cause

    • Change introduced in buildah PR #6233; shipped starting with buildah v1.41.0.
    • Current podman releases bundle this affected version of buildah, so the permission tightening propagates.
    • Simply installing a different standalone buildah does not help because podman has a hard dependency on (and vendors/aligns with) a specific buildah version.

    Upstream Status

    • Tracked in podman issue: containers/podman#27131.
    • A fix has been merged in buildah PR #6381; it is expected in an upcoming buildah release (likely 1.41.5 or later), and then will need to be incorporated into a subsequent podman release.

    Current Workaround (Recommended)

    Downgrade to podman ≤ 5.5.2 until a patched release is published.
    High‑level steps (example for macOS arm64 remote client):

    1. Stop any running podman processes / machines:
      • podman machine stop (if applicable)
      • Quit related background services.
    2. Download an older release (e.g. 5.5.2) from the tags page:
    3. Replace the existing podman binary with the older one (ensure it’s on your PATH).
    4. Clean up and recreate the machine if needed: podman machine rm -f then podman machine init && podman machine start.
    5. Verify version: podman --version.

    (If you use Podman Desktop: it must already be installed and pinned/bundled to a compatible older CLI; otherwise Desktop may not function correctly with the downgraded binary.)

    Not Recommended Right Now

    • Building podman from source solely to pick up the buildah fix—this is time‑consuming and offers little benefit versus waiting for the official release.
    • Attempting to “manually” swap just buildah; podman will still invoke the version it aligns with.

    Next Steps
    We’ll explore whether a temporary mitigation is feasible within the dev container CLI, but for now the downgrade path above is the practical solution until the fixed buildah propagates into an official podman release.

    Action
    Use podman 5.5.2 (or earlier) for affected workflows until a new podman build including the buildah fix is released.

    P.S. - I tried the same with 5.6.1 and 5.6.0 where it failed for me and then tried with 5.5.2 when dev container was successfully created. Attaching logs for reference.

    Podman-5.5.2.rtf

    Podman-5.6.1.rtf

  9. Natan (Yokutto)
    marked Terraform:1 - Permission denied on /tmp when using universal image features#1483 as a duplicate of this issue on Sep 29, 2025

  10. limwa commented on Nov 12, 2025

    @limwa
    André Lima (limwa)
    on Nov 12, 2025

    I think this is still happening in Podman 5.7.0 (which ships with Buildah 1.42.0, the first version to include podman-container-tools/buildah#6381).

    The permissions are still 755 instead of 1777. I'll try to find an existing issue for this in the buildah repository.

  11. riker09 commented on Mar 10, 2026

    @riker09
    Volker Thiel (riker09)
    on Mar 10, 2026

    This is still happening with Podman v5.7.1 as well.

  12. cbernard-rm25 commented on Apr 26, 2026

    @cbernard-rm25
    Christian Bernard (cbernard-rm25)
    on Apr 26, 2026

    Still occurring with Podman v5.8.1.

  13. cbernard-rm25 commented on Apr 27, 2026

    @cbernard-rm25
    Christian Bernard (cbernard-rm25)
    on Apr 27, 2026

    Hello @robynrox , Hello @Yokutto ,

    Thank you for your patience. PFB the details of my investigation so far.

    Summary This issue is caused by a recent buildah change that forces mount target directory permissions to 700, which breaks certain workflows when using the latest podman (5.6.0 / 5.6.1).

    Root Cause

    • Change introduced in buildah PR #6233; shipped starting with buildah v1.41.0.
    • Current podman releases bundle this affected version of buildah, so the permission tightening propagates.
    • Simply installing a different standalone buildah does not help because podman has a hard dependency on (and vendors/aligns with) a specific buildah version.

    Upstream Status

    • Tracked in podman issue: containers/podman#27131.
    • A fix has been merged in buildah PR #6381; it is expected in an upcoming buildah release (likely 1.41.5 or later), and then will need to be incorporated into a subsequent podman release.

    Current Workaround (Recommended)

    Downgrade to podman ≤ 5.5.2 until a patched release is published. High‑level steps (example for macOS arm64 remote client):

    1. Stop any running podman processes / machines:

      • podman machine stop (if applicable)
      • Quit related background services.

    2. Download an older release (e.g. 5.5.2) from the tags page:

    3. Replace the existing podman binary with the older one (ensure it’s on your PATH).

    4. Clean up and recreate the machine if needed: podman machine rm -f then podman machine init && podman machine start.

    5. Verify version: podman --version.

    (If you use Podman Desktop: it must already be installed and pinned/bundled to a compatible older CLI; otherwise Desktop may not function correctly with the downgraded binary.)

    Not Recommended Right Now

    • Building podman from source solely to pick up the buildah fix—this is time‑consuming and offers little benefit versus waiting for the official release.
    • Attempting to “manually” swap just buildah; podman will still invoke the version it aligns with.

    Next Steps We’ll explore whether a temporary mitigation is feasible within the dev container CLI, but for now the downgrade path above is the practical solution until the fixed buildah propagates into an official podman release.

    Action Use podman 5.5.2 (or earlier) for affected workflows until a new podman build including the buildah fix is released.

    P.S. - I tried the same with 5.6.1 and 5.6.0 where it failed for me and then tried with 5.5.2 when dev container was successfully created. Attaching logs for reference.

    Podman-5.5.2.rtf

    Podman-5.6.1.rtf

    This is super helpful and saved me from pulling out my hair. Really a bummer newer versions of podman are basically unusable for devcontainers that use git or the github cli.

  14. v-Kaniska244 commented on Sep 16, 2026

    @v-Kaniska244
    Kaniska (v-Kaniska244)
    on Sep 16, 2026
    Contributor

    This should be resolved with latest podman - 6.1.0. Kindly check and get back if the issue persists.

  15. Kaniska (v-Kaniska244)
    closed this as completedon Sep 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions