Failed to register layer error processing tar file

Description I'm using docker on windows 7 via docker toolbox , when trying to pull a big image of 4 Go I get the following output latest: Pulling from preintv2 50655cf8037a: Extracting [=======...

Description
I’m using docker on windows 7 via docker toolbox , when trying to pull a big image of 4 Go I get the following output
latest: Pulling from preintv2
50655cf8037a: Extracting [==================================================>] 4.055 GB/4.055 GB
failed to register layer: Error processing tar file(exit status 1): write file : no space left on device

What I find unusual is that when I type df -h :

$ df -h
Filesystem Size Used Avail Use% Mounted on
C:/Program Files/Git 239G 187G 52G 79% /
U: 3,0T 2,5T 494G 84% /u
V: 20G 8,4G 11G 44% /v
X: 14G 2,2G 11G 17% /x
Z: 16G 37K 16G 1% /z

in the partition /u the size is 3.0T I don’t know from where it comes , in my windows C:/ partition it remains only 80Go .

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

$ docker version
time="2017-04-25T15:39:42+02:00" level=info msg="Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows"
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Tue Mar 28 00:40:02 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.04.0-ce
 API version:  1.28 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   4845c56
 Built:        Wed Apr  5 18:45:47 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:

$ docker info
time="2017-04-25T15:22:02+02:00" level=info msg="Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows"
Containers: 6
 Running: 0
 Paused: 0
 Stopped: 6
Images: 2
Server Version: 17.04.0-ce
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 26
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary:
containerd version: 422e31ce907fd9c3833a38d7b8fdd023e5a76e73
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.4.59-boot2docker
Operating System: Boot2Docker 17.04.0-ce (TCL 7.2); HEAD : c69677f - Thu Apr  6 16:26:16 UTC 2017
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 995.8 MiB
Name: default
ID: CYXK:K7TN:O3OZ:SVML:FCLM:PLSB:SL4P:2ZF4:7VF2:H6UM:W2YI:FIW6
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 17
 Goroutines: 26
 System Time: 2017-04-25T13:22:02.240737949Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

I needed space and executed: docker rmi $(docker images -f "dangling=true" -q)

Since then I can’t with docker-compose: docker-compose build, I get the error: ERROR: Error processing tar file(exit status 1): unexpected EOF.

I tried to remove all images, reinstall docker, but nothing will do: always the same error, after quite some time.

I built on another system and it worked, which suggests that this is a wrong-state issue.

Any idea what I should clean?

Using:

▶ docker version
Client:
 Version:      17.03.0-ce
 API version:  1.24 (downgraded from 1.26)
 Go version:   go1.7.5
 Git commit:   3a232c8
 Built:        Tue Feb 28 08:01:32 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.6
 API version:  1.24 (minimum version )
 Go version:   go1.6.2
 Git commit:   78d1802
 Built:        Tue Jan 31 23:35:14 2017
 OS/Arch:      linux/amd64
 Experimental: false

▶ docker-compose version
docker-compose version 1.11.2, build dfed245
docker-py version: 2.1.0
CPython version: 2.7.13
OpenSSL version: OpenSSL 1.0.1t  3 May 2016

asked Mar 14, 2017 at 11:11

Augustin Riedinger's user avatar

2

I had the same issue and the approved answer didn’t work for me.

Turns out I had a file with permissions which didn’t allow the user running docker-compose to read it. After removing the file everything was OK

answered Jul 11, 2017 at 15:16

Oktav's user avatar

9

There is an built in command to remove unused images (Version 1.13+):

docker image prune

Now to handle the situation:

  • Stop Docker Service

    systemctl stop docker
    
  • Backup /var/lib/docker then:

  • Remove /var/lib/docker
    Caution: This will remove images, containers, volumes, … make sure you back it up first.

    rm -rf /var/lib/docker
    
  • Start Docker service

    systemctl start docker  
    

Update:

As noted in the other answer, In somecases it might be file permissions issue. Please review permissions.

answered Mar 14, 2017 at 12:16

Farhad Farahi's user avatar

Farhad FarahiFarhad Farahi

33.7k7 gold badges75 silver badges69 bronze badges

7

For me it was a permission error.
I walked against the same exact issue as PR,
ERROR: Error processing tar file(exit status 1): unexpected EOF
My solution is dirty but worked for me

chown -R 777 /foo/bar/project

You almost always want to avoid to set permissions on 777, 655 is more reasonable.

0 = ---
1 = --x
2 = -w-
3 = -wx
4 = r-
5 = r-x
6 = rw-
7 = rwx

A more detailed explanation can be found here:
https://www.pluralsight.com/blog/it-ops/linux-file-permissions

answered Dec 26, 2018 at 1:44

0x78f1935's user avatar

0x78f19350x78f1935

4056 silver badges10 bronze badges

Solving this error for good

docker build needs read access to every file in the context directory tree. To avoid permission issues, add all your mounted directories to .dockerignore file except those required for the build. For example, for this docker-compose file:

version: '3'
services:
    myservice:
        build: .
    volumes:
        - './etc:/etc/myservice'
        - './log:/var/log/myservice'

Add a .dockerignore file with this content:

/etc
/log

The problem will go away no matter the permissions of the files in your mounted directories.

How to get a more informative error

The docker-compose error is not very informative so you can try to run docker on each build just to get detailed information:

$ docker build .

You will get an error like this:

error checking context: 'no permission to read from '/home/david/docker/myservice/log/2020161.log'.

answered Jun 9, 2020 at 13:27

David's user avatar

DavidDavid

2,84231 silver badges16 bronze badges

For me the issue turned out that a Docker Pull was hung, so I CTRL+C’d out of it and tried again. Same error message.

In the end I found some files owned by root in this directory. Giving the files proper permissions fixed the issue.

chown -R <username>:<group> /var/lib/docker/tmp

  • MAC Docker version 17.12.0-ce, build c97c6d6

answered Feb 14, 2018 at 2:42

BJH's user avatar

1

there could be several different problems. You can find out the problem by checking the issue that docker build is throwing.

The problem is that docker-compose build will suppress the information of the issue. To find out what the issue is

do not use:

docker-compose build XXX

instead, open your docker-compose.yml, find the build: tag of the service is giving you an issue, e.g.

services:
   yourservice: 
       build: yourservice-directory/

and then run:

docker build yourservice-directory

after this you will see what is the issue.

Pang's user avatar

Pang

9,365146 gold badges85 silver badges121 bronze badges

answered Jan 28, 2020 at 7:30

useless's user avatar

uselessuseless

1,84217 silver badges16 bronze badges

1

answered Jan 24, 2019 at 20:10

Padmini C's user avatar

Padmini CPadmini C

1191 silver badge3 bronze badges

If you have tried looking through permissions, docker reset, docker system prune, deleting all containers, deleting all images (dangling or otherwise), reading about everything that there is surrounding this issue and have had no success. Try uninstalling docker and re-installing the stable version.

Although, the error I was struggling with was : Error processing tar file(exit status 1): mkdir /some/path/name: no such file or directory

answered Mar 15, 2018 at 15:42

Sheetal Kaul's user avatar

Sheetal KaulSheetal Kaul

2,8992 gold badges13 silver badges6 bronze badges

1

In my case, the problem was a .dump file created by one of my project’s scripts.

docker-compose passes the context to the engine as a tar file, therefore, the build command was packing a tar (the .dump file) inside another tar file (the docker context) hence throwing an unexpected EOF on the context.

Since I don’t need the .dump file in the container, I added it to my .dockerignore file.

answered Sep 11, 2018 at 20:14

Pablo Carbajal's user avatar

I was having the same issue when i changed the Dockerfile location in a python project. I tried the accepted answer and didn’t work for me.

I resolved the problem by running :

find . | grep -E "(__pycache__|.pyc|.pyo$)" | xargs sudo rm -r

On the project root.

The problem was that docker-compose build was trying to read files inside pycache folders.

Maybe this also can be fixed with a proper use of .dockerignore but i dind’t try it

Hope this helps.

Saludos.

answered Nov 26, 2019 at 17:45

Nazareno Castro's user avatar

Try increasing the memory for Docker, it fixed the issue for me.

Docker memory setting in Preferences was set to 2GB, so when pulling the ~3GB image, I was getting exactly this error:

$ docker pull skymindops/skil-ce
latest: Pulling from skymindops/skil-ce
118c5f2883d6: Pull complete 
3d199b2e6224: Extracting [==================================================>]  2.902GB/2.902GB
failed to register layer: Error processing tar file(exit status 1): unexpected EOF

Increasing the memory limit fixed it (I also increased the swap, but unsure was it required or not).

answered Apr 5, 2018 at 10:39

Rosty's user avatar

RostyRosty

1195 bronze badges

1

I tried everything from rebooting, reinstalling Docker, and purging /var/lib/docker.

My cause was something corrupting the build context in my project. After I ran git clean to reset the project directory back to its original state, I was able to docker-compose.

Run git clean -iXd in your project’s root to interactively git clean.

Edit: after a while, it happened again. This time, git clean didn’t fix it. I’m pretty sure it only happens on Ubuntu. My arch coworkers have never encountered it.

answered Aug 1, 2019 at 17:16

Ammar Bandukwala's user avatar

I found a temporary solution:

  1. Ensure specify the image name on docker-compose.yml
    for example, specify the image name and container_name as django_practice_db/django_practice_web

    services:
      django_practice_db:
        image: postgres
        container_name: django_practice_db
      django_practice_web:
        container_name: django_practice_web
        build: .
        command: pipenv run python manage.py runserver 0.0.0.0:8000
    
  2. Copy the project file to another place

  3. Go inside the copied project directory

  4. Execute docker-compose build

  5. Go back to the original project directory

  6. Execute docker-compose up

Not sure why I can build images when I change the folder path.

Pang's user avatar

Pang

9,365146 gold badges85 silver badges121 bronze badges

answered Oct 12, 2019 at 5:51

Kant Chen's user avatar

Kant ChenKant Chen

1231 silver badge6 bronze badges

Another potential cause of this, especially if you’re seeing an error like

Error processing tar file(exit status 1): write /code/node_modules/xxx: no space left on device

You might want to check the «disk image size» in the Docker application. You might need to increase the disk size.

answered Feb 5, 2021 at 13:55

Nik Barres's user avatar

Nik BarresNik Barres

5231 gold badge8 silver badges18 bronze badges

I had the same error in Ubuntu: Ran below command and it worked (just make sure to start again once you are done):

/opt/McAfee/ens/tp/init/mfetpd-control.sh stop

answered Mar 1, 2021 at 7:00

user2814010's user avatar

Solve for me. You need have your user in docker group (usermod -aG docker $USER):

sudo chmod -R 775 .
sudo chown -R : .

answered Jun 13, 2021 at 10:57

makiolo's user avatar

makiolomakiolo

1761 silver badge4 bronze badges

This question is a little bit old now, but I had this problem today and what I figured out was next. When I was exporting my image as a tar file with next command:

docker save -o exportedfile.tar myimage/version:latest

I exported this in Linux shell instead of CMD. When I do it in CMD everything works fine. I guess there is some difference in -o flag between Windows and Linux.

answered Aug 23, 2022 at 13:59

Ryukote's user avatar

RyukoteRyukote

7371 gold badge9 silver badges25 bronze badges

For me, I replaced the .tar file and tried to build again and it worked.

answered Nov 21, 2022 at 1:09

Barbaros's user avatar

I had the same issue as OP, but neither the approved answer nor the top voted answer did it for me.

What pointed me in the right direction was a comment under the approved answer by JGlass saying that after closing Notepad++ everything worked properly.

I wasn’t using Notepad++, but I did have Visual Studio open. I didn’t have any files open either, but I did have the project open in the solution explorer. After closing Visual Studio, the issue was resolved.

In my case it wasn’t a permission issue, but Docker was unable to access the file because another application was using it.

Hopes this helps someone.

answered Jan 30 at 17:13

mike.slomczynski's user avatar

I am on Manjaro.

I keep getting:

failed to register layer: Error processing tar file(exit status 1): write /usr/lib/x86_64-linux-gnu/libvlccore.so.9.0.0: no space left on device

while downloading:

docker pull kdeneon/all

This is the output of df -H

Filesystem      Size  Used Avail Use% Mounted on
dev             2.6G     0  2.6G   0% /dev
run             2.6G  930k  2.6G   1% /run
/dev/dm-0        16G   11G  4.8G  69% /
tmpfs           2.6G   39M  2.6G   2% /dev/shm
tmpfs           2.6G     0  2.6G   0% /sys/fs/cgroup
tmpfs           2.6G   48M  2.6G   2% /tmp
/dev/dm-1        18G  631M   17G   4% /home
tmpfs           514M  4.1k  514M   1% /run/user/1000

I have even symlinked the images directory from /var/lib/docker/image to /home/newbie/docker/image. Since /home has only 4% usage.

ls -l /var/lib/docker/image
lrwxrwxrwx 1 root root   26 Mar  9 07:32 image -> /home/newbie/docker/image/

This has no effect.

What else can I do ? Why is this happening ?

asked Mar 9, 2020 at 2:24

ng.newbie's user avatar

4

The correct way to solve this problem is to move the docker data directory to another location where there is sufficient space. In my case this was my home partition.

To do that I had to create a daemon.json file in /etc/docker and add the following lines to it:

{
    "data-root": "/home/newbie/docker_data"
}

Then restart the docker service, if you are suing systemd this should be:

systemctl restart docker

answered Mar 11, 2020 at 10:54

ng.newbie's user avatar

ng.newbieng.newbie

1,0256 gold badges16 silver badges26 bronze badges

0

I was experiencing the same error on a Mac computer without Docker Desktop. And moving the docker data directory did not work for me.

This is what worked for me using minikube.

minikube stop && minikube delete // this is required
minikube start --memory=16384 --cpus=8 --disk-size='80000mb'
eval $(minikube docker-env)

Then try your docker pull... again.

answered Feb 17, 2022 at 22:04

vromancas's user avatar

1

I am trying to run Docker hello-world on armel platform. However, I am getting tar: invalid argument error as shown. I am Running Docker in chroot environment. Hoping to get some pointers…

#./docker run hello-world
DEBU[2019-05-27T13:59:01.403488020Z] Calling GET /_ping

DEBU[2019-05-27T13:59:01.406786120Z] Calling POST /v1.39/containers/create

DEBU[2019-05-27T13:59:01.407900660Z] form data: 
{"AttachStderr":true,"AttachStdin":false,"AttachStdout":true,"Cmd":null,"Domainname":"","Entrypoint":null,"Env":[],"HostConfig":{"AutoRemove":false,"Binds":null,"BlkioDeviceReadBps":null,"BlkioDeviceReadIOps":null,"BlkioDeviceWriteBps":null,"BlkioDeviceWriteIOps":null,"BlkioWeight":0,"BlkioWeightDevice":[],"CapAdd":null,"CapDrop":null,"Cgroup":"","CgroupParent":"","ConsoleSize":[0,0],"ContainerIDFile":"","CpuCount":0,"CpuPercent":0,"CpuPeriod":0,"CpuQuota":0,"CpuRealtimePeriod":0,"CpuRealtimeRuntime":0,"CpuShares":0,"CpusetCpus":"","CpusetMems":"","DeviceCgroupRules":null,"Devices":[],"DiskQuota":0,"Dns":[],"DnsOptions":[],"DnsSearch":[],"ExtraHosts":null,"GroupAdd":null,"IOMaximumBandwidth":0,"IOMaximumIOps":0,"IpcMode":"","Isolation":"","KernelMemory":0,"Links":null,"LogConfig":{"Config":{},"Type":""},"MaskedPaths":null,"Memory":0,"MemoryReservation":0,"MemorySwap":0,"MemorySwappiness":-1,"NanoCpus":0,"NetworkMode":"default","OomKillDisable":false,"OomScoreAdj":0,"PidMode":"","PidsLimit":0,"PortBindings":{},"Privileged":false,"PublishAllPorts":false,"ReadonlyPaths":null,"ReadonlyRootfs":false,"RestartPolicy":{"MaximumRetryCount":0,"Name":"no"},"SecurityOpt":null,"ShmSize":0,"UTSMode":"","Ulimits":null,"UsernsMode":"","VolumeDriver":"","VolumesFrom":null},"Hostname":"","Image":"hello-world","Labels":{},"NetworkingConfig":{"EndpointsConfig":{}},"OnBuild":null,"OpenStdin":false,"StdinOnce":false,"Tty":false,"User":"","Volumes":{},"WorkingDir":""}

Unable to find image 'hello-world:latest' locally

DEBU[2019-05-27T13:59:01.413317800Z] Calling GET /v1.39/info

WARN[2019-05-27T13:59:01.414791760Z] Could not get operating system name: Error opening /usr/lib/os-release: open /usr/lib/os-release: no such file or directory

DEBU[2019-05-27T13:59:01.438037600Z] Calling POST /v1.39/images/create?fromImage=hello-world&tag=latest

DEBU[2019-05-27T13:59:01.438664080Z] Trying to pull hello-world from https://registry-1.docker.io v2

DEBU[2019-05-27T13:59:02.340561960Z] Pulling ref from V2 registry: hello-world:latest

DEBU[2019-05-27T13:59:02.340799640Z] docker.io/library/hello-world:latest resolved to a manifestList object with 9 entries; looking for a unknown/arm match

DEBU[2019-05-27T13:59:02.340851620Z] found deprecated partial match for linux/arm/v8 with media type application/vnd.docker.distribution.manifest.v2+json, digest sha256:1e44d8bca6fb0464794555e5ccd3a32e2a4f6e44a20605e4e82605189904f44d
DEBU[2019-05-27T13:59:02.340898100Z] found deprecated partial match for linux/arm/v8 with media type application/vnd.docker.distribution.manifest.v2+json, digest sha256:d1fd2e204af0a2bca3ab033b417b29c76d7950ed29a44e427d1c4d07d14f04f9

DEBU[2019-05-27T13:59:02.340938600Z] found multiple matches in manifest list, choosing best match sha256:1e44d8bca6fb0464794555e5ccd3a32e2a4f6e44a20605e4e82605189904f44d
latest: Pulling from library/hello-world

DEBU[2019-05-27T13:59:02.498004860Z] pulling blob "sha256:590e13f69e4afcc08e9060a320ec5e4622d2771ace9dc26b024dc786fcb5b36e"
590e13f69e4a: Downloading 1.027kB/1.027kB
590e13f69e4a: Extracting 1.027kB/1.027kB
590e13f69e4a: Extracting 1.027kB/1.027kB

DEBU[2019-05-27T13:59:03.433254360Z] Cleaning up layer 22e8d4d817b6220a7884a028ba7b1e52b09f83b760a34acc3b9ffaf07f1f4cc4: Error processing tar file(exit status 1): invalid argument

INFO[2019-05-27T13:59:03.434607560Z] Attempting next endpoint for pull after error: failed to register layer: Error processing tar file(exit status 1): invalid argument

./docker: failed to register layer: Error processing tar file(exit status 1): invalid argument.

See './docker run --help'.

#./docker info
DEBU[2019-05-27T14:15:14.212268660Z] Calling GET /_ping

DEBU[2019-05-27T14:15:14.213233780Z] Calling GET /v1.39/info

WARN[2019-05-27T14:15:14.214784160Z] Could not get operating system name: Error opening /usr/lib/os-release: open /usr/lib/os-release: no such file or directory

Containers: 0

Running: 0

Paused: 0

Stopped: 0

Images: 0

Server Version: 18.09.4

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 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: bb71b10fd8f58240ca47fbb579b9d1028eea7c84

runc version: 2b18fe1d885ee5083ef9f0838fee39b62d653e30

init version: fec3683

Kernel Version: 4.1.51-ws-symbol

OSType: linux

Architecture: aarch64

CPUs: 2

Total Memory: 870.7MiB

Name: (none)

ID: AWJE:2XHF:F6IX:AFBY:RKSO:ZAD5:QORR:OWBG:RXWM:UHBC:24JT:PT55

Docker Root Dir: /mnt/usb/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

WARNING: No cpu cfs quota support

WARNING: No cpu cfs period support


0

3

docker pull vimagick/privoxy

Using default tag: latest

latest: Pulling from vimagick/privoxy

8e3ba11ec2a2: Extracting 

[==================================================>]  

2.207MB/2.207MB

36c2a994d09d: Download complete 

821b025e6874: Download complete 

failed to register layer: Error processing tar file(exit 
status 1): invalid argument

перед chroot монтируются следующие каталоги:

ChrootDir=$1;

if [ -z $ChrootDir ]; then
{
        echo 'Please specify a non null $ChrootDir';
        exit 1;
}
fi;

bind_dir()
{                                                                                           
        DirName=$1;                                                                         
        MountPoint=$ChrootDir""$DirName;                                                    
        umount $MountPoint; >> /dev/null;                                                   
                                                                                            
        mkdir -p $MountPoint;                                                               
        mount --bind $DirName $MountPoint;                                                  
}                                                                                           


bind_file()
{
        FileName=$1;
        MountPoint=$ChrootDir""$FileName;
        umount $MountPoint; >> /dev/null;

        mount --bind $FileName $MountPoint;
}



bind_system()
{

        mkdir -p $ChrootDir/sys $ChrootDir/proc $ChrootDir/dev $ChrootDir/usr/src $ChrootDir/lib/modules $ChrootDir/utils $ChrootDir/download $ChrootDir/home $ChrootDir/var/run2;

        bind_dir /sys;
        bind_dir /proc;
        bind_dir /dev;
        bind_dir /dev/pts;
        bind_dir /usr/src;
        bind_dir /lib/modules;
        bind_dir /utils;

        bind_dir /download;
        bind_dir /home;
        bind_dir /var/run2/mysqld;



        bind_dir /data_root;
#       bind_dir /data_root/data/versions;
#       bind_dir /data_root/data/domains;

#       bind_file /etc/passwd;
#       bind_file /etc/group;
#       bind_file /etc/shadow;

        bind_file /etc/hosts;
        bind_file /etc/hostname;
        bind_file /etc/localtime;
        bind_file /etc/timezone;
        bind_file /etc/resolv.conf;
#       bind_file /root/.Xauthority;

}

bind_system;

When starting a container, you may see this error message:

failed to register layer: Error processing tar file (exit status 1): container id 1000000 cannot be mapped to a host id

This document explains the problem and how to fix it.

Background

The user namespace (userns) is a feature of the Linux kernel that adds another security layer to Linux containers. The userns allows a host machine to run containers outside its UID/GID namespace. This means all containers can have a root account (UID 0) in their own namespace and run processes without receiving root privileges from the host machine.

When a userns is created, the Linux kernel provides a mapping between the container and the host machine. For example, if you start a container and run a process with UID 0 inside of it, the Linux kernel maps the container’s UID 0 to a non-privileged UID on the host machine. This allows the container to run a process as if it were the root user, while actually being run by the non-root user on the host machine.

Problem

The error is caused by a userns remapping failure. CircleCI runs Docker containers with userns enabled in order to securely run customers’ containers. The host machine is configured with a valid UID/GID for remapping. This UID/GID must be in the range of 0 — 65535.

When Docker starts a container, Docker pulls an image and extracts layers from that image. If a layer contains files with UID/GID outside of the accepted range, Docker cannot successfully remap and fails to start the container.

Solution

To fix this error, you must update the files’ UID/GID and re-create the image.

If you are not the image maintainer, congratulations: it’s not your responsibility. Contact the image maintainer and report the error.

If you are the image maintainer, identify the file with the high UID/GID and correct it. First, grab the high UID/GID from the error message. In the example presented at the top of this document, this value is 1000000. Next, start the container and look for the files which receive that invalid value.

Below is an example of finding an invalid file inside circleci/doc-highid using the find command:

# Start a shell inside the container
$ docker run -it circleci/doc-highid sh

# Find the file with high UID/GID
$ find / ( -uid 1000000 )  -ls 2>/dev/null
     50      0 -rw-r--r--   1 veryhigh veryhigh        0 Jul  9 03:05 /file-with-high-id

# Confirm that the file has high UID/GID
$ ls -ln file-with-high-id
-rw-r--r-- 1 1000000 1000000 0 Jul  9 03:05 file-with-high-id

After locating the offending file, change its ownership and re-create the image.

Note: It is possible for an invalid file to be generated and removed while a container is building. In this case, you may have to modify the RUN step in the Dockerfile itself. Adding && chown -R root:root /root to the problem step should fix the problem without creating a bad interim.

See Also

Refer to the following Microsoft forum post for additional links if you get more errors after performing this procedure.


Help make this document better

This guide, as well as the rest of our docs, are open source and available on GitHub. We welcome your contributions.

  • Suggest an edit to this page (please read the contributing guide first).
  • To report a problem in the documentation, or to submit feedback and comments, please open an issue on GitHub.
  • CircleCI is always seeking ways to improve your experience with our platform. If you would like to share feedback, please join our research community.

Need support?

Our support engineers are available to help with service issues, billing, or account related questions, and can help troubleshoot build configurations. Contact our support engineers by opening a ticket.

You can also visit our support site to find support articles, community forums, and training resources.


Docker error processing tar file occurs due to insufficient space or due to permission issues.

Here at Bobcares, we have seen several causes for this error while troubleshooting Docker issues as part of our Docker Hosting Support.

Today we’ll take a look at the cause for this error and how to fix it.

Why does Docker error processing tar file occur

Now let’s see why does this Docker error occur.

Generally, this error occurs while running any command in the Docker. This occurs if there is no space left on the device.
Also, in some cases, we noticed that this error also arose when there were some permission issues with certain files.

However, the reason for this error differs accordingly.

For instance, the error appears as below.

Docker error processing tar file

How we fix Docker error processing tar file

Let’s move to the solution part of this error. Here are the cases where we resolved this error for our customers.

1. Remove unused images

Recently, one of our customers approached us with the same error. He was trying to clear the space from his device and ran into the below error.

ERROR: Error processing tar file(exit status 1): unexpected EOF.

Now, let’s see how our Support Engineers fix this error for our customers.

First, we used a built-in command to remove unused images (Version 1.13+)

docker image prune

Then we ran the below command to stop the Docker.

systemctl stop docker

After that, we backed up the docker folder /var/lib/docker and removed it by running the below command

NOTE: This will remove images, containers, volumes, … make sure you back it up first.

rm -rf /var/lib/docker

Once this is done, we started the Docker service by running the below command.

systemctl start docker

This, fixed the error.

2. Permission issue

In a few cases, we saw that the files owned by root in the directory having permission issues. Providing the files proper permissions fixed the issue. For that, we used the below command.

chown -R : /var/lib/docker/tmp

[Need any further assistance in fixing Docker errors? – We’re available 24*7]

Conclusion

In short, this Docker error occurs due to insufficient space or due to permission issues. Today, we saw how our Support Engineers resolve this error to our customers.

Are you using Docker based apps?

There are proven ways to get even more out of your Docker containers! Let us help you.

Spend your time in growing business and we will take care of Docker Infrastructure for you.

GET STARTED

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

Понравилась статья? Поделить с друзьями:
  • Failed to register layer error creating overlay mount to
  • Failed to receive status rpc error code unavailable desc transport is closing
  • Failed to receive status rpc error code unavailable desc error reading from server eof
  • Failed to receive expected response from server with error 80090304
  • Failed to read rom error 0fl01 atiflash