I´m facing a weird problem when I want to build my image on Windows. I haven´t used Docker for anything else, so the installation can be considered as fresh. There are no volumes at all and no images yet.
When I´m trying to build my application from my Dockerfile, it finishes with this error
docker build ./
Sending build context to Docker daemon 1.4 GB
Error response from daemon: Error processing tar file(exit status 1): write /.bowerrc: no space left on device
I´ve read that you can increase the basesize of docker, but I haven´t found a solution for that for Windows (Why is this even limited by default?)
docker info prints some stuff, but it doesn´t show anything about the basesize under "Storage Driver" at all
$ docker info
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 1.13.1
Storage Driver: overlay2
Backing Filesystem: tmpfs
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
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1
runc version: 9df8b306d01f59d3a8029be411de015b7304dd8f
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.8-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.934 GiB
Name: moby
ID: GUXQ:KPKS:PHBV:BMEF:QHHM:B2YG:MWPB:2W5H:Z3GX:27YS:QBT6:O4RV
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 13
Goroutines: 21
System Time: 2017-02-19T20:15:57.8764828Z
EventsListeners: 0
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
According to some posts in the internet, this was once or is the way to go on Linux, but it doesn´t work on Windows
docker daemon --storage-opt dm.basesize=20G
What is wrong with my docker installation and how can I increase the basesize?
I had the same problem on Windows. One of this two settings should solve this problem:
Increase Memory that Docker is using. If is it 2GB, add more
Increase "Disk image max size" - initially is 60, move it to 80 GB
This should be enough, but depends on complexity of what you are building. In some cases increase of Swap would be needed. The initial Swap of Docker is 1024 MB
Thanks
I reset to factory default , then select : delete all image.
At advanced tab : increase 'Disk image max size' (I modify to 80 GB)
Then build docker again
I´ve reinstalled Docker and now it seems to work
This wouldn't have been the underlying issue for the OP back in 2017, but if you're experiencing this problem with Windows 10 1903, then you may be running into Docker for Windows issue #4100 ("Windows 1903 fails when storage-opt used").
On January 6th, 2020, a commit was pushed to the docker-ce GitHub repository that, from the comments (below), appears to implement a workaround to the underlying bug in Windows.
microsoft/hcsshim#718 wclayer: Work around Windows bug when expanding sandbox size
fixes microsoft/hcsshim#708 Windows Host Compute Service bug breaks docker (and other) sandboxes bigger than 20G on Windows 1903
fixes microsoft/hcsshim#624The hcsshim on Windows 10 1903 always fails to build Docker image
fixes/addresses docker/for-win#3884 An error occurred while attempting to build Docker image (especially this comment and the next comments after: docker/for-win#3884 (comment))
fixes/addresses docker/for-win#4100 Windows 1903 fails when storage-opt used
fixes moby/moby#36831 hcsshim::PrepareLayer failed in Win32: The parameter is incorrect (moby/moby#36831 (comment))
fixes Stannieman/audacity-with-asio-builder#5 Docker won't build container
fixes MicrosoftDocs/visualstudio-docs#3523 Error when running build with storage-opts set
fixes moby/moby#39524 Docker build windows 19.03 --storage-opt size>20G
Unfortunately, no new release of Docker has yet been made that includes this commit, so those of us on 1903 and experiencing this bug are kind of stuck for the time being.
Assuming you're doing this with a dev environment, just run:
docker system prune -a -f
Caution: Do not run this on a production environment
Related
I am trying build the nodemcu firmware with a docker on a windows 10 system.
When I try to build the nodemcu firmware, I have this error:
(...)
PRUNE libmain.a libc.a
/opt:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/nodemcu-firmware/tools/toolchains/esp8266-linux-x86_64-20190731.0/bin
xtensa-lx106-elf-ar: /opt/nodemcu-firmware/sdk/esp_iot_sdk_v3.0-e4434aa/lib/libc.a: No space left on device
Makefile:334: recipe for target '/opt/nodemcu-firmware/sdk/.pruned-3.0-e4434aa' failed
make: *** [/opt/nodemcu-firmware/sdk/.pruned-3.0-e4434aa] Error 1
make: Leaving directory '/opt/nodemcu-firmware'
I tried docker system prune but this error persists.
I tried execute docker info but doesn't help me:
Client:
Debug Mode: false
Server:
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 12
Server Version: 19.03.1
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.14.131-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.419GiB
Name: docker-desktop
ID: RCEX:VYON:IG6T:AXCF:CSLX:3NVK:V453:DTSP:HW4Y:EKBY:PCVW:2UOJ
Docker Root Dir: /var/lib/docker
Debug Mode: true
File Descriptors: 28
Goroutines: 44
System Time: 2020-12-21T02:04:22.387341144Z
EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
When I execute docker system df, I have this result:
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 4 1 673.8MB 209.8MB (31%)
Containers 1 0 0B 0B
Local Volumes 10 0 0B 0B
Build Cache 0 0 0B 0B
I am new in docker and I don't know what do to from here. Can anyone help me?
Docker tends to need cleanup after you work with it sometimes. There may be previous resources that were created in the past that are no longer in use, this is especially true if you are making use of volumes.
Sometimes, images are not fully created and end up becoming untagged dangling images which for the most part are undesirable. So you have to remove these undesirables that consume space.
docker image prune
docker image prune removes all dangling images.
2. docker volume prune
docker volume prune removes all 'volumes' which are not attached to any containers. These should always be ran before pruning containers otherwise all containers will get deleted this is because pruning containers removes all containers which are not running at the time the command is ran. For the most part in my experience volumes is often what consumes the most amount of resources in terms of space.
docker container prune
For the most part this is optional and you can choose to do this or not
Now even after deleting dangling images there might still be other images that do not get deleted but you no longer need, like for example if you had older versions of the redis image and later download the most recent version of it, you may need to remove the older one if you no longer use it. You will have to delete this manually. Use the following commands:
docker image ls
docker rmi <image id>
The first command gives you a list of all the images you have downloaded, and the second command deletes it. sometimes you may have to use the -f flag on the delete command to force the deletion of an image:
docker rmi -f <image id>
I'm running the latest Windows 10 Pro build (1903), the latest Docker Engine build (v19.03.8), and the latest IntelliJ (2019.3.4). I have set Expose daemon on tcp://localhost:2375 without TLS and Apply/Restart-ed the Engine. Trying to switch to a Windows container seemingly hangs the daemon, throwing an error, after which I need to destroy all settings and config files before I can start the daemon again.
Yet, when I'm trying to set tcp://localhost:2375 in my Docker plugin, the connection simply fails (probably with a timeout, but there's no log of it). Yet, simply using docker info and other commands from the CLI works as intended, so I'm fairly certain the Engine is running.
For reference, the output of docker info:
$ docker system info
Client:
Debug Mode: false
Plugins:
app: Docker Application (Docker Inc., v0.8.0)
buildx: Build with BuildKit (Docker Inc., v0.3.1-tp-docker)
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 19.03.8
Storage Driver: overlay2
Backing Filesystem: <unknown>
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: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
init version: fec3683
Security Options:
seccomp
Profile: default
Kernel Version: 4.19.76-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.943GiB
Name: docker-desktop
ID: NGP3:BQCE:JSUO:6BSV:IUU6:2UEZ:4QTQ:N6IO:TA3T:A7I7:4GXS:IYD6
Docker Root Dir: /var/lib/docker
Debug Mode: true
File Descriptors: 34
Goroutines: 50
System Time: 2020-03-27T15:56:23.690394533Z
EventsListeners: 3
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
What else can I try (short of using Docker Toolkit again) to get the integration up and running? How can I even test where the connection might be dropping?
So after three days of research, I have an answer. Apparently, Windows 10 reserves a port range of 2344-2444, which prevents the Docker daemon from actually exposing the TCP socket, despite the settings. I have a feeling it also relates to the daemon being unable to start after a reboot. You can verify if this is the root cause of the issue by executing the following in an elevated prompt/powershell: netsh interface ipv4 show excludedportrange protocol=tcp - if the output show a range that includes 2375, you are affected,
Remediation (this will include two reboots!):
Disable HyperV and reboot, to free up the port allocations: dism.exe /Online /Disable-Feature:Microsoft-Hyper-V
Manually allocate port 2375: netsh int ipv4 add excludedportrange protocol=tcp startport=2375 numberofports=1
Re-enable HyperV and reboot to take advantage of the fix: dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All
Optional: after this process, you can re-enable TLS on said socket, and the Docker plugin will be able to connect just fine.
2 years later (June 2022), this integration is easier to setup, assuming you have the latest Docker Desktop for Windows.
It uses as a back-end either WSL2 or HyperV.
The article "Getting Started with Visual Studio Code and IntelliJ IDEA Docker Plugins" from Tyler Charboneau details the IntelliJ IDEA part.
It will require a manual installation of the Docker plugin if you’re using the Community Edition.
Once you’ve installed the Docker plugin, you’ll need to connect it to Docker Desktop.
Follow these steps:
Navigate to IntelliJ IDEA > Preferences.
Expand the Build, Execution, Deployment group.
Click Docker, and then click the small "+" icon to the right.
Choose the correct Docker daemon for your platform (for example, Docker for Mac).
The installation may take a few minutes. Once it’s complete, you’ll see the "Connection successful" message toward the middle-bottom of the Preferences pane:
I am using Windows 10 pro and successfully installed Docker Client 18.09.0 and fetched hello-world docker image.
But when I try to run the image in container using docker run, it is giving the below error
C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: CreateComputeSystem 7b206637bedeb11c5f4bb8a5c12f941da3980a5c0e6e18d823f3323b6640a9de: The virtual machine could not be started because a required feature is not installed.
(extra info: {"SystemType":"Container","Name":"7b206637bedeb11c5f4bb8a5c12f941da3980a5c0e6e18d823f3323b6640a9de","Owner":"docker","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\ProgramData\\Docker\\windowsfilter\\7b206637bedeb11c5f4bb8a5c12f941da3980a5c0e6e18d823f3323b6640a9de","Layers":[{"ID":"ba045b84-94ef-5e96-a203-a8ef5cf53b41","Path":"C:\\ProgramData\\Docker\\windowsfilter\\2cbe39538cedc860f14e954ceed1044a5760df8830e8dc21bcbd4d21e88bf8f3"},{"ID":"959d85fc-a8bf-595a-84f9-a083080f2e27","Path":"C:\\ProgramData\\Docker\\windowsfilter\\3fc0987aeffab6be6b2bb0626867739cbad8dd80f42951e4e803b1e61b64543f"},{"ID":"40a5cfc0-ad6b-5b5e-85ff-dcd5826f380a","Path":"C:\\ProgramData\\Docker\\windowsfilter\\3e839c40c3c413a579f0f60a6ad8ec03daa496dcb61cfc621c35788beb6ae0d4"},{"ID":"be5e886a-ec0d-50e8-a735-c2c9a8b717de","Path":"C:\\ProgramData\\Docker\\windowsfilter\\12eddd7dc5f665f34ffebe1ff1600de14da8d7998950b9a3a180407b2781993a"}],"HostName":"7b206637bede","HvPartition":true,"EndpointList":["3C0F3EDA-3D0F-4C93-8908-C4DCB4FF6C8E"],"HvRuntime":{"ImagePath":"C:\\ProgramData\\Docker\\windowsfilter\\3e839c40c3c413a579f0f60a6ad8ec03daa496dcb61cfc621c35788beb6ae0d4\\UtilityVM"},"AllowUnqualifiedDNSQuery":true}).
I am not sure what sure about the issue or what feature is not installed. When I searched the internet all the errors are about hyperv which is there in my environment. My docker info gives the below details by the way:
PS C:\Windows\system32> docker info
Containers: 14
Running: 0
Paused: 0
Stopped: 14
Images: 2
Server Version: 18.09.0
Storage Driver: windowsfilter
Windows:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics l2bridge l2tunnel nat null overlay transparent
Log: awslogs etwlogs fluentd gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
Operating System: Windows 10 Pro Version 1809 (OS Build 17763.134)
OSType: windows
Architecture: x86_64
CPUs: 4
Total Memory: 23.54GiB
Name: DESKTOP-6MOD0L8
ID: 4QC3:QQKX:2BS2:P2JG:RUZA:3MK2:RAQ7:ZW7V:Q6YZ:5S56:Z3GQ:WXDC
Docker Root Dir: C:\ProgramData\Docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: -1
Goroutines: 26
System Time: 2018-12-10T12:14:05.5454663+05:30
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
Just in case someone is using a Windows 10 Virtual Machine like me you can use the following command in power shell.
Set-VMProcessor -VMName my_virtual_machine -ExposeVirtualizationExtensions $true
Remember to run as Administrator before executing the command else it will give you an error saying you don't have permissions.
This helped me with the same problem (I have virtualization enabled, but you can double-check on the Task Manager -> Performance tab):
Uninstall hyper-v (found in Windows Features)
Restart PC
Install hyper-v
Restart PC
Now you hopefully can build your container.
Source: https://github.com/docker/for-win/issues/2956#issuecomment-514572084
If you're running Docker with Hyper-V you may need to go into your BIOS and enable virtualization
https://blogs.technet.microsoft.com/canitpro/2015/09/08/step-by-step-enabling-hyper-v-for-use-on-windows-10/
I ran into this error with a recent Docker for Windows install and that was the culprit.
I was trying to run RavenDB docker container in Windows 10. My Windows 10 is a virtual machine running in Parallels Desktop on Mac OS.
To be able to run it I had to enable the Nested Virtualization feature on Parallels:
Nested Hyper-V support in Parallels Desktop virtual machines
Having that disabled was causing the RavenDB container to not start with that generic message:
"the virtual machine could not be started because a required feature is
not installed."
By the way, to get the log while starting docker on the command line you can do this:
docker run -it ravendb/ravendb:windows-nanoserver-latest > C:/Temp/docker-log.txt 2>&1d
This may help you debug what's causing the issue...
Try the following:
Uninstall docker, reboot
Uncheck Hyper-V and Windows Container in Windows Features, reboot
Completely remove docker, reboot
Re-install docker, maybe try edge
I have made a .net core app and it is uploaded to docker hub
When I try to pull it to my own machine, (win 10) it just works
When I try to pull it to the server (server 2016) I get an error:
docker pull arrivaflg/flg:20180618104928
....
failed to register layer: re-exec error: exit status 1: output: ProcessUtilityVMImage \\?\C:\ProgramData\docker\windowsfilter\cf1f49a6508aaa657768d667c58779e571392a80be0ba7519fe0835ac2476402\UtilityVM: The system cannot find the path specified.
But the really interesting part is when I try to pull a specific microsoft image, I get the SAME error message. (this is the version 1709 visual studio uses in the docker file on my machine)
c:\tmp>docker pull microsoft/nanoserver:1709
1709: Pulling from microsoft/nanoserver
407ada6e90de: Extracting [==================================================>] 81.04MB/81.04MB
85710d780d68: Download complete
failed to register layer: re-exec error: exit status 1: output: ProcessUtilityVMImage \\?\C:\ProgramData\docker\windowsfilter\cf1f49a6508aaa657768d667c58779e571392a80be0ba7519fe0835ac2476402\UtilityVM: The system cannot find the path specified.
If I don't specify the version number (and it just defaults to latest) there is no problem with getting the nano server on the server
But still a problem with getting mine image to the server.
So I'm guessing I should use a specific version of the nano server.
I have tried with these in my dockerfile:
FROM microsoft/aspnetcore:2.0-nanoserver-1709 AS base
and
FROM microsoft/aspnetcore:2.0-nanoserver-1803 AS base
My server information:
C:\Windows\system32>docker info
Containers: 3
Running: 0
Paused: 0
Stopped: 3
Images: 3
Server Version: 17.06.2-ee-11
Storage Driver: windowsfilter
Windows:
Logging Driver: json-file
Plugins:
Volume: local
Network: l2bridge l2tunnel nat null overlay transparent
Log: awslogs etwlogs fluentd json-file logentries splunk syslog
Swarm: inactive
Default Isolation: process
Kernel Version: 10.0 14393 (14393.2312.amd64fre.rs1_release.180607-1919)
Operating System: Windows Server 2016 Datacenter
OSType: windows
Architecture: x86_64
CPUs: 2
Total Memory: 4GiB
Name: AWS1twAROS001
ID: IVVQ:GK2Q:DNJ7:PW6W:GYZ7:WYQM:65VV:Q4JM:6BEL:5CGQ:ISXY:AWEF
Docker Root Dir: C:\ProgramData\docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
This error message typically indicates that the host system is running an older kernel version than that of the Docker image. As you can see in the table on the Windows Container Version Compatibility page, Windows Server 2016 doesn't support containers based on Windows Server version 1709 or Windows Server version 1803. However, Windows 10 version 1803 does support them through Hyper-V isolation mode, which is why the images were able to work correctly on your own machine.
Your attempts at using different base image versions are almost correct, you simply need the right tag for Windows Server 2016, as listed under the "Windows Server 2016 amd64 tags" section of the aspnetcore image page on Docker Hub:
FROM microsoft/aspnetcore:2.0-nanoserver-sac2016 AS base
This will use the build of the ASP.NET Core image that was built against the Windows Server 2016 version of the Nano Server image, which can then be used under a Windows Server 2016 host system.
I was trying to install gitlab using docker containers and was able to bring up gitlab successfully using docker compose file from sameersbn.
However after few uninstalls and (docker rm ) reinstalls (docker-compose up) as part of CI testing, I started getting this weird error while running docker-compose up or docker run
[root#server.com ~]# docker run java
Unable to find image 'java:latest' locally
Pulling repository docker.io/library/java
docker: Error while pulling image: Get https://index.docker.io/v1/repositories/library/java/images: malformed MIME header line: Too Many Requests (HAP429)..
See 'docker run --help'.
I can't seem to be able to pull any of the docker containers using docker run or docker-compose.
Couldn't find much help online reg this issue.
As per the docker hub forum the issue https://forums.docker.com/t/429-too-many-requests-how-to-fix-this-isssue/3971/7 should disappear after an hour but I waited half a day without much luck!
Here are the details of my installation:
[root#server build]# docker version
Client:
Version: 1.12.1
API version: 1.24
Go version: go1.6.3
Git commit: 23cf638
Built:
OS/Arch: linux/amd64
Server:
Version: 1.12.1
API version: 1.24
Go version: go1.6.3
Git commit: 23cf638
Built:
OS/Arch: linux/amd64
[root#server build]# docker info
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 15
Server Version: 1.12.1
Storage Driver: devicemapper
Pool Name: docker-thinpool
Pool Blocksize: 524.3 kB
Base Device Size: 10.74 GB
Backing Filesystem: xfs
Data file:
Metadata file:
Data Space Used: 3.077 GB
Data Space Total: 61.2 GB
Data Space Available: 58.12 GB
Metadata Space Used: 1.204 MB
Metadata Space Total: 641.7 MB
Metadata Space Available: 640.5 MB
Thin Pool Minimum Free Space: 6.119 GB
Udev Sync Supported: true
Deferred Removal Enabled: true
Deferred Deletion Enabled: false
Deferred Deleted Device Count: 0
Library Version: 1.02.107-RHEL7 (2015-10-14)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge null host overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-327.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.64 GiB
Name: server.com
ID: SDFS:SDEF:GKY5:UKGK:QHWR:H4EC:wEFw:YVAS:JE2V:A5YB:FDSW
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 17
Goroutines: 23
System Time: 2016-10-09T18:34:43.969512367-05:00
EventsListeners: 0
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-ip6tables is disabled
Insecure Registries:
127.0.0.0/8
Any help would be much appreciated. I'm stuck with this error and can't proceed any further with my gitlab.
Thanks.
This may or may not be relevant to your situation, but I can report that I had the same error (didn't go away within an hour) and it was related to the fact that I was on a VPN to my office. I don't know if the VPN was the issue, or the NAT of my workplace, but when I turned off the VPN, the issue went away.
Note, I was running Docker for Windows (W7), so my circumstances are quite different from yours. But perhaps this answer will be useful to you or to anyone else looking for an answer.
Bottom line: If you are using a VPN, switch it off and try again. If you are inside a corporate filewall, try from outside.