The same issue reported below exists in 1.6.0-0.1.rc6.fc21 +++ This bug was initially created as a clone of Bug #1212188 +++ Description of problem: I'm unable to 'docker login' using 1.6.0-2.el7 Version-Release number of selected component (if applicable): docker-1.6.0-2.el7 How reproducible: 100% Steps to Reproduce: 1. docker login -u <user> -p <pass> -e <email> Actual results: FATA[0001] Post http:///var/run/docker.sock/v1.18/auth: EOF. Are you trying to connect to a TLS-enabled daemon without TLS? Expected results: WARNING: login credentials saved in /home/vagrant/.dockercfg. Login Succeeded Additional info: From journalctl: time="2015-04-15T13:18:12-04:00" level=info msg="POST /v1.18/auth" time="2015-04-15T13:18:12-04:00" level=info msg="+job auth()" time="2015-04-15T13:18:12-04:00" level=info msg="-job auth()" 2015/04/15 13:18:12 http: panic serving @: runtime error: invalid memory address or nil pointer dereference goroutine 2838 [running]: net/http.func·011() /usr/lib/golang/src/net/http/server.go:1130 +0xbb fp=0xc20810d4c8 sp=0xc20810d3e8 runtime.call16(0xc20810def0, 0xc209c32510, 0x0) /usr/lib/golang/src/runtime/asm_amd64.s:401 +0x45 fp=0xc20810d4e0 sp=0xc20810d4c8 runtime.gopanic(0xb15060, 0xc20802a050) /usr/lib/golang/src/runtime/panic.go:387 +0x3a8 fp=0xc20810d548 sp=0xc20810d4e0 runtime.panicmem() /usr/lib/golang/src/runtime/panic.go:42 +0x4e fp=0xc20810d570 sp=0xc20810d548 runtime.sigpanic() /usr/lib/golang/src/runtime/sigpanic_unix.go:26 +0x274 fp=0xc20810d5c0 sp=0xc20810d570 github.com/docker/docker/registry.NewEndpoint(0x0, 0xc1e1d0, 0x0, 0x0) /builddir/build/BUILD/docker-b27feb4ff804f335c80861b17a4e2bfc29fbbf45/_build/src/github.com/docker/docker/registry/endpoint.go:47 +0x31 fp=0xc20810d620 sp=0xc20810d5c0 github.com/docker/docker/registry.(*Service).Auth(0xc20802e340, 0xc208d91900, 0x2) /builddir/build/BUILD/docker-b27feb4ff804f335c80861b17a4e2bfc29fbbf45/_build/src/github.com/docker/docker/registry/service.go:64 +0x168 fp=0xc20810d730 sp=0xc20810d620 github.com/docker/docker/registry.*Service.Auth·fm(0xc208d91900, 0x7fac53e860a0) /builddir/build/BUILD/docker-b27feb4ff804f335c80861b17a4e2bfc29fbbf45/_build/src/github.com/docker/docker/registry/service.go:33 +0x31 fp=0xc20810d750 sp=0xc20810d730 github.com/docker/docker/engine.(*Job).Run(0xc208d91900, 0x0, 0x0) /builddir/build/BUILD/docker-b27feb4ff804f335c80861b17a4e2bfc29fbbf45/_build/src/github.com/docker/docker/engine/job.go:90 +0x936 fp=0xc20810d8a0 sp=0xc20810d750 github.com/docker/docker/api/server.postAuth(0xc2080e20d0, 0xc208984c27, 0x4, 0x7fac53ead348, 0xc208d917c0, 0xc20893e000, 0xc20933a6c0, 0x0, 0x0) /builddir/build/BUILD/docker-b27feb4ff804f335c80861b17a4e2bfc29fbbf45/_build/src/github.com/docker/docker/api/server/server.go:189 +0x292 fp=0xc20810d9e0 sp=0xc20810d8a0
I've experienced this very error using docker-1.7.1 on Fedora 22. Is this a regression?
I don't think so, but could you try out docker-1.8.1 which should be in updates-testing?
I can see that in updates-testing, but all my "dnf update" commands keep telling me "Nothing to do." Do i need to refresh my cache, or update metadata, or wait for mirror propagation, or sacrifice a chicken?
Must be something wrong in fedora release engineering, Might be just a backup because everyone was at FLOCK last week. Pull it directly from koji and see if it fixes your issue.
OK, docker-1.8.1 finally showed up in updates-testing, so I updated, rebooted just to play it safe and: $ docker login Username: rpjday Password: Email: rpjday Post http:///var/run/docker.sock/v1.20/auth: dial unix /var/run/docker.sock: permission denied. * Are you trying to connect to a TLS-enabled daemon without TLS? * Is your docker daemon up and running? $ docker is definitely running, and that is the error I expect to get whenever I try to invoke docker without "sudo". However, if I use "sudo", while it succeeds, my credentials will be stored under /root, obviously not what I want. I recall from somewhere mention of a possible "docker" group and, if one existed, the socket would be in that group, and any user who was also in that group would have extra privileges. On my Fedora 22 system, there is no such group, but there is this: dockerroot:x:966: I have no idea what it's for. Should all this be a new BZ report? Or just continue here?
You can set it up, but I address the problems here. http://www.projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-run-docker-in-centos-fedora-or-rhel/
Fair enough, but then the man page for "docker-login" is wrong since it clearly suggests you can log in to Docker Hub as a non-root user as long as you have an account at Docker Hub.
Yes, although eventually we would like to fix this so you could use docker group. Please open a bugzill on the docker-login man page.
Okeley dokeley.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.