QEMU has a neat bridge-helper utility which allows a non-root user to easily connect a virtual machine to a bridged interface. In Fedora at least, qemu-bridge-helper runs as setuid (any user can run as root) and privileges are immediately dropped to cap_net_admin. It also has a simple white/blacklist ACL mechanism in place which limits connections to virbr0, libvirt’s local area network.
That’s all great, but often you actually want a guest to be a part of your real network. This means it must connect to a bridged interface (often br0) on a physical network device.
If your user tries to kick up such a QEMU guest while specifying bridge,br=br0, something like this (although probably also with a disk or kernel and initramfs):
qemu-system-x86_64 \
-machine accel=kvm \
-cpu host \
-netdev bridge,br=br0,id=net0 \
-device virtio-net-pci,netdev=net0
You may run into the following error:
access denied by acl file
qemu-system-ppc64: -netdev bridge,br=br0,id=net0: bridge helper failed
As mentioned above, this is the QEMU bridge config file /etc/qemu/bridge.conf restricting bridged interfaces to virbr0 for all users by default. So how to make this work more nicely?
One way is to simply edit the main config file and change virbr0 to all, however that’s not particularly fine-grained.
Instead, we could create a new config file for the user which specifies any (or all) bridge devices that this user is permitted to connect guests to. This way all other users are restricted to virbr0 while your user can connect to other bridges.
This doesn’t have to be a user, it could also be a group (just substitute ${USER} for the group, below), and you can also add multiple files.
Instead of allow you can use deny in the same way to prevent a user or group from attaching to any or all bridges.
So, let’s create a new file for our user and give them access to all interfaces (requires sudo):
echo "allow all" | sudo tee /etc/qemu/${USER}.conf
echo "include /etc/qemu/${USER}.conf" | sudo tee --append /etc/qemu/bridge.conf
sudo chown root:${USER} /etc/qemu/${USER}.conf
sudo chmod 640 /etc/qemu/${USER}.conf
This user should now be able to successfully kick up the guest connected to br0.
qemu-system-x86_64 \
-machine accel=kvm \
-cpu host \
-netdev bridge,br=br0,id=net0 \
-device virtio-net-pci,netdev=net0
6 thoughts on “Configuring QEMU bridge helper after “access denied by acl file” error”
Hello. I am trying to emulate ARM architecture using QEMU. My host OS is ubuntu 16.04 and the guest OS inside the emulated machine is also ubuntu 16.04.
I follwed your tutorial to remove the following error:
“access denied by acl file
qemu-system-ppc64: -netdev bridge,br=br0,id=net0: bridge helper failed”
The final command that I’m running reads “sudo qemu-system-arm -m 1024 -cpu cortex-a57 -M virt -nographic -drive file=flash0.img,format=raw,if=pflash -drive file=flash1.img,format=raw,if=pflash -drive if=none,file=xenial-server-cloudimg-arm64-uefi1.img,id=hd0 -device virtio-blk-device,drive=hd0 -netdev bridge,br=br0,id=net0 -device virtio-net-pci,netdev=net0,mac=$randma”
But now I’m getting the following error:
“failed to get mtu of bridge `br0′: No such device
qemu-system-arm: -netdev bridge,br=br0,id=net0: bridge helper failed”
This is my first time emulating a machine in QEMU. Your help would be highly appreciated.
Thank you in advance.
I think this is because you are telling your qemu machine to connect to a bridge network device, br0, however I’m assuming you have not configured this bridge. A bridge will connect your guest to the local network as though it was a physical machine plugged in. You may want to just do local networking and have the guest behind a NAT. I’m not sure how Ubuntu does this, sorry, but maybe this will help: https://help.ubuntu.com/community/KVM/Networking
Bringing up the QEMU bridge took me two whole days to figure out what the problem was…
Thanks for this write up dude, adding “allow all” to the custom bridge conf fixed the permissions issue and I could get into virt.
Installing ebtables and dnsmasq would also lock me out, so I could never tell what the problem was until I chroot’ed from a live disk with natural networking.
Thanks!
Awesome, glad it helped!
I put my machine to sleep overnight, woke it up the next day, and BLAM, I could no longer attach VMs to the default bridge. This article helped. Thanks!
Great!