Unprivileged lxc containers using veth will not start after upgrade
from bookworm to trixie. Details are given in
https://github.com/lxc/lxc/issues/4587  They do start just fine, when
the Debian  executable `lxc-user-nic` is replaced by one built from
today's github code. That is: what's in github right now works. What's
in Debian trixie doesn't.

The details are in the github bug report. To summarize, the errors I
was seeing were these:

lxc-start -F mycontainer
lxc-start: mycontainer: ../src/lxc/network.c:
lxc_create_network_unpriv_exec: 3029 lxc-user-nic failed to configure
requested network: ../src/lxc/cmd/lxc_user_nic.c: 838:
lxc_secure_rename_in_ns - Permission denied - Failed opening network
namespace path for 383865
../src/lxc/cmd/lxc_user_nic.c: 1219: main: Failed to rename the link
lxc-start: mycontainer: ../src/lxc/start.c: lxc_spawn: 1852 Failed to
create the network
lxc-start: mycontainer: ../src/lxc/start.c: __lxc_start: 2119 Failed
to spawn container "mycontainer"

control: tags -1 + moreinfo

Hi Linas,

  I think there must be something specific to your setup and/or
container configuration, as I can successfully start an unprivilged
trixie container using the steps below, both on a clean bookworm VM
upgraded to trixie after the container is created/started, as well as a
clean trixie VM.

  As you can see, the default configuration for lxc in Debian is to
setup a veth-backed NIC for each container.

  It would be useful if you could try creating a minimal container on
the same host system using the above steps to see if you encounter the
same issue starting a fresh container. If so, I would look at your
sub{u,g}id mappings or other local changes to the configurations files
under /usr/share/lxc/config/. If the fresh container starts up, that
points to an issue in the existing container's configuration.

Mathias

  A link to the upstream pull request with the fix would be most
appreciated. Bug fixes for stable must be specific and targeted; since
I can't reproduce the issue on my end I can't git bisect down to the
commit that fixes your issue.

  Without additional information to help other people reproduce your
issue, there's really nothing that can be done about this bug.

Mathias

Hi Matthias,

When you tried to reproduce this issue, what did you actually do? What
did you attempt, and at which stage did things "just work" for you? I
can try to walk you through the steps until you hit failure. Can you
give a specific list of steps to the failure-to-reproduce point?  I
cannot really guess what it is that you did, or how you did it. You'd
have to be more specific.

But I'm also confused about what you are asking for: clearly, many
other people have tripped over this; you can find umpteen discussions
on various forums describing the bug(s). The lxc maintainers found the
bug and fixed it; the 28 Sept 2025 lxc git tree contains working code.
I can't tell which pull req it is that provided the fix.  Are you
asking me to git bisect to find the specific fix?

Let's work on getting this reproduced on your machine; it should not
be that hard to do.