Change:
virtualisation.podman.enable = true; virtualisation.podman.defaultNetwork.settings.dns_enabled = true; <del> networking.firewall.allowedUDPPorts = [ 53 ]; </del> }; docker = { pkgs, ... }: { virtualisation.podman.enable = true;

Discussion:
Upgrading from NixOS 23.05 to 23.11 makes podman not be able to install a project inside a container. podman in a folder, create the following two files: Dockerfile with the following contents: with the following contents: the folder with the two docker files, open a terminal and run the container with the container into express-generator-typescript folder and run After exiting the container, stop it with and remove all containers and images from system with When running yarn install, the process should finish with success as in NixOS 23.05 ! ! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
i can confirm network in containers is not working after upgrade to 23.11, the issue also occurs with update: fixes the issue, however that means that portmapping will not work anymore.
I think this should be re-opened. Now that it is now available in release and unstable I tested and it is still not working for me. Here from the container: Here on the host:
Anything I can do or help? Open a new issue? Re-open this one? Provide more details?
We need more informtion. What nixpkgs revision are you running? Are you using the default network or a new one?
Some people use experimental nftables as firewall. They should add to nftable ruleset
Here is my podman config: Which is pretty barebones: I am running the following test pod: Which starts the dns resolver But the it's still not usable from within the pod Maybe the "kube" uses another network? I also tried but that didn't make a difference. This is what the firewall looks like: Cross Checking the interfaces I found that there is no So I tried with which made it work. But IMO that's something the podman package should do automatically.
Okay, we can modify the firewall rule to use a wildcard like to cover all interfaces starting with the prefix podman. However, the user can set arbitrary interface names for interfaces created at runtime. So I don't think we can fix every case here. That's also why I thought the default interface case is enough for a convenient automatic firewall opening.

If the user has more interfaces, the firewall configuration needs to be set accordingly. Any thoughts on how to proceed? Maybe add some documentation? Regarding nftables, since AFAIK there isn't yet a composable way to add new firewall rules I don't think we can solve that in the podman module itself.
I guess the question for me is: Why has my install instead of . I didn't configure it that way. The problem should go away (for me) if it was . Can I change that? How? I guess opening the fw could be done dynamically (via systemd? during startup?). Really not a fan of that idea though. If this needs to be configured it needs to be very prominent in the documentation.
You probably hat two networks configured in podman at some point and removed the first one. This is runtime config and thus state in podman which we do not control in the NixOS module. You can create a new podman network like and remove the other one with . This would also need to be done at runtime not only at service start since at any point new interfaces can be created by the user via the CLI/API. There would need to be a service that monitors the networks managed by the podman service.
There is neither a nor a network. I am wondering if this is rather due to the fact this is using . True. Unless the firewall rules can allow for a wildcard match that feels the cleanest (and only?) option. Or how about just creating static rules for , and so on? And have the number be part of the podman config?
My guess is that is and is . Maybe we just need to expand the fix to also include for now? What's the further process, Anything else I can help with?
So no further suggestions? Should this be at least documented somewhere?