PSA: network.subnet setting broken in versions 0.12.x under macOS 15

[natevw]

After a recent bout of having to reset my network stack for macOS 15 (xref #1350) my networking was restored momentarily but then broke again when I updated from release 10.0.0 to release 0.12.3.

At this point all containers were getting assigned IP and DNS addresses within the default (192.168.64.1/24) subnet rather than the actual one specified by the network.subnet system property. I.e. even with that set (via defaults write or system property set) to "192.168.66.1/24" I would still see in the container system logs -f stream entries like:

2026-05-27 15:15:34.058864-0700 0x1265d3 Info 0x0 14214 0 container-network-vmnet: [com.apple.container:NetworkVmnetHelper] allocated attachment [ipv4Address=192.168.64.2/24] …[ipv6Address=unavailable] [ipv4Gateway=192.168.64.1] [id=default]

I believe this regression was introduced via https://github.com/apple/container/pull/1424/changes#diff-a6e22425214f659d9dde69d7d2ffb92340a097f7efc62335d7027874f92b7470 though I haven't quite analyzed how/why as the logic looks superficially somewhat similar just reshuffled somewhat.

It appears that this may be changing anyway with the move to TOML: https://github.com/apple/container/pull/1425/changes#diff-a6e22425214f659d9dde69d7d2ffb92340a097f7efc62335d7027874f92b7470

For now I have worked around by re-installing the 0.11.0 release which predates #1424 and does launch the VM into the specified subnet as before.

UPDATE — see #1677 (comment) for a workaround on newer releases (confirmed myself on 1.0.0 release and likely 0.12.x as well). I removed the whole folder but it might be (unofficially, at-your-own-riskedly!!!) possible to edit a stale subnet value in the ~/Library/Application\ Support/com.apple.container/networks/default/entity.json file to the new desired one.

[jglogan]

container has no control over what subnet vmnet gives us.

This is a fundamental limitation of the vmnet framework in macOS 15. The new vmnet APIs for macOS 26 were created to support tools like container.

What makes fixing the problem for Sequoia so tricky is that you need to create a VM to materialize the network in Sequoia. It's only at that time that the subnet CIDR is known.

We don't support container on macOS 15 for this reason in particular.

[natevw]

Unclear what didn't make it into 1.0.0? ~~But I do find that on macOS 15.7.7 trying container run -it --rm alpine just get:

Error: builtin network is not present

…so I'll have to review if there's any corresponding doc update or workaround but maybe 0.11.x was the last substantially working release then on Sequoia?

UPDATE1: nope, that issue was just because I had not done a container system stop; container system start. Trying

# NOTE: if you get "file exists" then don't proceed; you'll want to append/edit manually
mkdir ~/.config/container
printf '[network]\nsubnet = "192.168.66.1/24"\n' >> ~/.config/container/config.toml

followed by another stop/start of the container system doesn't give me the right subnet as reported by ip a in the container though yet.

[natevw]

Okay, I suspect what @afbjorklund was saying is that @jglogan's hope that:

We'll double-check that the TOML network.subnet setting does the correct thing on a Sequoia system in the next release.

is the "it" that didn't make it into 1.0.0. I'm still seeing similar behavior under the TOML system as with the 0.12.x regression. Now filed as #1677 and will downgrade to 0.11.x as workaround again.

[katiewasnothere]

@natevw I'm setting up a test machine to take a better look. In the meantime, what do you see in the logs when you've set the subnet in the user toml?

[natevw]

Thanks @katiewasnothere — the full logs I see if I run container run --rm alpine ip a in a second terminal are:

% container system logs -f
Filtering the log data using "subsystem == "com.apple.container""
Timestamp                       Thread     Type        Activity             PID    TTL  
2026-06-09 15:26:41.822017-0700 0x542413   Info        0x0                  79347  0    container-apiserver: [com.apple.container:APIServer] Registering plugin [id=com.apple.container.container-runtime-linux.71c4926c-9833-4914-a55c-714fbc83f958]
2026-06-09 15:26:41.884812-0700 0x544b5f   Info        0x0                  79527  0    container-runtime-linux: [com.apple.container:RuntimeLinuxHelper] starting helper [name=container-runtime-linux] [uuid=71c4926c-9833-4914-a55c-714fbc83f958]
2026-06-09 15:26:41.886248-0700 0x544b5f   Info        0x0                  79527  0    container-runtime-linux: [com.apple.container:RuntimeLinuxHelper] configuring XPC server [uuid=71c4926c-9833-4914-a55c-714fbc83f958]
2026-06-09 15:26:41.886453-0700 0x544b5f   Info        0x0                  79527  0    container-runtime-linux: [com.apple.container:RuntimeLinuxHelper] starting XPC server [uuid=71c4926c-9833-4914-a55c-714fbc83f958]
2026-06-09 15:26:41.896038-0700 0x544b69   Info        0x0                  79527  0    container-runtime-linux: [com.apple.container:RuntimeLinuxHelper] created bundle [uuid=71c4926c-9833-4914-a55c-714fbc83f958] [configPath=file:///Users/natevw/Library/Application%20Support/com.apple.container/containers/71c4926c-9833-4914-a55c-714fbc83f958]
2026-06-09 15:26:41.897258-0700 0x5448dc   Info        0x0                  79354  0    container-network-vmnet: [com.apple.container:NetworkVmnetHelper] allocated attachment [id=default] [ipv4Gateway=192.168.64.1] [ipv4Address=192.168.64.5/24] [ipv6Address=unavailable] [hostname=71c4926c-9833-4914-a55c-714fbc83f958] [macAddress=f6:e8:4a:7c:a2:28]
2026-06-09 15:26:42.701561-0700 0x542413   Info        0x0                  79347  0    container-apiserver: [com.apple.container:APIServer] registering container with exit monitor
2026-06-09 15:26:42.704799-0700 0x544b69   Info        0x0                  79527  0    container-runtime-linux: [com.apple.container:RuntimeLinuxHelper] init process exited [uuid=71c4926c-9833-4914-a55c-714fbc83f958] [status=ExitStatus(exitCode: 0, exitedAt: 2026-06-09 22:26:43 +0000)]
2026-06-09 15:26:42.721868-0700 0x544b69   Info        0x0                  79527  0    container-runtime-linux: [com.apple.container:RuntimeLinuxHelper] closing forwarders [uuid=71c4926c-9833-4914-a55c-714fbc83f958]
2026-06-09 15:26:42.721890-0700 0x544b69   Info        0x0                  79527  0    container-runtime-linux: [com.apple.container:RuntimeLinuxHelper] closed forwarders [uuid=71c4926c-9833-4914-a55c-714fbc83f958]
2026-06-09 15:26:42.733299-0700 0x542ab6   Info        0x0                  79347  0    container-apiserver: [com.apple.container:APIServer] container finished in exit monitor [id=71c4926c-9833-4914-a55c-714fbc83f958] [rc=ExitStatus(exitCode: 0, exitedAt: 2026-06-09 22:26:43 +0000)]
2026-06-09 15:26:42.736140-0700 0x5448dc   Info        0x0                  79354  0    container-network-vmnet: [com.apple.container:NetworkVmnetHelper] released session [id=default] [allocations=1]
2026-06-09 15:26:42.736382-0700 0x542ab6   Info        0x0                  79347  0    container-apiserver: [com.apple.container:APIServer] handling container exit [rc=ExitStatus(exitCode: 0, exitedAt: 2026-06-09 22:26:43 +0000)] [id=71c4926c-9833-4914-a55c-714fbc83f958]
2026-06-09 15:26:42.736742-0700 0x542ab6   Info        0x0                  79347  0    container-apiserver: [com.apple.container:APIServer] shutting down runtime service [id=71c4926c-9833-4914-a55c-714fbc83f958]
2026-06-09 15:26:42.755179-0700 0x542ab6   Info        0x0                  79347  0    container-apiserver: [com.apple.container:APIServer] deregistered runtime service [id=71c4926c-9833-4914-a55c-714fbc83f958]

[natevw]

I think we have a better workaround thanks to @katiewasnothere debugging so far, see #1677 (comment) about removing a ~/Library/Application\ Support/com.apple.container/networks folder which seems to let the setting take effect for me in the 1.0.0 release.