#GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not prov

1 messages Ā· Page 1 of 1 (latest)

teal depot
#

TL;DR with no $HOME/.docker/config.json and gnome-keyring not installed, dagger failed to pull public images

Hello, I am failing to run what seems like a pretty basic scenario, and I have even condensed it down to a minimal repro.

Goal: compile a go program using golang:1.22 using dagger.io/dagger v0.10.3
Expected:

  • fetch the image
  • mount my source
  • compile it
  • export executable to host filesystem

Actual:

12: resolve image config for docker.io/library/golang:1.22
12: > in from golang:1.22
12: resolve image config for docker.io/library/golang:1.22 ERROR: 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`

I have no issue running docker pull golang:1.22, so I don't believe I should have a dependency on any keychain/secrets.

EDIT: Even more minimal repro code:
dag.Container().From("golang:1.22").Export(context.Background(), "golang.tar")

This is my minimal code to reproduce the error:

package main

import (
    "context"
    "fmt"
    "os"

    "dagger.io/dagger"
)

func check(err error) {
    if err != nil {
        panic(err)
    }
}

func main() {
    client, err := dagger.Connect(context.Background(), dagger.WithLogOutput(os.Stderr))
    check(err)

    const buildImg = "golang:1.22"

    src := client.Host().Directory(".")
    build := client.Container().From(buildImg).WithMountedDirectory("/src", src)

    ok, err := build.WithExec([]string{"go", "build",
        "-o", "/app/demo",
        "/src/main.go"}).
        File("/app/demo").
        Export(context.Background(), "demo")
    check(err)
    if ok {
        fmt.Println("That was ok I guess")
    } else {
        fmt.Println("That was not ok")
    }
    fmt.Println("Compiled executable to ./demo")
}
quartz turret
#

Hey @teal depot šŸ‘‹
What happen if you add .WithWorkdir("/src") in your build?
build := client.Container().From(buildImg).WithMountedDirectory("/src", src).WithWorkdir("/src")

I did a quick repro and it works in my side (with WithWordir())

Dagger version: dagger v0.10.2

teal depot
#

Thanks for the reply. I tried the change exactly as you typed it, and got the same error. Let me try switching to v0.10.2

#

Good news, it fails exactly the same way on v0.10.2, so (A) this isn't a regression and (B) it is somehow related to my environment

#

Do we know if the DBus interactions are a docker thing or a dagger thing?

teal depot
#

WithoutRegistryAuth("docker.io") changes nothing

quartz turret
#

šŸ¤”

#

I don't think the error is related to dagger

#

Does your application inside the container tries to access the GNOME Keyring or a similar service that implements the org.freedesktop.secrets interface for storing secrets.
It seems that the service is not available within the container.

#

Can you try the build a different app?

teal depot
#

FWIW one of my coworkers tried the same code and it worked on their machine.

#

@quartz turret Could you clarify what you mean by "build a different app"? The entire source of my repro is in this thread. The error is related to "resolve image config for docker.io/library/golang:1.22" so I'll try playing with the image in use.

It may be relevant that I'm using Ubuntu 20.04.6 LTS 🤷

teal depot
#

Tried the combination of golang 1.22.2 and dagger.io/dagger v0.11.0 and I got the exact same error, but much earlier this time. I guess I'm gonna learn a lot about DBus today.

quartz turret
quartz turret
teal depot
#

Thanks for these suggestions. Since the problem is only present on my system, I tried killing dagger-engine and clearing volumes. At this point I can show an even simpler example that fails for me in the same way.

dag.Container().From("golang:1.22").Export(context.Background(), "golang.tar")

I verified with dbus-monitor that docker build is not attempting to interact with dbus. Looking a little closer, my dockerd is configured with a private mirror that dagger probably doesn't know about. I wonder if that can cause authentication to fail in this way?

quartz turret
dusky ridge
#

@teal depot what's your current dagger environment?

#

are you running this in your local machine?

#

It may be relevant that I'm using Ubuntu 20.04.6 LTS 🤷

just saw this. Can you check if you have installed gnome-keyring?

#

apt-get install gnome-keyring should fix the issue if you don't have that package installed

dusky ridge
teal depot
#

Confirmed I do not have gnome-keyring installed. Before I apply this workaround, could we discuss whether there is any way to avoid it entirely? I know precisely which auth and/or mirrors will be used in my pipeline, and none of it is expected via a keyring.

dusky ridge
#

are you pulling images from a public repository or you need to use your internal one?

teal depot
teal depot
dusky ridge
#

since they're defined a at the docker engine level

teal depot
#

yeah the lack of mirrors makes sense. I read the docs about running a custom dagger engine instance in order to provide mirror config

dusky ridge
#

could you try creating an empty ~/.docker/config.json file and try to run your basic repro again?

teal depot
#

empty file at ~/.docker/config.json seems to have no effect

dusky ridge
teal depot
#

so if I have a non-empty auth in my docker config...

dusky ridge
#

I'd expect docker login to raise the same error

teal depot
#

It did the trick!

$ cat ~/.docker/config.json
{
    "auths": {
      "https://index.docker.io/v1/": {
      }
    }
}
dusky ridge
#

haha, empty config. SGTM 🚢

teal depot
#

If DetectDefaultStore fails to connect to gnome-keyring, I'd suggest treating that as a miss rather than an error

#

Thanks for helping me with the root cause

dusky ridge
dusky ridge
#

@teal depot by any chance do you have the docker-credential-secretservice binary in your system?

teal depot
#

Indeed I do, and it comes from

$ dpkg -S $(which docker-credential-secretservice)
golang-docker-credential-helpers: /usr/bin/docker-credential-secretservice
dusky ridge
dusky ridge
#

if you remove that package, dagger should be ok as the binary docker-credential-secretservice will not be found

#

not sure to flag this as a Dagger issue per-se given that your local setup seems to be in a weird state