Closed struanb closed 2 years ago
Further investigations have revealed that the issue may arise from an interaction between some version combinations of the Linux kernel/Apparmor/Docker. Recent versions of Docker install the docker-default
AppArmor security profile by default for launched containers, and this security profile inhibits the container's access to /var/run/docker.sock
.
While AppArmor can be disabled on a host by adding apparmor=0
to the kernel command line, this is overly unrestrictive and likely to be inappropriate for some environments.
Instead, the AppArmor security profile can be disabled purely for the Dockside container by adding --security-opt=apparmor=unconfined
to the normal Dockside docker run
command line e.g.
mkdir -p ~/.dockside && \
docker run -it --name dockside \
-v ~/.dockside:/data \
-v /var/run/docker.sock:/var/run/docker.sock \
-p 443:443 -p 80:80 \
--security-opt=apparmor=unconfined \
newsnowlabs/dockside --ssl-builtin
This will leave the default Docker AppArmor security profile in operation on devtainers.
As a further extension, should it be deemed necessary, a custom AppArmor security profile for Dockside could also be deployed.
We plan to improve how Dockside tests for /var/run/docker.sock
as it launches, and update the documentation, before closing this issue.
Improved testing that /var/run/docker.sock
responds to API queries is committed at https://github.com/newsnowlabs/dockside/commit/3d203ff355dff20d0dc7402a2f02526a0ab9ef0c and will be included in the next release.
This issues is resolved by Release v1.7.0.
On some systems running Apparmor, Dockside may fail to launch with the following error:
This means that, despite the correct ownership and permissions on the bind-mounted
/var/run/docker.sock
socket, processes within the Dockside container will not allowed to access the socket.