moby: Incorrect detection of lack of Apparmor installed
Description
Package 23.0.1-1~debian.11~bullseye
on fresh install gives:
AppArmor enabled on system but the docker-default profile could not be loaded:
the app armor is not installed nor enabled
The bug happened after we installed 23 on new node, previous ones on 20 didn’t had the problem
Reproduce
Install docker on fresh debian install
Expected behavior
No response
docker version
Client: Docker Engine - Community
Version: 23.0.0
API version: 1.42
Go version: go1.19.5
Git commit: e92dd87
Built: Wed Feb 1 17:43:17 2023
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 23.0.1
API version: 1.42 (minimum version 1.12)
Go version: go1.19.5
Git commit: bc3805a
Built: Thu Feb 9 19:46:54 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.16
GitCommit: 31aa4358a36870b21a992d3ad2bef29e1d693bec
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker info
Client:
Context: default
Debug Mode: false
Server:
Containers: 53
Running: 4
Paused: 0
Stopped: 49
Images: 7
Server Version: 23.0.1
Storage Driver: overlay2
Backing Filesystem: xfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 31aa4358a36870b21a992d3ad2bef29e1d693bec
runc version: v1.1.4-0-g5fd4c4d
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 5.10.0-21-amd64
Operating System: Debian GNU/Linux 11 (bullseye)
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 29.39GiB
Name: d1-fw-kube20
ID: 91ef61ab-0b63-4f4b-9f6c-6cfb41903247
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Additional Info
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 35 (14 by maintainers)
Commits related to this issue
- Revert "Don't check for apparmor_parser to be present" This reverts commit 1acca8bba36e99684ee3489ea4a42609194ca6b9. As stated in the Godoc, this function is intended to check for presence of `appar... — committed to neersighted/containerd by neersighted a year ago
- Revert "Don't check for apparmor_parser to be present" This reverts commit 1acca8bba36e99684ee3489ea4a42609194ca6b9. As stated in the Godoc, this function is intended to check for presence of `appar... — committed to neersighted/containerd by neersighted a year ago
- Fix issue with lack of apparmor. Recently there are failures observed with docker installations. Newest version (23.x) started to fail to create containers, when there are no tools for apparmor avail... — committed to gryf/devstack-plugin-container by gryf a year ago
- Update git submodules * Update devstack-plugin-container from branch 'master' to 6c468e5293b79e8e75c7810352e46eacd2dd3eb5 - Fix issue with lack of apparmor. Recently there are failures o... — committed to openstack/openstack by gryf a year ago
- Workaround for docker issue More info at https://github.com/moby/moby/issues/44970 — committed to elfosardo/metal3-dev-env by elfosardo a year ago
- Allow metal3-dev-env to run on a generic ubuntu VM - Detect libvirt_domain_type when running in a VM - Install pkg-config for building packages - Install netcat for remote libvirt access - Do not use... — committed to elfosardo/metal3-dev-env by dtantsur 2 years ago
- Allow metal3-dev-env to run on a generic ubuntu VM - Detect libvirt_domain_type when running in a VM - Install pkg-config for building packages - Install netcat for remote libvirt access - Do not use... — committed to elfosardo/metal3-dev-env by dtantsur 2 years ago
- Allow metal3-dev-env to run on a generic ubuntu VM - Detect libvirt_domain_type when running in a VM - Install pkg-config for building packages - Install netcat for remote libvirt access - Do not use... — committed to elfosardo/metal3-dev-env by dtantsur 2 years ago
- Allow metal3-dev-env to run on a generic ubuntu VM - Detect libvirt_domain_type when running in a VM - Install pkg-config for building packages - Install netcat for remote libvirt access - Do not use... — committed to elfosardo/metal3-dev-env by dtantsur 2 years ago
- Allow metal3-dev-env to run on a generic ubuntu VM - Detect libvirt_domain_type when running in a VM - Install pkg-config for building packages - Install netcat for remote libvirt access - Do not use... — committed to elfosardo/metal3-dev-env by dtantsur 2 years ago
- Allow metal3-dev-env to run on a generic ubuntu VM - Detect libvirt_domain_type when running in a VM - Install pkg-config for building packages - Install netcat for remote libvirt access - Do not use... — committed to elfosardo/metal3-dev-env by dtantsur 2 years ago
@nergdron I can confirm that installing
apparmor
package and restarting docker service fixed the problem on my system.After being upgraded on an Armbian system to 23.0.1 a couple of hours ago, docker-ce could no longer start containers. The error message was:
Installing the apparmor package didn’t help. I had to downgrade it to 20.10.23.
I can confirm too that installing apparmor prior to upgrading to 23.0.1 is able to work around the issue.
23.0.2 is out now, and the problem is gone for me. Thanks a lot to everyone involved in fixing it!
Please refrain from “me too,” which is unhelpful (sends needless notifications) and unnecessary (there is a 👍 button, and there is a mitigation).
You can
apt install apparmor
as already discussed in this thread (and then restartdocker
, e.g.systemctl restart docker.service
), or simply setapparmor=0
on the kernel command line.You can set
--security-opt apparmor=unconfined
on the affected containers instead of taking a shotgun approach.This is bit confusing. So did containerd accept the change made by docker? Or did contained fix it - by not trying to load AppArmor on a non-Debian based machine?
@x-yuri I think you need to have AppArmor installed if your distribution supports it, security wise it’s a bad idea not to have AppArmor installed.
oh, yeah, when I checked before I didn’t restart docker after installing apparmor. if I do the following, then my containers keep working:
would definitely love confirmation from @pavelvodrazka, but I think you’ve found it, @neersighted!
Okay, are you able to install
apparmor_parser
(packageapparmor
), restart the daemon, and confirm you are able to start containers? The only thing that changed since 20.10 is that a check we used for/sbin/apparmor_parser
was unintentionally removed.It appears that the fix in 23.0.1 (https://github.com/moby/moby/pull/44902) wasn’t proliferated as far as it needs to be. If you have a working
apparmor_parser
, restart, and still have issues, it will point to deeper issues past the initial and this follow-up RCA.