ERROR: Preparation failed: Error response from daemon: The requested URL /v1.25/info was not found on this server

I’m trying to set up gitlab CI on a windows 10 PC as a test.

I have created a docker container for gitlab and another for the runner. Everything seems to be OK till i execute the pipeline.

If i execute the pipeline, i have this error :

ERROR: Job failed (system failure): Error response from daemon: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<title>404 Not Found</title>
<h1>Not Found</h1>
<p>The requested URL /v1.25/info was not found on this server.</p>
</body></html> (executor_docker.go:980:0s)

The docker container for gitlab was created with this command (volumes are docker volumes) :

docker run --detach --name gitlab --hostname gitlab.mod --publish 4443:443 --publish 4480:80 --publish 8222:22 --volume gitlab-conf:/etc/gitlab --volume gitlab-logs:/var/log/gitlab --volume gitlab-data:/var/opt/gitlab gitlab/gitlab-ee

The runner was created this way

docker run -d --name gitlab-runner -v gitlab-runner-conf:/etc/gitlab-runner gitlab/gitlab-runner:latest


docker run --rm -t -i -v gitlab-runner-conf:/etc/gitlab-runner gitlab/gitlab-runner register --url "" --registration-token "sEcrEttOkEnfOrgItlAb" --description "Runner" --executor "docker" --docker-image alpine:latest --docker-services postgres:latest

where is the IP of my computer

My runner is configured like this :

  name = "Runner des tests unitaires"
  url = ""
  token = "my_secret_token"
  executor = "docker"
    host = "tcp://"

and my (very simple) .gitlab-ci.yml is set accordingly :

    HELLO: World
    DOCKER_HOST: tcp://

        - echo $HELLO

I also tried tcp:// (known from ipconfig) instead of tcp:// but the result is the same.

I don’t understand the meaning of the error message…

It seems that gitlab and the gitlab runner can talk together

When my job returns " The requested URL /v1.25/info was not found on this server. "

Is “this” the gitlab server or the gitlab runner server ? Where is this /v1.25/info URL called ?

No one has a clue ? Is there logfiles where i can have more detailed message ? I’m stuck with this…
As i am a newbie, i’m not surprised to meet some difficult steps but I thought this would not be a too much hard case : 2 docker containers on a single windows 10 machine, one gitlab, one runner and one very simple .gitlab-ci.yml.
May this come from the hostname ? the proxy ? a bad choice in the --docker-image ?
I don’t think so because the 2 containers seems to see each other. But what then ?
And where does this URL comes from ?


the /1.25/info URL endpoint sounds a little odd, too old. Which version of GitLab are you using? Check that with https://gitlab.yourdomain/help in you browser.


1 Like

My gitlab version is

  • GitLab Enterprise Edition [12.6.2-ee]

The runner is in 12.6 version too

Both are dockerized.

What happens if you manually try to login into the Windows Docker instance?

docker login

Likewise, try printing

docker info

inside the script section to gather further insights.


docker login

It asks for a username (?). I don’t know which user i am to provide.
Anyway, if i test anything, I have :

Error response from daemon: Get Service Unavailable

The script section of the .gitlab-ci.yml file ? (sorry i’m not very easy with all the CI stuff)

So, my new gitlab-ci.yml :

    HELLO: World
    DOCKER_HOST: tcp://

        - docker info

Same error and no info.

If I run docker info in a command line, i have :

Containers: 4
 Running: 2
 Paused: 0
 Stopped: 2
Images: 133
Server Version: 18.09.2
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
 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:
  Profile: default
Kernel Version: 4.9.125-linuxkit
Operating System: Docker for Windows
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.934GiB
Name: linuxkit-00155ddad101
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 34
 Goroutines: 56
 System Time: 2020-01-15T11:28:45.5660619Z
 EventsListeners: 1
HTTP Proxy: http://proxyxxxxxxx:1234
HTTPS Proxy: http://proxyxxxxxxx:1234
Experimental: false
Insecure Registries:
Live Restore Enabled: false
Product License: Community Engine 

Is this host equivalent to what’s written in your DOCKER_HOST variable? (without http)

On my macbook, it looks like this:

$ docker info | grep 'HTTP Proxy'
 HTTP Proxy: gateway.docker.internal:3128
$ docker login gateway.docker.internal
Username: ^C


The proxy here is the HTTP_PROXY from my windows 10 config
I set them in the gui and if not set this way, i can’t access the docker hub (at least could I access it once i had set the proxy in the GUI).

Ok. I don’t know why but the error you are seeing is from an HTTP server which does not provide the URL endpoint, so this isn’t a Docker host but an http proxy leading to somewhere else. What happens if you open in your browser or inside the gitlab-ci.yml with

curl -vvv

Thank you. It will be difficult to test today (i’m away) but this may be a very good clue because in fact, i have 2 gitlab servers. The official one, on another machine, which is rather old (but which i can’t modify), and the one on my local machine, which is dockerized.
When I push, i can choose one of the two remotes : origin (the official gitlab) and origin_local for the dockerized one.
For a reason i don’t know (yet) it seems that the official gitlab server comes in my tests.
I’ll test this tomorrow.

In the first case, I have a DNS error.
In the second, i have the error mentioned in the first post.

I have tested by removing origin_local from my git config and make my local gitlab origin bu I still have the error.
I have to test from a fresh install to be sure the “official” gitlab is nowhere in the way.

I created a new runner and registered it once again but no change. Always this same URL error coming from somewhere i don’t know.

When you say :

this means you know this url.
Is this given by the gitlab server ? The runner ? Docker ?
Does this error happen when gitlab wants to connect to the runner ? on the runner while trying to lauch the tests ? on gitlab when he tries to get the tests results ?
What url is waited on a recent config (v2.5/info ? v12.6/info ?) ?
Can I reach it somewhere via the browser (on the gitlab server) to test if it has something to do with my “official” gitlab ?


Yep, that is the Docker engine API version and specifically, the URL endpoint the client tries to reach on the Docker daemon.

Here’s an overview about the API versions: Redirecting…
1.25 translates to Docker 1.13 which is too old for recent Docker daemons/registries.

Try running docker version to get the client and server API versions. If that’s really 1.25, you’re likely using a too old Docker setup on your Windows runner. That’s not related to GitLab then.


So this may come from docker rather than the gitlab and gitlab runner containers…
I don’t understand what’s going on and what is this docker v1.25.
But this doesn’t seem to be my local machine one :

> docker version
Client: Docker Engine - Community
 Version:           18.09.2
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        6247962
 Built:             Sun Feb 10 04:12:31 2019
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
  Version:          18.09.2
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.6
  Git commit:       6247962
  Built:            Sun Feb 10 04:13:06 2019
  OS/Arch:          linux/amd64
  Experimental:     false

May this come from the proxy setup ?
I used the internal network proxy to setup docker to be able to reach the hub.
Is there a chance i reach some other docker server this way ? (How ??)

I’m not sure why you are testing on your local machine, this should be executed on the Windows runner.

You can automate this by adding this execution to your .gitlab-ci.yml too.

    HELLO: World
    DOCKER_HOST: tcp://

        - docker version

Commit, push, watch the CI jobs output.


I thank you very much for your patience.
I’ll try to summerize :
I’m beginning with CI and wanted to test this without messing the gitlab from my compagny (which is very old anyway).

So, i decided to try to install all the stack on my local machine with docker (the idea is to mimic multiple machines).

I use one container for gitlab and another for a gitlab runner.
Proxy in the docker gui is set to the proxy of my compagny
I put the IP in my no_proxy setting

Everything was going rather well.
Commands to create the containers went ok,
Firsts commits went ok (very basic project)
runner registeration went ok
But now, i have this error each time i push code as soon as i have a .gitlab-ci.yml file (so does the push for your last post).
I’ve updated everything i could. I have done nothing more than install docker, run the 3 commands listed (except that now i register the runner in a non interactive way when i retry the process), create a new project on gitlab and push my basic code. And i have this error each time whatever is in it my .gitlab-ci.yml file.

The only lead i can see is some mess between my “official” gitlab server and my local one. But how ?? And anyway, the “official” gitlab is not dockerized so this lead is not very good.


ok, so you are offline in your own containerized environment. I had mixed this up from the long topic, I thought it was only the runner.

Still, if you don’t need to pull anything from external, a try worthwhile would be to entirely remove the HTTP proxy settings from your Docker desktop config and see if that changes things. The CI job currently doesn’t use any Docker image, so it may succeed offline. If it does, that’s a target for research then.


I’ll test that next week.You are definitly right. I’ll plug off the network and start again from scratch. Whatever the result is, it will seriously narrow the scope.
Thanks again. You’re really very helpful.