Docker dm_task_run failed error - docker

Today I first time installed docker on Fedora 21. Now, I need change location of docker images folder from default /var/lib/docker.
After copying files (devicemapper subfolder skipped, docker service stopped) and changing /etc/sysconfig/docker (adding -g option), I run docker service again, no problems, devicemapper/metadata created.
Next, I'm trying to pull first image:
docker pull centos
But this error occured:
docker pull centos
latest: Pulling from docker.io/centos
6941bfcbbfca: Download complete
6941bfcbbfca: Error downloading dependent layers
41459f052977: Downloading [==========================> ] 41.61 MB/77.28 MB
fd44297e2ddb: Error pulling image (latest) from docker.io/centos, endpoint: https://registry-1.docker.io/v1/, Driver devicemapper failed to create image rootfs 6941bfcbbfca7f4f48becd38f2639157042bfd44297e2ddb: Error pulling image (latest) from docker.io/centos, Driver devicemapper failed to create image rootfs 6941bfcbbfca7f4f48becd38f2639157042b5cf9ab8c080f1d8b6d047380ecfc: Error running DeviceCreate (createSnapDevice) dm_task_run failed
FATA[0013] Error pulling image (latest) from docker.io/centos, Driver devicemapper failed to create image rootfs 6941bfcbbfca7f4f48becd38f2639157042b5cf9ab8c080f1d8b6d047380ecfc: Error running DeviceCreate (createSnapDevice) dm_task_run failed
If I try this without changing location - ok, no problems.
How to fix it?

1) service docker stop
2) thin_check /home/docker/devicemapper/devicemapper/metadata
3) thin_check --clear-needs-check-flag /home/docker/devicemapper/devicemapper/metadata
4) service docker start

As seen in issue 3721, this generally is a disk space issue.
The problem is that docker rmi doesn't always work in that case:
Getting this in v1.2 on CentOS 6.5 if a disk fills up before the image finishes pulling. Unable to rmi the incomplete image.
One "nuclear" option:
removing everything in /var/lib/docker worked out. Thanks
Another reason can be a common layer of fs to be downloaded between two images.

This was worked for me,
mv -f /var/lib/docker/* /data/tmp
systemctl restart docker.service
docker system prune -a

this could be caused when disk usage got full you can check this by doing df -h if so clean up unwanted space or can prune docker by doing docker system prune once after freeing up space , stop docker because thin_check cannot be run on live metadata.
systemctl stop docker
thin_check /var/lib/docker/devicemapper/devicemapper/metadata
check for error if noting clear check flag by
thin_check --clear-needs-check-flag /var/lib/docker/devicemapper/devicemapper/metadata
then start docker
systemctl start docker.service
if thin check not installed
yum install -y device-mapper-persistent-data
for centos
apt-get install -y thin-provisioning-tools

Got this today.
sudo reboot
Problem's out.

I encounter another dm_task_run issue during docker import, for my case, I yum erase docker.x86_64; yum install docker.x86_64; systemctl start docker.service works.

Related

Getting error while running local docker registry

I am getting while running local docker registry on centos system. I am explaining the error below.
docker: Error response from daemon: lstat /var/lib/docker/overlay2/3202584ed599bad99c7896e0363ac9bb80a0385910844ce13e9c5e8849494d07: no such file or directory.
I am setting of the local registry like below.
vi /etc/docker/daemon.json:
{ "insecure-registries":["ip:5000"] }
I have the registry image installed my system and I am running using the below command.
docker run -dit -p 5000:5000 --name registry bundle/tools:registry_3.0.0-521
I have cleaned all volume as per some suggestion from google but still same issue. Can anybody help me to resolve this error.
The error is not related to the registry and is happening in the client side because of local caching (or some other docker-related issue) in your system.
I've seen this error a lot in the docker community and the most suggested approach to solve this error is to clean up the whole /var/lib/docker directory.
On your local client system, if you don't care about your current containers, images, and caches, try stopping the docker daemon, removing the whole /var/lib/docker directory, and starting it again:
Note that sometimes it gets fixed by only restarting the daemon, so it worths trying it first:
sudo service docker restart
If a simple restart can't solve the problem, go ahead and destroy it:
sudo service docker stop
sudo rm -rf /var/lib/docker
sudo service docker start
(I'm not sure about if these systemd commands will work on your CentOS too)

docker compose down fails due to "permission denied"

On running docker-compose stop it fails to stop the docker images, and gives an error like this:
ERROR: for nginx cannot stop container: 5f5ed6d2110a0d845508ede160d8196d3e01f1d677e22e4944adc8c984800cff: Cannot kill container
5f5ed6d2110a0d845508ede160d8196d3e01f1d677e22e4944adc8c984800cff: Unknown error after kill: docker-runc did not terminate sucessfully: container_linux.go:393: signaling init process caused "Permission Denied": unknown
The images are still running properly, they just don't restart. I am running docker-compose on Ubuntu.
I was able to work around the problem by running:
sudo killall docker-containerd-shim
And then docker-compose down started working for me.
I found the solution in this bug report, and it seems that it involves a backport of a fix to the runc code.
EDIT
It seems that the root cause of these problems on my system was the Docker snap image on my Ubuntu 18.04 installation. I completely removed the snap image and reinstalled Docker using https://get.docker.io, and I no longer encounter these problems. In the meantime, the rest of my answer above worked for me as a workaround.
Somehow this worked for me.
$ sudo killall containerd-shim
2021: in my case, I am using the
sudo aa-remove-unknown
then, run
sudo docker-compose down
then, the application down successfully
I had the same problem and what helped me was to kill all of my containers, delete all of my images and data volumes, and start over.
If you have no problem DELETING all of your data volumes and all of your unused images, you can try these two commands:
sudo service docker restart
docker system prune --all --volumes
There is such a solution.
Stop and restart docker services
sudo systemctl stop docker.socket
sudo systemctl stop docker
sudo systemctl restart docker
After check -> docker ps
if cant be deleted to containers then try this -> docker container rm container_name --force
Ports may not have been deleted. this will cause conflict.
Find used port PID -> sudo lsof -i:port
and kill sudo kill -9 PID

Docker - ERROR: failed to register layer: symlink

I'm running a docker-compose file we have, I usually run it with command:
docker-compose up
But today I'm getting this error.
ERROR: failed to register layer: symlink ../bdf441e8145a625c4ab289f13ac2274b37d35475b97680f50b7eccda4328f973/diff /var/lib/docker/overlay2/l/7O5XKRTJV6RMTXBV5DTPDOHYNX: no such file or directory
To solve this issue, you just Stop and Start docker service from terminal.
# service docker stop
# service docker start
For me, this issue came up when I tried to clear the lib/docker/overlay folder by deleting all its contents (not a good thing to do). After that, I was not able to build any of my images back.
Solved it by running this
docker system prune --volumes -a
Warning: This removes all the volumes and its contents which may result in data loss. Which was fine for me since I already deleted everything.
Followed this answer just restarting docker fixed the problem.
https://stackoverflow.com/a/35325477/4031815
Restart docker or if that doesn't work, do a Docker > Reset > Remove all Data.
I got the same error and the latter is the only thing that ended up working for me.
What worked for me and did not involve losing all my data:
Make sure all docker containers are down: docker compose down
Remove problematic overlay2: sudo rm -R /var/lib/docker/overlay2
Remove images: sudo rm -R /var/lib/docker/image
Clear any other cached data: docker system prune -f
Restart docker service: systemctl restart docker
Close and reopen VS Code
Then, docker compose build finally worked fine for me

Error: "error creating aufs mount to" when building dockerfile

I get this error when I try to build a docker file
error creating aufs mount to /var/lib/docker/aufs/mnt
/6c1b42ce1a98b1c0f2d2a7f17c196221445f1054566065d4c607e4f1b99930eb-init:
invalid argument
What does it mean? How do I fix it?
I had some unresolved errors after removing /var/lib/docker/aufs, which a couple extra steps cleared up.
To add to #benwalther answer, since I lack the reputation to comment:
# Cleaning up through docker avoids these errors
# ERROR: Service 'master' failed to build:
# open /var/lib/docker/aufs/layers/<container_id>: no such file or directory
# ERROR: Service 'master' failed to build: failed to register layer:
# open /var/lib/docker/aufs/layers/<container_id>: no such file or directory
docker rm -f $(docker ps -a -q)
docker rmi -f $(docker images -a -q)
# As per #BenWalther's answer above
sudo service docker stop
sudo rm -rf /var/lib/docker/aufs
# Removing the linkgraph.db fixed this error:
# Conflict. The name "/jenkins_data_1" is already in use by container <container_id>.
# You have to remove (or rename) that container to be able to reuse that name.
sudo rm -f /var/lib/docker/linkgraph.db
sudo service docker start
If you try to use docker inside a persistent enable Live CD, you may encounter this error. I guess, it is due to the fact that you can't mount aufs inside overlayfs mounts, which is the persistent layer.
The solution was simply using different driver. I've used vfs in /etc/docker/daemon.json
Here it is
{
"storage-driver": "vfs"
}
I have removed /var/lib/docker/aufs/diff and got the same problem:
error creating aufs mount to /var/lib/docker/aufs/mnt/blah-blah-init: invalid argument
It solved by running the following commands:
docker stop $(docker ps -a -q);
docker rm $(docker ps -a -q);
docker rmi -f $(docker images -a -q)
AUFS is unable to mount the docker container filesystem.
This is either because: the path is already mounted - or - there's a race condition in docker's interaction with AUFS, due to the large amount of existing volumes.
To solve this, try the following:
restart the docker service or daemon and try again.
check mount for aufs mounted on any paths under /var/lib/docker/aufs/. If found, stop docker, then umount them (need sudo).
example:
mount
none on /var/lib/docker/aufs/mnt/55639da9aa959e88765899ac9dc200ccdf363b2f09ea933370cf4f96051b22b9 type aufs (rw,relatime,si=5abf628bd5735419,dio,dirperm1)
then
sudo umount /var/lib/docker/aufs/mnt/55639da9aa959e88765899ac9dc200ccdf363b2f09ea933370cf4f96051b22b9
If that doesn't work, stop docker, then sudo rm -rf /var/lib/docker/aufs. You will lose any existing stopped containers and all images. But this is just about guaranteed to solve the problem.
Unfortunately on my system I could not resolve this with the above answers. The docker administration kept remembering a certain file in the aufs layer that it couldn't reach anymore. Other solutions didn't work either. So if this is an option for you, you could try the following fix: uninstall/purge docker and docker-engine:
apt-get purge docker docker-engine
Then make sure everything from /var/lib/docker is removed.
rm -rf /var/lib/docker
After that install docker again.
I'm using Raspbian with Raspberry 4
Best way to do it..
Check your docker version with:
sudo docker info and check "Storage Driver"
sudo systemctl stop docker
sudo nano /etc/docker/daemon.json
write this code below and save it
{
"storage-driver": "vfs"
}
sudo systemctl start docker
altought vfs... has a performance issue and could not be the best choice... :)
I just had a similar issue on Lubuntu (Ubuntu 4.15.0-20-generic) with Docker CE 18.03. None of the described options helped.
It appears that latest docker versions use the overlay2 storage driver. However some applications require aufs. Thus a possible fix might be to simply use this docker guide to change the storage driver to aufs (simply replace "overlay2" with "aufs") as in this guide.
I am running a container inside another container(also installed docker in that container) and is trying to create an aufs storage on top of an overlayfs mount, which is not possible. So, I also change the host overlyfs storage to aufs. It's solve my issue. To check storage driver use below command.
docker info
The solution was simply using different driver. I've used aufs in /etc/docker/daemon.json
Here it is
{
"storage-driver": "aufs"
}
For detailed explanation read below documentation.
Docker storage documentation
A similar issue arose while I was using Docker in Windows:
ERROR: Service 'daemon' failed to build: error creating overlay mount
to /var/lib/docker/overlay2/83c98f716020954420e8b89e6074b1af6
1b2b86cd51ac6a54724ed263b3663a2-init/merged: no such file or directory
The problem occurred after having removed a volume from the image's Dockerfile, rebuilding the image and then rebooting the PC. Maybe this is a common cause?
I managed to solve the problem by clicking Docker -> Settings -> Reset -> Reset to factory defaults...
All my images were subsequently lost but that didn't matter for me. I also figured that removing the VM disk image (the path to which can be found under the Advanced tab in Settings) could solve the issue. I haven't tried this approach however.
In windows after a restart, docker machine problem is solved for me.
Use these commands:
docker-machine stop
docker-machine start
docker-compose up
I put this answer also here, as the google search lead me here since the #whitebrow's answer contains what term I searched for in google
ERROR: Service '***' failed to build: error creating overlay mount
to /var/lib/docker/overlay2/***/merged: no such file or directory
In my case, the working workaround surprisingly was to restrict the number of 'RUN' docker building commands/layers, since if the number surpassed 60 layers/commands, it always ended up with that missing 'merged' folder error, no matter what was the contents of the command, even simple command such as RUN ls -la ended up with that error, if the total number of such/any commands was higher than about 60, strange. Merged subfolder was always missing, though even when I automatically generated all the merged subfolders, always was created on the fly a new layer with a new hash, which was missing that subfolder.
I faced the same issue.I resolved it by adding the storage driver to /etc/docker/daemon.json
you can refer this link as well to see other driver options.
Visit https://docs.docker.com/storage/storagedriver/select-storage-driver/

docker push of a 1.2 GB image

I went through the list of debian packages in bio-ngs (http://blends.debian.org/med/tasks/bio-ngs) and tried to install them in a docker container based on Ubuntu Precise.
I did it manually by doing a sudo docker run [...] /bin/bash and doing apt-get install on each package.
I then tried to docker commit and docker push the container with everything in bio-ngs, and it tried to upload the 1.215 GB of data in one go.
A few seconds after starting the process, it failed with this error:
4160cce5fef0: Pushing [=> ] 24.42 MB/1.215 GB 1h6m34s
2014/02/19 17:07:37 Failed to upload layer: Put https://registry-1.docker.io/v1/images/4160cce5fef01ae777b856c15a42e0a632021d1891c33f29018024e35aed60be/layer: write tcp 54.224.119.89:443: broken pipe
Any ideas?

Resources