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

[robynrox]

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.

[Yokutto]

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

[robynrox]

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

[Kaniska244]

Hello @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?

[Yokutto]

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!

[robynrox]

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?

[Kaniska244]

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:
   • v5.5.2 release assets
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