[Solved - AppArmor] What don't I understand about file permissions? Permissions Denied ever after chmod 777

In preparation for converting my main system over to a linux → qemu + looking glass configuration, I’m attempting do duplicate the setup on an old laptop that I have. Part of the process of passing the dedicated nvidia gpu to the vm is that I need to present a fake battery to the guest. This is accomplished with an acpitable, but virt-manager is unable to access the file.

What am I missing?

I’m on Debian Sid. As far as I can tell, SeLinux/AppArmor aren’t installed, which is what google points me to as a likely cause. I suspect there is a fundamental aspect of file permissions that I don’t understand.



I made sure that the UID that is running the virt-manager process is the same as the owner of the file. I tried chmod-ing the parent images folder as well and the behavior didn’t change.

It’s ownership. The user requesting an action needs to be owner of the action target. A bit cryptic, but you need to make the qemu process owner of the directory /var/lib/images/

Investigate the chown command: link!

1 Like

The qemu process was happening under user “libvirt-qemu”. Setting the owner of the file and folder to match that didn’t change the behavior.

Maybe there’s something else to this.

Are you sure the file is there? It says the file cant open, maybe because it isnt there?

Do try to browse the directory itself and run ls -la

1 Like

I did try removing the file and the error changed to ‘file not found’, so it is being detected.

I’m working on temporarily running qemu as root. If the error STILL doesn’t change then my computer is just haunted.

EDIT: setting user = “root” and group = “root” in /etc/libvirt/qemu.conf didn’t change the error either. Hmmmm. . . I might need to reload libvirt or something.

Make sure the qemu or wizard user has read right to the
/var/lib/libvirt/images directory
It’s no use to make the file world readable if the user cannot access the dir…

1 Like

Are you absolutely sure apparmor isn’t involved? Often (not always) DAC denials give you an “Operation not permitted” error, whereas MAC would give you a “Permission denied”.
And since you opened that file to the whole world by chmodding it to 777 (fix it when you figure out the issue, it’s bad practice no matter what file) and you said it’s part of the same groups too, it really doesn’t sound like a DAC issue.

If you’re running virt-manager as a flatpak, check the dir access permissions with flatseal.
If it’s a native repo install, all I can think of is apparmor


This is 100% is AppArmor and/or cgroups

As for chmod, I tried to make a video to explain it a few years ago, no idea how successful it is/was.


Would be good to see the output of some apparmor status commands to confirm AppArmor/HowToUse - Debian Wiki

selinux has a log file it writes policy alerts too which can be useful for debug and writing selinux policy. Not sure on apparmor, might be something similar.

I had to google debian Sid. unstable version hmm. Maybe a bug in your current installed packages.

Have you had a look in the libvirt log? Often extra detail about fails in the logs, or systemd status.

I landed on the original assumption that neither SELinux not AppArmor were installed because the status commands that I tried resulted in a “command not found” kind of output. But when I get home I’m going to spend more time looking into both services are figure out what’s going on.

1 Like

Both aa-status and getenforce return “command not found”, so it seems like I can rule that out.

I’ve ensured that the process has access to the directory.

I installed virt-manager though apt, so I should be good there as well.

The only relevant logs that I had found were through (I believe) journalctl, and those were just duplicates of the permission denied output. I will look into libvirt logs for more information.

Barring that, I’ll investigate if qemu is placed in a cgroup (I was not aware of their existence until tonight) and figure out what restrictions are placed on it.

1 Like

Just to double-check, did you change to root by using “su” or “su -” before checking aa-status?

You can also check with ‘systemctl status apparmor’

1 Like

TIL that “command not found” and a service not being installed are not the same thing. Thanks for the tip with systemctl status :+1:

I was running aa-status as a user and was expecting a permissions error if it existed.

Yeah it can be unintuitive at first because often it is not explained, it’s actually a security feature because the idea is that unprivileged users don’t need to know what security implications are active. It’s just security through obscurity.

Also changing users with the hyphen is often overlooked so sometimes commands fail because as the computer is concerned, if it’s running a root command as a user it will assume unprivileged user permissions to said command.

1 Like

I added read access to the file into AppArmor and my permissions issue is resolved :ok_hand: Thank you all.


I have been experimenting with Fedora and hit a similar wall with access to /dev/kvmfs0 for qemu. “Permission denied” leads to SELinux, but the issue persists even with SELinux set to permissive mode. I’m might just not have ownership set to the correct user, but is there anything different about persimmons in Fedora?

EDIT: cstates :+1:

  1. It’s /dev/kvmfr0
  2. It’s cgroups not cstates
  3. Seeing as you’re now talking about looking glass, see our documentation:



Right right, cstates is processor power.

I got this sorted last week by rtfm-ing the lg documentation :+1: Very complete, but you actually have to read it and not skip sections.

1 Like