Thanks for your reply. The issues arose for the first time when I upgraded Debian 10 to 11, though that can also be caused by me using the classic versions of the applications before the upgrade. Is there a way to force apps to run in classic mode?
As mentioned in my original post, the failure of the ‘org.freedesktop.systemd1’ process goes hand in hand with the ‘DENIED’ error from AppArmor. Anything else I can do to tackle that error except for setting up a new AppArmor profile like I already tried?
I already reinstalled snapd after a purge of all files and settings, to no avail.
Edit: I noticed an AppArmor kernel feature issue in the snapd status output, could this be related?
$ systemctl status snapd.service
● snapd.service - Snap Daemon
Loaded: loaded (/lib/systemd/system/snapd.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2022-02-25 13:47:11 CET; 4min 47s ago
TriggeredBy: ● snapd.socket
Main PID: 2003714 (snapd)
Tasks: 32 (limit: 106266)
Memory: 30.1M
CPU: 1.023s
CGroup: /system.slice/snapd.service
└─2003714 /usr/lib/snapd/snapd
Feb 25 13:47:10 BM01-N0113-EXSELL-DEV systemd[1]: Starting Snap Daemon...
Feb 25 13:47:10 BM01-N0113-EXSELL-DEV snapd[2003714]: AppArmor status: apparmor is enabled but some kernel features are missing: dbus, network
Feb 25 13:47:10 BM01-N0113-EXSELL-DEV snapd[2003714]: AppArmor status: apparmor is enabled but some kernel features are missing: dbus, network
Feb 25 13:47:10 BM01-N0113-EXSELL-DEV snapd[2003714]: daemon.go:246: started snapd/2.54.3.2 (series 16; classic; devmode) debian/11 (amd64) linux/5.10.0-11-amd64.
Feb 25 13:47:10 BM01-N0113-EXSELL-DEV snapd[2003714]: daemon.go:339: adjusting startup timeout by 1m35s (pessimistic estimate of 30s plus 5s per snap)
Feb 25 13:47:11 BM01-N0113-EXSELL-DEV systemd[1]: Started Snap Daemon.