Home Original page

nspawn: systemd-networkd stopped working in containers without `-U` in 242 · Issue #12313 · systemd/systemd

@doverride

I have the same issue: Volatile= conflicts with -U, and so i cannot run networkd in my containers with volatile=overlay (things like passwd do not work in this scenario either by the way)

@yuwata yuwata changed the title systemd-networkd stopped working in containers without -U in 242 nspawn: systemd-networkd stopped working in containers without -U in 242

Apr 15, 2019

@yuwata

yuwata added a commit to yuwata/systemd that referenced this issue

Apr 15, 2019

@yuwata

@yuwata

@enku

Copy link

Author

@enku enku commented Apr 16, 2019

@yuwata This seems to work for my vanilla containers. However for ones that I have a .nspawn file I still get ConditionCapability=CAP_NET_ADMIN was not met, even if said file is empty. IOW:

# rm /etc/systemd/nspawn/<machine>.nspawn succeeds, but then

# touch /etc/systemd/nspawn/<machine>.nspawn fails.

This is with --settings=override.

@yuwata

When --settings=override and the corresponding .nspawn file exists, then the command line arguments are ignored. So, the behavior is intended.

Before a3fc6b5, the capability CAP_NET_ADMIN was not dropped. But it is not intended. See issue #11755.

Let's close this.

@enku

Copy link

Author

@enku enku commented Apr 17, 2019 •

So with --settings=override all command-line arguments are ignored? The man page says:

If this option is set to override, the file is searched, read and used the
same way, however, the order of precedence is reversed: settings read from
the .nspawn file will take precedence over the corresponding command line
options, if both are specified.

So I would think that an empty .nspawn file would have no effect, since it isn't overriding anything.

@yuwata

@qmega

Copy link

Contributor

@qmega qmega commented Apr 28, 2019 •

I have a similar regression that I bisected to a3fc6b5. Let me know if I should open a new issue, but I suspect the cause and resolution will be the same. My case is using machinectl start with some settings in /etc/systemd/nspawn/*.nspawn, but no network-related ones -- I'm relying on the default network options of the systemd-nspawn@.service template for those. I get the exact same issue with systemd-networkd inside the container complaining about CAP_NET_ADMIN.

The problem, AFAICT, is that the logic in the aforementioned commit looks only at the file being parsed to decide whether CAP_NET_ADMIN is needed or not. That was fine when it was only being added, as code elsewhere added it when command line arguments required it. But now that the file-settings logic is also removing the capability, it will be erroneously removed when there are command-line options implying private-network but nothing in the config file that does so. In support of this, my case can be worked around by adding a [Network] section with Private=yes to my .nspawn file.

@fgrsnau

Workaround for the default configuration of the systemd-nspawn@.service units is to add VirtualEthernet=yes to the [Network] section of the corresponding nspawn files.

@bjoe2k4

@yuwata I'd like to retain CAP_NET_ADMIN for my nspawn container while at the same time having VirtualEthernet=no. According to the man page this should be simply done by adding Capability=CAP_NET_ADMIN to the [Exec] section of the .nspawn file. With the current systemd-242 this does not work. There is no net_admin when verifying via pscap.

@h3ndrik

i added my bridge config to each /etc/systemd/nspawn/*.nspawn file:

[Network]
VirtualEthernet=yes
Bridge=br0

this gives the CAP_NET_ADMIN to the containers. specifying the same in the ExecStart command-line-options /etc/systemd/system/systemd-nspawn@.service doesn't do anything anymore.

@lahwaacz

I don't know if this is a regression or not, but the report is somewhat confusing. Despite what the OP says, the behaviour is unrelated to the -U flag - the problem appears with as well as without -U. Maybe it's a regression^2... Anyway, please change the title to something better to make the issue easier to find.

To summarize the behaviour that has been observed in the comments above (you can add -U with no change in behaviour):

  1. systemd-nspawn --network-veth --settings=override -bD container and /etc/systemd/nspawn/container.nspawn does not exist – works as expected

  2. systemd-nspawn --network-veth --settings=override -bD container and /etc/systemd/nspawn/container.nspawn exists, but is empty – the systemd-networkd.service does not start in the container due to ConditionCapability=CAP_NET_ADMIN was not met, the host0 interface in the container remains unmanaged

  3. systemd-nspawn --network-veth --settings=override -bD container and /etc/systemd/nspawn/container.nspawn contains:

    [Network]
VirtualEthernet=yes

    – works as expected

Now, consider another case:

  1. systemd-nspawn --network-veth --settings=override -bD container and /etc/systemd/nspawn/container.nspawn contains:

    – the result is that systemd-networkd.service starts fine in the container, but the virtual Ethernet link was not created! (the container interface host0 and host interface ve-container were not created)

Why does passing Private=yes in the .nspawn file and --network-veth on the command line discard the creation of the virtual Ethernet link?

This was tested with systemd 246.2 and Arch Linux (both host and container).

@srd424

Copy link

Contributor

@srd424 srd424 commented Mar 15, 2021 •

@PaulGrandperrin

For info, the bug is still present in Systemd 247 (NixOS 21.05).
This workaround still works too (#12313 (comment))