docker build regression: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files

[DimanNe]

Docker was working perfectly fine, but recently it stopped building the simplest possible Dockerfile, such as this one:

FROM ubuntu:19.04
RUN echo "hello world"

Here is the output:

$ DOCKER_BUILDKIT=1  docker build -t test .
[+] Building 0.6s (4/5)                                                                                                                                         
 => [internal] load build definition from Dockerfile                       0.0s
 => => transferring dockerfile: 37B                                        0.0s
 => [internal] load .dockerignore                                          0.0s
 => => transferring context: 2B                                            0.0s
 => ERROR [internal] load metadata for docker.io/library/ubuntu:19.04      0.4s
 => ERROR [1/2] FROM docker.io/library/ubuntu:19.04                        0.1s
 => => resolve docker.io/library/ubuntu:19.04                              0.1s
------
 > [internal] load metadata for docker.io/library/ubuntu:19.04:
------
------
 > [1/2] FROM docker.io/library/ubuntu:19.04:
------
rpc error: code = Unknown desc = error getting credentials - err: exit status 1, out:
`GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets
was not provided by any .service files`

Do you have any ideas of what might be wrong?

r$ docker version
Client:
 Version:           18.09.7
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        2d0083d
 Built:             Thu Jun 27 17:56:23 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.7
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.8
  Git commit:       2d0083d
  Built:            Thu Jun 27 17:23:02 2019
  OS/Arch:          linux/amd64
  Experimental:     false

$ docker info
Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 25
Server Version: 18.09.7
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: nvidia runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 894b81a4b802e4eb2a91d1ce216b8817763c29fb
runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f
init version: fec3683
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 5.0.0-20-generic
Operating System: Ubuntu 19.04
OSType: linux
Architecture: x86_64
CPUs: 12
Total Memory: 62.84GiB
Name: Impedance
ID: PAJA:TZMR:JCJS:Y3CO:VWNZ:DDXQ:WHT3:U467:F7S4:BE37:VIH2:ZALQ
Docker Root Dir: /var/lib/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
Product License: Community Engine

WARNING: No swap limit support

[thaJeztah]

Do you happen to have the "secret service" docker credential helper installed?

[tonistiigi]

The error is on getting the credentials. Post docker cli config (if you already didn't figure it out based on @thaJeztah comment). Mask the passwords before posting.

[thaJeztah]

Yes, I think this is because of the secretservice credential helper (i was answering from my phone earlier so couldn't find the relative links easily); that helper cannot run headless / non-interactive, which is what I suspect happens here; see moby/moby#25169

Instead of the secretservice credential helper, you can use the pass credentials-helper, which is able to run headless; see docker/cli#451

[DimanNe]

Thank you for the quick response.
So, I have docker-credential-helpers installed

$ apt list --installed | grep docker-credential
golang-docker-credential-helpers/disco,now 0.6.1-1 amd64 [installed,automatic]

I also managed to find a workaround - installing gnome-keyring fixes the issue.

And finally,

Instead of the secretservice credential helper, you can use the pass credentials-helper, which is able to run headless;

Not sure whether I understood you correctly or not, but I am running it NOT in headless mode - I am trying to build images on my regular home PC.

[lucasantarella]

Can also confirm that
sudo apt install gnome-keyring fixed the issue for me.

This seems to be a KDE Neon related issue. @DimanNe can you confirm if you are on Kubuntu?

[DimanNe]

@lucasantarella Yep, you are right, I am using Kubuntu.

[novakg]

I experience the same issue on Kubuntu 20.04

[thaJeztah]

Try either uninstalling the golang-docker-credential-helpers package, or installing the pass package. The golang-docker-credential-helpers package shipped by (K)ubuntu tries to use the secretservice credentials store (which does not work in non-interactive sessions), whereas the pass store can work.

[novakg]

Yes, I can confirm that the pass way works. I just wanted to note that others should not spend too much time on trying to make the secretservice way work in (K)ubuntu 20.04

[Gameransari]

**The Solution is here
**
https://youtu.be/34iXHWuhsss

[spoelstraethan]

You can use gnome-keyring-daemon without a lot of extra cruft if you install with sudo apt install gnome-keyring --no-install-recommends and then if you already have a DBUS_SESSION_BUS_ADDRESS you can just gnome-keyring-daemon --unlock and provide a password and press Ctrl+D. If you don't have the above variable you can follow the steps from keyring or Zowe.

[subhash-jd]

Can also confirm that sudo apt install gnome-keyring fixed the issue for me.

This seems to be a KDE Neon related issue. @DimanNe can you confirm if you are on Kubuntu?

This worked for me

[AashiqRamachandran]

apt-get install gnome-keyring worked for me as well

[kjdfklha]

apt-get install gnome-keyring worked +1

[tlightsky]

apt-get install gnome-keyring worked +1