Bug in ACL when editing while assigned to profile

,

Hi,

I think I found a bug in the ACL edit function after assigning an ACL to a nic via profile.

How to reproduce

Fresh Incus installation 6.17 on Debian 13

  1. Create a network of type bridge, in this cases it is a vlan on an upstream interface:
incus network create incusbr1010 --type=bridge bridge.external_interfaces=enp47s0f0.1010/enp47s0f0/1010 ipv4.address=none ipv6.address=none
  1. Assign this interface to an additional profile:
name: incusbr1010
description: ''
devices:
  eth0:
    network: incusbr1010
    type: nic
config: {}
project: default
  1. create an ACL called ‘test’, content of the ACL does not really matter:
name: test
description: test
egress:
  - action: reject
    state: enabled
ingress:
  - protocol: ''
    action: reject
    state: enabled
config: {}
  1. assign the ACL to the nic eth0 in the profile create in Step 2):
name: incusbr1010
description: ''
devices:
  eth0:
    network: incusbr1010
    type: nic
    security.acls: test
config: {}
project: default
  1. now assign a VM or a container to the profile. The ACL rules perfectly work on the container.

  2. now try to modify the ACL

 network acl edit test

you will receive the following error:

Config parsing error: Failed to run: nft -f -: exit status 1 (/dev/stdin:2:24-38: Error: No such file or directory; did you mean chain ‘fwd.incusbr0’ in table inet ‘incus’?

You first have to remove the ACL from the profile, then edit the ACL and assign it back to the profile. Editing while assigned to the profile throws the above error.

Expected behaviour

Being able to edit ACLs without deleting them from profiles first and adding them back after the ACL change.

Bonus Question not related to the bug:

would you recommend using

incus network create incusbr1010 --type=bridge bridge.external_interfaces=enp47s0f0.1010/enp47s0f0/1010 ipv4.address=none ipv6.address=none

or

incus network create vlan1010 --type=macvlan vlan=1010 parent=enp47s0f0

To my understanding ACLs in the above describe way can only be used with type bridge, is this correct? Are there any downsides bridge vs macvlan?

Can you file an issue at Sign in to GitHub · GitHub for the error you ran into?

And you’re correct that we can only do ACLs on a bridge, macvlan doesn’t provide any host-side device that can be used for filtering. In general, bridges should be preferred to macvlan whenever practical.

Thank you for your reply. You will find the bug report here: