When working with libvirt's virsh command-line tool, you might encounter a puzzling situation where network configurations appear differently between regular users and root:

$ virsh net-list --all
 Name                 State      Autostart     Persistent
----------------------------------------------------------

$ sudo virsh net-list --all
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 default              active     no            yes

First, verify your user's group memberships and file permissions:

$ groups
user kvm libvirt libvirtd

$ ls -l /etc/libvirt/qemu/networks/
total 8
drwxr-xr-x 2 root root 4096 Jul  1 18:19 autostart
-rw-r--r-- 1 root root  228 Jul  1 18:19 default.xml

The primary issue stems from connection URI differences. By default, virsh uses different connections for root and non-root users:

$ virsh uri
qemu:///session

$ sudo virsh uri
qemu:///system

Force virsh to use the system connection as a regular user:

$ virsh -c qemu:///system net-list --all
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 default              active     no            yes

To make this persistent, configure your libvirt client:

$ cat ~/.config/libvirt/libvirt.conf
uri_default = "qemu:///system"

For systems using PolicyKit, create access rules:

$ cat /etc/polkit-1/localauthority/50-local.d/50-libvirt-group-network-access.pkla
[Allow libvirt group network access]
Identity=unix-group:libvirt
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes

After configuration changes, verify with:

$ id
$ virsh -c qemu:///system net-list
$ getfacl /etc/libvirt/qemu/networks

---

When working with Libvirt's virsh command, you might encounter a scenario where network listings appear differently between regular users and root:

# As regular user
$ virsh net-list --all
 Name                 State      Autostart     Persistent
----------------------------------------------------------

# As root
$ sudo virsh net-list --all
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 default              active     no            yes

First confirm your user belongs to required groups:

$ groups
username kvm libvirtd docker

The root cause typically lies in libvirtd's authentication settings. Check the UNIX socket permissions:

$ ls -l /var/run/libvirt/libvirt-sock
srwxrwx--- 1 root libvirtd 0 Jul  1 18:19 /var/run/libvirt/libvirt-sock

Modern systems use systemd socket activation. Verify the socket unit configuration:

$ systemctl cat libvirtd.socket
[Socket]
SocketMode=0660
SocketUser=root
SocketGroup=libvirt

Create or modify Polkit rules in /etc/polkit-1/rules.d/50-libvirt.rules:

polkit.addRule(function(action, subject) {
    if (action.id == "org.libvirt.unix.manage" &&
        subject.isInGroup("libvirt")) {
            return polkit.Result.YES;
    }
});

After making changes, test connectivity with:

$ virsh -c qemu:///system list --all

For some systems, explicitly specifying the connection URI helps:

$ virsh -c qemu:///system net-list --all

When troubleshooting fails, strace can reveal permission issues:

$ strace -f -e connect virsh net-list 2>&1 | grep libvirt

Examine libvirtd logs for authentication errors:

$ journalctl -u libvirtd -n 50 --no-pager

While network XML files might have correct permissions, other paths matter too:

$ ls -ld /var/lib/libvirt/dnsmasq/
drwx------ 3 root root 4096 Jul  1 18:19 /var/lib/libvirt/dnsmasq/

Verify libvirtd.conf settings:

$ grep -E '^unix_sock|^auth_unix' /etc/libvirt/libvirtd.conf
unix_sock_group = "libvirtd"
unix_sock_rw_perms = "0770"
auth_unix_ro = "none"
auth_unix_rw = "none"