Docker seccomp error after upgrade from debian 8 to debian 9 - docker

The following error occurs during docker run and docker build after upgrading from Debian 8 to Debian 9:
ERROR: Service 'etherpad' failed to build: OCI runtime create failed: container_linux.go:344: starting container process caused "error loading seccomp filter into kernel: invalid argument": unknown
I was able to solve the problem when running a container by using --seccomp-profile:unconfined but build doesn't support this flag (https://github.com/moby/moby/issues/21105). I also tried to pass it to the daemon via the daemon.json but this caused an error during startup.
Kernel support is enabled:
grep CONFIG_SECCOMP= /boot/config-$(uname -r)
CONFIG_SECCOMP=y
docker info:
Containers: 38
Running: 9
Paused: 0
Stopped: 29
Images: 119
Server Version: 18.09.2
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 275
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9754871865f7fe2f4e74d43e2fc7ccd237edcbce
runc version: 09c8266bf2fcf9519a651b04ae54c967b9ab86ec
init version: fec3683
Security Options:
seccomp
WARNING: You're not using the default seccomp profile
Profile: /root/labs/security/seccomp/seccomp-profiles/default.json
Kernel Version: 3.16.0-7-amd64
Operating System: Debian GNU/Linux 9 (stretch)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.71GiB
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Does anyone have an idea how to solve it? Thank you very much.

TLDR; reboot your server after upgrading to Stretch.
Your issue looks similar to one that I experienced. I received the below error:
OCI runtime create failed: container_linux.go:345: starting container process caused "error loading seccomp filter into kernel: invalid argument": unknown
The issue occurred after upgrading from Jessie to Stretch and installing a fresh copy of Docker (https://docs.docker.com/install/linux/docker-ce/debian/).
I believe your issue is similar because your docker info output shows
Kernel Version: 3.16.0-7-amd64
and for me:
# uname -a
Linux debian 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64 GNU/Linux
Stretch should be using a later kernel version than that, so the fix was:
# reboot
# uname -a
Linux debian 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13) x86_64 GNU/Linux

Related

docker import with Docker for Windows using Linux containers no space left on device error with Storage Driver: overlay2

I'm importing a large database image at 15 GB (I can import an image of 9.5 GB without a problem.) with Docker for Windows using Linux containers. I'm using Windows 10 Pro 1803, build 17134.1006.
Error:
PS C:\WINDOWS\system32> docker import "C:\Users\oscar\Desktop\MSSQL.tar" mssql
Error response from daemon: Error processing tar file(exit status 1): write /var/opt/mssql/data/TestDatabase.mdf: no space left on device
I have removed all dangling volumes and unused images as suggested here:
https://stackoverflow.com/a/37287054/3850405
When reading about storage drivers I came across some limitations for devicemapper and other drivers.
https://docs.docker.com/engine/reference/commandline/dockerd/#options-per-storage-driver
For devicemapper:
Specifies the size to use when creating the base device, which limits
the size of images and containers. The default value is 10G. Note,
thin devices are inherently “sparse”, so a 10G device which is mostly
empty doesn’t use 10 GB of space on the pool. However, the filesystem
will use more space for the empty case the larger the device is.
https://docs.docker.com/engine/reference/commandline/dockerd/#dmbasesize
I can't find any image limitation for overlay2, only 20 GB limit for containers as default.
Specifies the size to use when creating the sandbox which is used for
containers. Defaults to 20G.
I tried to run the example command but I got an error. dockerd is not mapped to command.
C:\>dockerd --storage-opt size=40G
'dockerd' is not recognized as an internal or external command,
operable program or batch file.
https://docs.docker.com/engine/reference/commandline/dockerd/#size
Since it should work anyway I'm not sure I'm on the right path there.
System information:
PS C:\WINDOWS\system32> docker --version
Docker version 19.03.2, build 6a30dfc
PS C:\WINDOWS\system32> docker info
Client:
Debug Mode: false
Server:
Containers: 5
Running: 0
Paused: 0
Stopped: 5
Images: 8
Server Version: 19.03.2
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
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: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 894b81a4b802e4eb2a91d1ce216b8817763c29fb
runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f
init version: fec3683
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.184-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.837GiB
Name: docker-desktop
ID: XD32:TQJ4:EKWP:BPE4:ETXW:XFXE:LB3L:J4WB:PCFR:DAXK:MJ62:47RI
Docker Root Dir: /var/lib/docker
Debug Mode: true
File Descriptors: 28
Goroutines: 42
System Time: 2019-09-17T10:00:50.1259999Z
EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
Storage space should not be an issue:
I should learn to read... read it as 55.29 GB unused. After increasing Disk image max size in Docker -> Settings -> Advanced everything started working.

exec: "docker-runc": executable file not found in $PATH: unknown

Using ubuntu 18.04
after upgrading docker to "Docker version 18.09.0-ce-tp5, build 9eb3d36"
Everything works fine before updating docker
Getting following error on docker-compose up:
ERROR: for mysql_1 Cannot start service mysql: OCI runtime create failed: unable to retrieve OCI runtime error (open /run/containerd/io.containerd.runtime.v1.linux/moby/242793c2e7ad05e93ccff53ae37e5d8b054a72f9c2076c1b480f33929dbb45aa/log.json: no such file or directory): exec: "docker-runc": executable file not found in $PATH: unknown
docker info gives
linux#linux-linux:/$ docker info
Containers: 14
Running: 14
Paused: 0
Stopped: 0
Images: 1091
Server Version: 18.09.0-ce-tp5
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 1038
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: containerd runc
Default Runtime: containerd
Init Binary: docker-init
containerd version: ce243288e27971e324363de8f322d221635a8521 (expected: 468a545b9edcd5932818eb9de8e72413e616e86e)
runc version: 1555a78945e56737bc3d15565191d857ee6fa2b9 (expected: 69663f0bd4b60df09991c08812a60108003fa340)
init version: fec3683
Security Options:
apparmor
Kernel Version: 4.15.0-32-generic
Operating System: Ubuntu 18.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.719GiB
Name: linux-linux
ID: F475:F7JY:3HSG:XLGM:BAPD:CZYD:HRRO:SN3N:SFSX:7XOK:VDZ4:SNMV
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
WARNING: No swap limit support
Using ubuntu 18.04 after upgrading docker to "Docker version 18.09.0-ce-tp5, build 9eb3d36"
The TP# releases are pre beta (I suspect it stands for technical preview). These will have issues, and there were lots of changes with the containerd integration. You can try upgrading to beta1, or go back to the stable 18.06.1 release. You can see the releases here:
https://github.com/docker/docker-ce/releases
Issue:
I faced the same issue.
Solution
first i restart docker,but when i tried to start my container i was having Error response from daemon: OCI runtime create failed: container with id exists:xxxxxxxxxx
but in ps -a it was showing nothing.
while i was able to run the new container using the same id.
than tried
reboot my server and it is working fine.
as you can see in this 2 rows:
containerd version: ce243288e27971e324363de8f322d221635a8521 (expected: 468a545b9edcd5932818eb9de8e72413e616e86e)
runc version: 1555a78945e56737bc3d15565191d857ee6fa2b9 (expected: 69663f0bd4b60df09991c08812a60108003fa340)
docker expects another internal container id as the tagged container has. i guess this causes the problem.
have you tried to rebuild your container?
I faced a similar problem.
Try committing your container.
Then run it again.
e.g.
docker commit RUNNING_CONTAINER IMAGE1
docker run -d IMAGE1
service docker restart solved the problem in my case

Cannot exec to a running container

After running docker container,docker run -d --name nginx nginx, I cannot use "docker exec", docker exec nginx echo 123, on this container.
I'm receiving an error:
ERRO[2018-08-19T11:09:10.909894729+03:00] stream copy error: reading from a closed fifo
ERRO[2018-08-19T11:09:10.909988081+03:00] stream copy error: reading from a closed fifo
ERRO[2018-08-19T11:09:10.931102317+03:00] Error running exec 19c6ae3c5d796180e02577f037f6a1bd1453b70393098643719dea3537933ae2 in container: OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "process_linux.go:86: executing setns process caused \"exit status 22\"": unknown`
OS: ubuntu 14.04
Kernel: 3.13.0-153-generic
Docker: Docker version 18.06.0-ce, build 0ffa825
Docker Info:
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 1
Server Version: 18.06.0-ce
Storage Driver: aufs
Root Dir: /var/lib/docker/165536.165536/aufs
Backing Filesystem: extfs
Dirs: 5
Dirperm1 Supported: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: d64c661f1d51c48782c9cec8fda7604785f93587
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
apparmor
userns
Kernel Version: 3.13.0-153-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 3.86GiB
Name: **************
ID: OL25:ISXX:RWR7:EY76:OQ6O:XLWG:ETWJ:FV2A:MC6A:ROP7:6DWD:DJX4
Docker Root Dir: /var/lib/docker/165536.165536
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Thanks!
That can happen when them use ENTRYPOINT instead of CMD. Check your image/container with "docker inspect". Your commandline argument becomes a CMD of ENTRYPOINT.
https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact
I could reproduce this issue whenever I executed docker run -it opensuse/leap followed by exit command. The container is actually stopped after exit command, but still showed running in docker ps.
Solution: Restart your docker daemon. And then try running your containers once again. If they stop, they won't show running status.
command: service docker restart
This worked in my case.
Please update your Kernel. Although Docker should work with most Kernel 3.10+ versions, there are often low level issues with older Kernels. See also https://github.com/moby/moby/issues/36084#issuecomment-364886573 for a seemingly same issue with a working solution:
updated to HWE ( 4.13.0-32-generic) and exec works again, however keep in mind that stock 16.04 uses 4.4.0 kernels - there should some kind of warning (at least) that specific versions combination will not work

Error on commit - How to increase Docker default container size when using Docker Toolbox and Windows 7

I'm running Docker on Windows 7, so Docker runs within a Virtual Box.
I've got an issue where I've got an Oracle image which has then had a database restored to it, pushing the image size up to 7.5 gigs. I want to do a docker commit on this, but I'm getting an out of space error when I do the commit.
I've seen a lot of posts on changing the default container size, but I'm not sure if this is possible with aufs, or how to change to a different file system type when running on Windows 7/VirtualBox.
Does anyone know how to increase the default container size in this environment ?
Error response from daemon: Error processing tar file(exit status 1): write /u01/app/oracle/oradata/XE/support.dbf: no space left on device
Docker info:
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 72
Server Version: 17.10.0-ce
Storage Driver: aufs
Root Dir: /mnt/sda1/var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 127
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 06b9cb35161009dcb7123345749fef02f7cea8e0
runc version: 0351df1c5a66838d0c392b4ac4cf9450de844e2d
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.4.93-boot2docker
Operating System: Boot2Docker 17.10.0-ce (TCL 7.2); HEAD : 34fe485 - Wed Oct 18 17:16:34 UTC 2017
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.79GiB
Name: default
ID: 2NWU:57WJ:4QAP:EBMY:MMF2:JFWA:IBWU:THGO:A4VD:SGVW:YQBP:MP2N
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 24
Goroutines: 35
System Time: 2017-12-06T09:33:14.736388742Z
EventsListeners: 2
Registry: https://index.docker.io/v1/
Labels:
provider=virtualbox
Experimental: false
Insecure Registries:
127.0.0.0/8
The default size for a docker machine is 20GB, you can double-check by running docker-machine inspect default. This size can be configured when creating the machine from the cli. You can recreate the default machine and set the size as follows:
docker-machine rm default
docker-machine create -d virtualbox --virtualbox-disk-size "400000" default
You can also edit the file C:\Program Files\Docker Toolbox\start.sh to set default values for size and ram for created machines.

Building docker for the ARM-64 architecture

I have been trying to compile docker for the ARM-64 architecture. Docker doesn’t officially support ARM 64-bits (at least not through the package management tools); hence I have to build it from source. Building docker binary set needs docker itself as a dependency. I’ve already managed to compile both the docker daemon and the client via the following (hack) command:
./hack/make.sh dynbinary
However, I haven’t managed to run it successfully. Both binaries are compiled and work, but when I want to start up the daemon it complains about other dependencies:
Failed to connect to containerd. Please make sure containerd is installed in your PATH or you have specified the correct address. Got error: exec: "docker-containerd": executable file not found in $PATH
As I mentioned earlier, I cannot build all the binaries as they need docker itself running.
Looking forward to your help.
Two weeks ago, I was able to install Docker on a Pine64 running Armbian (Debian based). It was as easy as following the official documentation for armhf with one exception, change [arch=armhf] by [arch=arm64] when you add the new apt source.
After the install you have a real Arm64 docker running :
root#pine64:~# docker system info
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 60
Server Version: 17.12.0-ce
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 28
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 89623f28b87a6004d4b785663257362d1658a729
runc version: b2567b37d7b75eb4cf325b77297b140ea686ce8f
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 3.10.107-pine64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 979.6MiB
Name: pine64
ID: xxx
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: xxx
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

Resources