Docker images can't network when using Proxmox kernel

Hi, all. I've got a new OMV4 install that I'm trying to setup. Have installed the Docker GUI plugin from OMV-Extras and am running the Proxmox 4.15 kernels but cannot get any docker images to properly network.

As an example, I installed the nzbget image and tried running it using default settings; although it runs the log outputs the following error:
[ERROR] Binding socket failed for 0.0.0.0: ErrNo 13, Permission denied

If I configure the image to use elevated privileges it will be able to bind the socket without issue and I can connect to it. However, I don't want to be forced to run all docker images with elevated privileges.

Oddly enough, when I switch back to the standard Debian 4.19 kernel the docker image is able to bind sockets without elevated privileges.

Does anyone have any idea what's going on here?

(A little background info in my setup: I've installed OMV ontop of a Deb9 netinstall per the official directions on this forum. I've compared the package list to the standard OMV4 install, and I do have everything, but there may be some configuration differences. However, even if this is the case, docker seems to work fine on the non-ProxMox kernel so things ought to be ok?)

Right, I don't think this necessarily has anything to do with the kernel, but I switched it over and it worked!

What other settings change over when switching kernels?

Zitat von ryecoaaron

When you switch back to the proxmox kernel, it doesn't work again? My docker test box is running the proxmox kernel and I haven't had any issues with containers.

No, once I switch back the containers are unable to change any network settings (either as host or bridge) unless they're run in privileged mode. It's rather confusing and I have no idea where to begin debugging.

I have a test box which as the standard OMV4 image installed and this one doesn't have a problem on either kernel. The only difference between that and my real box is that it was setup as OMV4 installed on Debian 9 netinstall. However, given that the containers are fine on the stock kernel I figure that it should just work on the proxmox kernel.

I have no idea how to troubleshoot this. What could change between kernels?

I took a look at dmesg and noticed that I get this error after attempting to start the docker on the proxmox kernel:

[ 95.284882] audit: type=1400 audit(1552570349.804:8): apparmor="DENIED" operation="create" profile="docker-default" pid=1934 comm="nzbget" family="inet" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"

Unsure if it's related, but during boot, this was also print to dmesg:
[ 17.575713] audit: type=1400 audit(1552570272.092:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="docker-default" pid=1273 comm="apparmor_parser"

The VM that has no issues shows this in dmesg after starting the container -- I think it's related to the container start, at least?
[ 111.840990] Built 1 zonelists, mobility grouping on. Total pages: 242127[ 111.840991] Policy zone: Normal

To be clear, you don't see the DENIED message when running on the proxmox kernel? If so, that makes sense.

Can you please take a look at the output of `aa-status` on your machine?

On my OMV4 clean install I get this when on pve:
root@openmediavault:~# aa-status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Whereas on the Deb9 netinstall I get this on pve:
root@debian:~# aa-status
apparmor module is loaded.
2 profiles are loaded.
2 profiles are in enforce mode.
/usr/sbin/ntpd
docker-default
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

According to the Docker Documentation the docker-default profile is auto-generated, but I haven't been able to figure out what is in there yet, or what is loading it in the Deb9 netinstall and not in the OMV4 install.

Note: it appears that the apparmor parser utility isn't installed in OMV by default so you'll need to `apt-get install apparmor` in order to run the `aa-status` utility.