`postCreateCommand` is never executed with `mcr.microsoft.com/devcontainers/base:ubuntu26.04`

[lucienshawls]

TL;DR
The problem wasn't with the image itself, but with the changes made to Ubuntu 26.04, and a series of coincidences.

Symptom

When using "image": "mcr.microsoft.com/devcontainers/base:ubuntu26.04", (or "image": "mcr.microsoft.com/devcontainers/base:ubuntu",) with postCreateCommand configured, the configured command does not run.

Reproduction

1. Create a new repository
2. Create a new folder named .devcontainer
3. Create a file named devcontainer.json in .devcontainer with:

{
    "name": "Test",
    "image": "mcr.microsoft.com/devcontainers/base:ubuntu26.04",
    "postCreateCommand": "bash .devcontainer/post-create.sh"
}

4. Create a file named post-create.sh in .devcontainer with:

#!/bin/bash

echo "Hello"
touch hello.txt
echo "done"

5. Reopen in container and Show container log
6. Verify that the post-create.sh never runs, and hello.txt is not there
7. Modify image in devcontainer.json:

{
    "name": "Test",
    "image": "mcr.microsoft.com/devcontainers/base:ubuntu24.04",
    "postCreateCommand": "bash .devcontainer/post-create.sh"
}

8. Rebuild container and Show container log
9. Verify that the post-create.sh successfully runs and hello.txt appears

[V-Subhankar-infy]

Hi Lucien Shaw (@lucienshawls), thanks for the detailed report!

I investigated this and the ubuntu26.04 (resolute) image itself is working correctly; postCreateCommand does execute on it. The behavior you're seeing is actually due to how Dev Container lifecycle commands work, not a difference between the two images.

What's happening

When you switched from ubuntu26.04 to ubuntu24.04, you likely used "Rebuild Container" (since a different image forces a rebuild). But when you first tried ubuntu26.04, you may have used "Reopen in Container" on an already-existing container. That's the key difference:

• Rebuild Container; destroys the old container, creates a new one; postCreateCommand runs
• Reopen in Container (when a container already exists); reuses it; postCreateCommand is skipped

How lifecycle commands work

Dev Containers has several lifecycle hooks that run at different stages:

Command	When it runs
initializeCommand	Every time, on the host, before anything else
onCreateCommand	Only once, when the container is first created
postCreateCommand	Only once, after onCreateCommand completes (first creation)
postStartCommand	Every time the container starts (including restarts/reopens)
postAttachCommand	Every time a tool (e.g. VS Code) attaches to the container

Since postCreateCommand is a one-time hook tied to container creation, it won't re-run on subsequent "Reopen in Container" actions.

What to do

• If you need a command to run only on first setup (e.g. installing dependencies): use postCreateCommand and make sure to Rebuild Container when you change it.
• If you need a command to run every time the container starts: use postStartCommand instead.
• If you need it every time you attach: use postAttachCommand.

To verify this for yourself: use ubuntu26.04 and run Dev Containers: Rebuild Container from the command palette; you'll see postCreateCommand execute as expected.

Based on the above information, apply the appropriate fix and retry the build and do let me know if it works or not.

[lucienshawls]

Thank you for your reply. But I am afraid that the problem is still not resolved on my side.

I tried to do the following:

1. I removed every container, image and volume on the machine (so there could be no "existing" devcontainers)
2. Enter the folder that contains only a .devcontainer folder with two files (devcontainer.json, post-create.sh), just like I said in the Reproduction part;
3. The image is now base:ubuntu26.04. I chose Reopen in container. I saw a new image was pulled and a new container was created, but the post-create.sh never ran.
4. I changed the image to base:ubuntu24.04. VS Code sent me a notification in the bottom right corner, and I clicked "Rebuild". Another container was created and post-create.sh ran successfully.
5. (Important) I removed the newly created file hello.txt, changed the image back to base:ubuntu26.04, clicked Rebuild button in the notification. The container was rebuilt, but post-create.sh did not run.
6. I repeated steps 4 and 5, chose Rebuild all the time, but the results remained the same: with base:ubuntu24.04, the command could run; with base:ubuntu26.04, the command could not run.

I am sure that I chose Rebuild and even Rebuild without cache, but it did not work. I tired 20.04, 22.04, they all function normally. 26.04 was the only image that failed. Is there a misconfiguration? Please help me.

BTW. The host that runs docker is actually a virtual machine running on Windows. I work on Windows and connect to the virtual machine via SSH. Is this related to the problem?

Wait. I tried to work directly on Windows (the folder that contains .devcontainer now rests on Windows), and use WSL, without SSH-ing to a virtual machine first. And 26.04 did work perfectly, no problem, just as you said. So, is this a problem that happens only when SSH then devcontainer?

[V-Subhankar-infy]

Hello Lucien Shaw (@lucienshawls),

I have followed the exact steps above manually to replicate the error (you can check the attached screeshot for reference) but for me the postcreate is running sucessfully as expected without errors hence I am still unable to replicate the error.

Seems like either there is cofiguration error at your end or there is some transient error that's causing an error in your specific system thats using Virtual Machine on windows via ssh connection.
I will once try replicating in other systems to check if it replicates, meanwhile you can also check if the docker engine and vs code is configured properly. Also, as you are using a virtual machine can you once test the same in a Linux VDI?

[lucienshawls]

Hello Lucien Shaw (@lucienshawls),

I have followed the exact steps above manually to replicate the error (you can check the attached screeshot for reference) but for me the postcreate is running sucessfully as expected without errors hence I am still unable to replicate the error.

Seems like either there is cofiguration error at your end or there is some transient error that's causing an error in your specific system thats using Virtual Machine on windows via ssh connection. I will once try replicating in other systems to check if it replicates, meanwhile you can also check if the docker engine and vs code is configured properly. Also, as you are using a virtual machine can you once test the same in a Linux VDI?

Thank you for your patience.

I did some other tests:

1. I installed vscode in the virtual machine and opened the folder with it (not with the vscode on windows that I was using before). This time everything was working perfectly.
2. Using the same vscode client on the virtual machine, but first established an SSH connection to localhost (that sounded meaningless). This time, post-create.sh did not run for 26.04 and correctly ran for 24.04, just like before. I also ruled out the vscode profile issue: this was a brand new vscode client and I did not even log in to vscode; there were no custom settings; I installed no extensions but devcontainer and SSH.

This locks the issue to SSH + devcontainer + ubuntu26.04 on my side. Weirdly, other combinations work perfectly: local + devcontainer + any image, SSH + devcontainer + many images except ubuntu26.04.

I still have untested scenarios. Could Docker itself play a role? I can see that you were using desktop-linux, which is a common context name of Docker Desktop. On my side, the docker is a rootful, directly installed Docker Engine.

I was wondering if you could find a linux machine (with rootful docker to be the best), SSH to it (or SSH to self), then try one more time?

[lucienshawls]

BTW. I noticed some small issues. For ALL of my failed attempts on ubuntu26.04 (cases where post-create.sh would not run), there was an error and only one error in the log, failing to copy a specific gnupg-related file:

# Logs for SSH + devcontainer + 26.04 (post-create.sh does not run):

[3156 ms] Start: Run in container: # Copy /home/lucien/.gnupg/pubring.kbx to /home/vscode/.gnupg/pubring.kbx
...
[3498 ms] Start: Run in container: # Copy /home/lucien/.gnupg/pubring.gpg to /home/vscode/.gnupg/pubring.gpg
...
[4010 ms] Command in container failed: # Copy /home/lucien/.gnupg/pubring.gpg to /home/vscode/.gnupg/pubring.gpg
(dd iflag=fullblock bs=8192 count=0 2>/dev/null; dd iflag=fullblock bs=0 count=1 2>/dev/null) >>'/home/vscode/.gnupg/pubring.gpg'

For all of my successful attempts, there were no errors:

# Logs for SSH + devcontainer + 24.04 (post-create.sh runs)

[6274 ms] Start: Run in container: # Copy /home/lucien/.gnupg/pubring.kbx to /home/vscode/.gnupg/pubring.kbx
...
[6537 ms] Start: Run in container: # Copy /home/lucien/.gnupg/pubring.gpg to /home/vscode/.gnupg/pubring.gpg
...
[6715 ms] Start: Run in container: # Copy /home/lucien/.gnupg/trustdb.gpg to /home/vscode/.gnupg/trustdb.gpg

# Logs for Local + devcontainer + 26.04 (post-create.sh runs)

[1080 ms] Start: Run in container: # Copy /home/lucien/.gnupg/pubring.kbx to /home/vscode/.gnupg/pubring.kbx
...
[1097 ms] Start: Run in container: # Copy /home/lucien/.gnupg/trustdb.gpg to /home/vscode/.gnupg/trustdb.gpg

For the above cases, I searched in the log for Copy /home/lucien/.gnupg/ and pasted all matching lines.

On the host, there was no such file: /home/lucien/.gnupg/pubring.gpg. But pubring.kbx and trustdb.gpg existed.

Does this help? Is this even related to the problem?

[V-Subhankar-infy]

Hello Lucien Shaw (@lucienshawls) , Thanks for the log details it helped me to reproduce the issue, Still it didn't happen naturally but I changed the configurations and achieved the bug that occurs on specific situations. (In short it's an upstream issue that's causing this to happen)

What's happening

GPG forwarding copies keyring files into the container using dd, splitting each transfer as count = size / 8192, bs = size % 8192. A 0-byte pubring.gpg therefore produces bs=0, which isn't a valid block size:

(dd iflag=fullblock bs=8192 count=0 2>/dev/null; dd iflag=fullblock bs=0 count=1 2>/dev/null) >>'/home/vscode/.gnupg/pubring.gpg'

Ubuntu 26.04 switched the default coreutils from GNU to Rust uutils, and the two handle that differently:

ubuntu24.04   dd (coreutils) 9.4           dd: invalid number: '0'          exit 1
ubuntu26.04   dd (uutils coreutils) 0.8.0  divide by zero → Aborted         exit 134

The extension tolerates exit 1 and carries on. It doesn't tolerate the abort , the copy sequence stops there (trustdb.gpg is never copied), setup aborts before lifecycle hooks, and postCreateCommand is never attempted. The container still starts and attaches, which is why there's no visible error.

Why it's rare

First of all most users simply use the local docker engine setup. That copying process that was failing only run when there's a host GPG setup to forward. GPG forwarding exists mainly so signed commits keep working inside the container, so it's only relevant if you have GPG keys on the host , which most dev container users don't. No ~/.gnupg, no copies, no dd, and 26.04 behaves exactly like 24.04. It's also automatic rather than opt-in, so the people who do hit it never switched anything on and have no reason to suspect it. And it's specific to the VS Code extension, the devcontainer CLI doesn't implement agent forwarding, so CLI-driven and CI builds never reach this path at all.

On top of that, newer GnuPG uses keyboxd and forwards a socket instead of copying files: my Mac had a 0-byte pubring.gpg and still worked until I disabled keyboxd to match your setup. Your WSL home simply had no pubring.gpg. The file is just an empty legacy keyring, any gpg1 call creates it, and gpg2 ignores it once pubring.kbx exists.

Workaround

The 0-byte pubring.gpg holds nothing, gpg2 reads your keys from pubring.kbx, so removing it is safe:

stat -c '%s %n' ~/.gnupg/pubring.*    # pubring.gpg should be 0
gpg --list-keys                       # keys should still be listed
rm ~/.gnupg/pubring.gpg

Where the fixes belong

Any one of these three would stop this happening, but only the first removes the underlying fault:

1. Don't generate bs=0, Dev Containers extension. For an empty source file the copy should just create the file; more generally the second dd shouldn't be emitted when the size is an exact multiple of 8192. This fixes it on every image and every coreutils implementation, and clears the same latent risk on the VS Code server download, which uses this code path. I captured iflag=fullblock bs=0 count=1 on 24.04 too by instrumenting dd inside the container, GNU rejects it cleanly, so it goes unnoticed there. That's why I'd treat the command generation as an extension bug rather than an Ubuntu one.
2. Don't let an optional credential copy abort provisioning , Dev Containers extension. Defence in depth: a failed GPG copy shouldn't silently skip lifecycle hooks with no error surfaced, whatever the cause.
3. Don't panic on bs=0, uutils/coreutils / Ubuntu's rust-coreutils. GNU prints an error and exits 1; aborting on user input is a regression against it. On its own this resolves the symptom but leaves 1 and 2 in place.

I'll file 1 and 2 at microsoft/vscode-remote-release and 3 upstream, and link them here.

Our side inherits coreutils from Ubuntu via buildpack-deps, so there's no image change to make here, but base:ubuntu currently floats to resolute and we'll document the coreutils switch in the 26.04 release notes. Keeping this open to track the upstream fixes.

Thanks for staying with it ; the log line you pulled out is what cracked this. ( Refer to the below report in case if you are interested to know in-depth analysis of this bug. report.md )

[lucienshawls]

Thank you for your thorough inspection, that was really a detailed report.

I have no more questions for now, but will keep this open to track upstream fixes (as you said). You can close this issue when everything is done.

[V-Subhankar-infy]

Before forwarding the issue, Could you once confirm if deleting the pubring solved your issue.

[lucienshawls]

Weird. I thought the problem could be solved as you described, but no.

I discovered that ~/.gnupg/pubring.gpg was never there —— I got nothing to remove, but the problem was still there. I then removed the entire folder ~/.gnupg, the problem was still there, with another error in log (complaining pubring.kbx failing to copy).

But I came up with an idea. I do not use gnupg, so I ran commands on host:

mkdir ~/.gnupg
cd ~/.gnupg
echo "#" > pubring.gpg
echo "#" > pubring.kbx
echo "#" > trustdb.gpg

These were some nonsense commands that simply writes something rubbish in the file so the filesize was not 0.

And the problem disappeared. post-create.sh ran successfully.

It confirmed your inference: the dd command does not tolerate bs=0.

But I was curious: why did the devcontainer try to copy gnupg files even if the ~/.gnupg did not exist?