Weird permission issues with APT in a priviledged LXC container?

[boiimak]

Hi guys! I'm pretty new to Proxmox, but I feel like I've been doing pretty fine. However, I've run into this really weird issue where I cannot use APT to install some packages in my LXC container. I also had some issues earlier with Docker, but I fixed those by turning on nesting. However, now when I try to install a package I get told that APT can't access Perl and other parts of my kernel.
It definitely smells like an Apparmor thing, but I have no idea how to change anything in Apparmor, so I can't confirm. Apart from that, I have no idea what it could be or what I could do. AFAIK, everything is updated on both the host and guest, and while I had done a lot of weird forkery with disks and such on the host, I haven't touched anything with Apparmor or LXC configurations, so I'm at a bit of a loss. Can anyone help?

APT Log
LXC Conf
apparmor.d attached below.


If there are any other logs/files anyone needs, please let me know. Thanks for the help!

 

[leesteken]

I just created a privileged container with the same configuration and apt-get install openvpn works without such errors.

Spoiler: 202.conf

arch: amd64
cmode: shell
cores: 4
features: nesting=1
hostname: CT203
memory: 6144
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=62:EE:A7:30:5F:38,ip=dhcp,type=veth
net1: name=br3,bridge=vmbr3,hwaddr=76:5C:1C:77:4F:FA,ip=105.1.2.244/24,type=veth
ostype: debian
rootfs: qpool-zfs:subvol-202-disk-0,mountoptions=noatime,size=32G
swap: 512

Spoiler: apt-get install openvpn

root@CT203:/# apt-get install openvpn
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
resolvconf openvpn-systemd-resolved
The following NEW packages will be installed:
openvpn
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/490 kB of archives.
After this operation, 1167 kB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously unselected package openvpn.
(Reading database ... 21057 files and directories currently installed.)
Preparing to unpack .../openvpn_2.4.7-1_amd64.deb ...
Unpacking openvpn (2.4.7-1) ...
Setting up openvpn (2.4.7-1) ...
[ ok ] Restarting virtual private network daemon.:.
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn.service → /lib/systemd/system/openvpn.service.
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for systemd (241-7~deb10u5) ...
root@CT203:/#

Did you maybe create an unprivileged container and then removed the unprivileged: 1?
Can you try again with an updated debian-10-standard_10.7-1_amd64.tar.gz template and create a privileged container from the start?

 

[boiimak]

I just created a privileged container with the same configuration and apt-get install openvpn works without such errors.

Spoiler: 202.conf

arch: amd64
cmode: shell
cores: 4
features: nesting=1
hostname: CT203
memory: 6144
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=62:EE:A7:30:5F:38,ip=dhcp,type=veth
net1: name=br3,bridge=vmbr3,hwaddr=76:5C:1C:77:4F:FA,ip=105.1.2.244/24,type=veth
ostype: debian
rootfs: qpool-zfs:subvol-202-disk-0,mountoptions=noatime,size=32G
swap: 512

Spoiler: apt-get install openvpn

root@CT203:/# apt-get install openvpn
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
resolvconf openvpn-systemd-resolved
The following NEW packages will be installed:
openvpn
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/490 kB of archives.
After this operation, 1167 kB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously unselected package openvpn.
(Reading database ... 21057 files and directories currently installed.)
Preparing to unpack .../openvpn_2.4.7-1_amd64.deb ...
Unpacking openvpn (2.4.7-1) ...
Setting up openvpn (2.4.7-1) ...
[ ok ] Restarting virtual private network daemon.:.
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn.service → /lib/systemd/system/openvpn.service.
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for systemd (241-7~deb10u5) ...
root@CT203:/#

Did you maybe create an unprivileged container and then removed the unprivileged: 1?
Can you try again with an updated debian-10-standard_10.7-1_amd64.tar.gz template and create a privileged container from the start?

Hmm, possibly. I don't remember doing so, and I thought that you couldn't, but if Proxmox lets you than I definitely did as a step to try and fix my Docker, which turned out to be nesting. I'll try creating a new one, thanks!