Remote error from secret service org freedesktop dbus error serviceunknown

Edit: I have a feeling I deleted/uninstalled something necessary for wired ethernet; so I’m putting this on hold until there’s a better reason to reinstall an OS.

I’m trying to connect with ethernet rather than wifi, but when I start nm-applet and try to change settings (there doesn’t seem to be a way to say «connect to ethernet» other than «connect automatically») I get these mysterious messages (and no connection):

** Message: Cannot save connection due to error: Editor initializing...
** Message: Connection validates and can be saved
** Message: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files

1 — «Cannot save connection» is immediately followed by
2 — «Connection validates and can be saved» — is it saved or not?
3 — When I «Edit->Save», with or without changing anything, I get that mysterious message from my good friends (ha! ha!) at freedesktop.org .

I do not have «keyring» packages installed. Are they required for ethernet but NOT Wifi?

https://help.ubuntu.com/stable/ubuntu-h … ct.html.en says:
«To set up most wired network connections, all you need to do is plug in a network cable. The wired network icon (settings) is displayed on the top bar with three dots while the connection is being established. The dots disappear when you are connected.»

I don’t see any dots and it doesn’t connect….

Edit: After installing gnome-keyring and rebooting, it still can’t connect but the freedesktop nonsense is gone:

Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
** Message: Cannot save connection due to error: Editor initializing...
** Message: Connection validates and can be saved

Output of journalctl --follow when trying to add a new wired connections named «wired1»:

Apr 30 09:14:37 mycom dbus[659]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Apr 30 09:14:37 mycom systemd[1]: Starting Hostname Service...
Apr 30 09:14:37 mycom dbus[659]: [system] Successfully activated service 'org.freedesktop.hostname1'
Apr 30 09:14:37 mycom systemd[1]: Started Hostname Service.
Apr 30 09:14:37 mycom org.gtk.vfs.Daemon[989]: ** (process:2109): WARNING **: send_done_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path /org/gtk/vfs/client/enumerator/1 (g-dbus-error-quark, 19)
Apr 30 09:14:38 mycom org.gtk.vfs.Daemon[989]: ** (gvfsd:1045): WARNING **: dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Failed to retrieve share list from server: Connection refused
Apr 30 09:14:38 mycom org.gtk.vfs.Daemon[989]: ** (gvfsd:1045): WARNING **: dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Failed to retrieve share list from server: Connection refused
Apr 30 09:14:38 mycom org.gtk.vfs.Daemon[989]: ** (process:2139): WARNING **: Couldn't create directory monitor on smb://x-gnome-default-workgroup/. Error: The specified location is not mounted
Apr 30 09:14:38 mycom org.gtk.vfs.Daemon[989]: ** (gvfsd:1045): WARNING **: dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Failed to retrieve share list from server: Connection refused
Apr 30 09:14:38 mycom org.gtk.vfs.Daemon[989]: ** (gvfsd:1045): WARNING **: dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Failed to retrieve share list from server: Connection refused
Apr 30 09:14:38 mycom org.gtk.vfs.Daemon[989]: ** (process:2136): WARNING **: Couldn't create directory monitor on smb://x-gnome-default-workgroup/. Error: The specified location is not mounted
Apr 30 09:14:38 mycom org.gtk.vfs.Daemon[989]: ** (gvfsd:1045): WARNING **: dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Failed to retrieve share list from server: Connection refused
Apr 30 09:14:38 mycom org.gtk.vfs.Daemon[989]: ** (gvfsd:1045): WARNING **: dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Failed to retrieve share list from server: Connection refused
Apr 30 09:14:38 mycom org.gtk.vfs.Daemon[989]: ** (process:2129): WARNING **: Couldn't create directory monitor on smb://x-gnome-default-workgroup/. Error: The specified location is not mounted
Apr 30 09:14:38 mycom org.gtk.vfs.Daemon[989]: ** (process:2123): WARNING **: Couldn't create directory monitor on smb://x-gnome-default-workgroup/. Error: The specified location is not mounted
Apr 30 09:14:38 mycom org.gtk.vfs.Daemon[989]: ** (process:2125): WARNING **: Couldn't create directory monitor on smb://x-gnome-default-workgroup/. Error: The specified location is not mounted
Apr 30 09:14:38 mycom org.gtk.vfs.Daemon[989]: ** (process:2132): WARNING **: Couldn't create directory monitor on smb://x-gnome-default-workgroup/. Error: The specified location is not mounted
Apr 30 09:14:48 mycom NetworkManager[690]: <info>  [1525101288.5485] keyfile: add connection /etc/NetworkManager/system-connections/Wired1 (3bf6224f-5e68-485b-b143-f7d9dfd5d00a,"Wired1")
Apr 30 09:14:48 mycom NetworkManager[690]: <info>  [1525101288.5492] audit: op="connection-add" uuid="3bf6224f-5e68-485b-b143-f7d9dfd5d00a" name="Wired1" pid=2104 uid=1000 result="success"
Apr 30 09:14:48 mycom gnome-keyring-daemon[2235]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory
Apr 30 09:14:48 mycom org.freedesktop.secrets[989]: ** Message: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory
Apr 30 09:15:08 mycom NetworkManager[690]: <info>  [1525101308.9162] keyfile: update /etc/NetworkManager/system-connections/Wired1 (3bf6224f-5e68-485b-b143-f7d9dfd5d00a,"Wired1")
Apr 30 09:15:08 mycom NetworkManager[690]: <info>  [1525101308.9177] audit: op="connection-update" uuid="3bf6224f-5e68-485b-b143-f7d9dfd5d00a" name="Wired1" pid=2104 uid=1000 result="success"
Apr 30 09:17:01 mycom CRON[2275]: pam_unix(cron:session): session opened for user root by (uid=0)
Apr 30 09:17:01 mycom CRON[2276]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Apr 30 09:17:01 mycom CRON[2275]: pam_unix(cron:session): session closed for user root

[Az.Accounts] Return warning «org.freedesktop.DBus.Error.ServiceUnknown» when dbus-user-session package is installed #14207

Comments

al-cheb commented Feb 16, 2021 •

Description

After installing dbus-user-session package on Ubuntu 18.04 , Import-Module Az.Accounts has returned ** Message: 17:43:58.624: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files which has broken our CI due to writing to the stderr.
This issue doesn’t reproduce on Ubuntu 20.04 where the dbus-user-session package is pre-installed by default or using sudo.

Steps to reproduce

Environment data

Module versions

Error output

The text was updated successfully, but these errors were encountered:

dingmeng-xue commented Feb 19, 2021

We will report this question to owner of MSAL extension.

bgavrilMS commented Feb 24, 2021

Hi @al-cheb — what Ubuntu distro should I install to reproduce this? The desktop image or the server image or some other image?

al-cheb commented Feb 24, 2021 •

Hi @al-cheb — what Ubuntu distro should I install to reproduce this? The desktop image or the server image or some other image?

Hi, @bgavrilMS. We use an image template from Azure marketplace:

bgavrilMS commented Feb 24, 2021

Ok, so I think what’s happening here is that the internal secret storage library MsalCacheExtension is unable to write to the dbus due to the error above. The root cause of the error is related to the fact that dbus requires X11, so the error it expected on a CI machine.

AzureCLI and PowerShell normally detect this kind of error (via the ValidatePersistence call), and will fallback to storing secrets in a plaintext file, as far as I know. @erich-wang can keep me honest here.

Источник

Linux Mint Forums

Welcome to the Linux Mint forums!

[DELAYED] Can’t connect to wired: «Remote error from secret service»

[DELAYED] Can’t connect to wired: «Remote error from secret service»

Post by Flemur » Mon Apr 30, 2018 10:56 am

Edit: I have a feeling I deleted/uninstalled something necessary for wired ethernet; so I’m putting this on hold until there’s a better reason to reinstall an OS.

I’m trying to connect with ethernet rather than wifi, but when I start nm-applet and try to change settings (there doesn’t seem to be a way to say «connect to ethernet» other than «connect automatically») I get these mysterious messages (and no connection):

1 — «Cannot save connection» is immediately followed by
2 — «Connection validates and can be saved» — is it saved or not?
3 — When I «Edit->Save», with or without changing anything, I get that mysterious message from my good friends (ha! ha!) at freedesktop.org .

I do not have «keyring» packages installed. Are they required for ethernet but NOT Wifi?

https://help.ubuntu.com/stable/ubuntu-h . ct.html.en says:
«To set up most wired network connections, all you need to do is plug in a network cable. The wired network icon (settings) is displayed on the top bar with three dots while the connection is being established. The dots disappear when you are connected.»

I don’t see any dots and it doesn’t connect.

Edit: After installing gnome-keyring and rebooting, it still can’t connect but the freedesktop nonsense is gone:

Источник

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

Comments

DimanNe commented Jul 12, 2019

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

Here is the output:

Do you have any ideas of what might be wrong?

The text was updated successfully, but these errors were encountered:

thaJeztah commented Jul 12, 2019

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

tonistiigi commented Jul 12, 2019

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 commented Jul 12, 2019 •

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 commented Jul 12, 2019

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

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

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.

Источник

The name org.freedesktop.secrets was not provided by any .service files #681

Comments

tobias-kuendig commented Feb 12, 2018

When I run mailspring on latest KDE Neon I get the following message:

All libsecret-* packages are installed as recommended in the KB article.

It looks like Mailspring cannot communicate with KWallet. Any idea on how to get this working?

What operating system are you using?

What version of Mailspring are you using?

The text was updated successfully, but these errors were encountered:

bengotow commented Feb 12, 2018

Hey! Are you using the Snapcraft release of Mailspring? It might be a good idea to see if that works — might also be useful to look at https://github.com/atom/node-keytar (the package we use to access the system wallet) and see if there are any clues there?

tobias-kuendig commented Feb 12, 2018

Hi, thanks for your response. I have tested it with both the deb and the snap version. Unfortunately without any luck.

This bug looks promising: atom/node-keytar#74

tobias-kuendig commented Feb 12, 2018

I can confirm that sudo apt install gnome-keyring solves the problem on KDE. Looks like the problem is with node-keytar . Thanks for pointing me to the right direction!

outfrost commented May 31, 2019 •

Could you make it an option to not store passwords on disk at all?

It seems that node-keytar relies on libsecret on Linux, and libsecret in turn relies on gnome-keyring . It’s possible that libsecret would support other keyrings implementing the org.freedesktop.secrets DBus functionality, but none appear to exist so far.

For me, as a KDE Plasma user, none of the solutions or workarounds that I’ve found for this problem are desirable. I would simply prefer it not to store my password offline, only holding it in RAM while logged in for the purpose of continuous sync. FWIW, it is an option in Thunderbird.

Hardwiring a desktop-agnostic app to absolutely always require a piece of GNOME software seems somewhat odd to me. IMHO it would be much better if offline password storage was optional.

Источник

podman complains about missing dbus-launch — but I don’t want to install a full desktop environment #9353

Comments

asottile commented Feb 12, 2021

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

Description

When I run any podman command as another user, I get this output:

dbus-launch on ubuntu is provided by the dbus-x11 package which pulls in a full x11 environment which I absolutely do not need on a headless server.

Steps to reproduce the issue:

1. run any podman command as another user

Describe the results you received:

Describe the results you expected:

no extraneous output

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version :

Output of podman info —debug :

Package info (e.g. output of rpm -q podman or apt list podman ):

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Additional environment details (AWS, VirtualBox, physical, etc.):

The text was updated successfully, but these errors were encountered:

vrothberg commented Feb 15, 2021 •

Thanks for reaching out!

Podman uses the systemd cgroup manager by default. You could change it to cgroupfs on the CLI via —cgroup-manager=cgroupfs or you tweak /usr/share/containers/containers.conf and set

vrothberg commented Feb 15, 2021

Please let me know if that works for you.

rhatdan commented Feb 15, 2021

The containers.conf change should be made in /etc/containers/containers.conf

asottile commented Feb 15, 2021

that changes the error message but doesn’t fix it:

asottile commented Feb 15, 2021

and actually, if I install dbus-x11 (which I don’t want to) it still doesn’t work (this is with the default container config):

vrothberg commented Feb 15, 2021 •

Can you try with sudo —login -u ? It looks like the systemd session of the pcrunner user is not complete.

asottile commented Feb 15, 2021

It’s meant to be a service user only — does podman require a full login session?

asottile commented Feb 15, 2021

(fwiw, this prints — as I expect for service users):

al-cheb commented Feb 15, 2021 •

I can reproduce the same behavior on Ubuntu 18.04. Starting with podman 3.0.0 one of dependence is dbus-user-session which breaks our CI with Az.Accounts powershell module. Is it possible to eliminate installation the dbus-user-session pkg?

Warnings don’t reproduce with sudo:

ocafebabe commented Feb 15, 2021

I’m observing the same behaviour with a fresh podman 3.0.0 install on Ubuntu 20.04.

I never had this issue with podman 2.2.1 on my other Ubuntu 20.04 servers, what has been changed in the latest release?

asottile commented Feb 16, 2021

I’m observing the same behaviour with a fresh podman 3.0.0 install on Ubuntu 20.04.

I never had this issue with podman 2.2.1 on my other Ubuntu 20.04 servers, what has been changed in the latest release?

I believe the reason it is just showing up now is the default log level changed from ERROR => WARN in 3.0.0

ocafebabe commented Feb 16, 2021

I’m observing the same behaviour with a fresh podman 3.0.0 install on Ubuntu 20.04.
I never had this issue with podman 2.2.1 on my other Ubuntu 20.04 servers, what has been changed in the latest release?

I believe the reason it is just showing up now is the default log level changed from ERROR => WARN in 3.0.0

This really sucks because now I get false-positive alerts whenever podman is invoked as this gets printed during crontab task executions.

BTW my use case is similar to yours: service account (accessed using sudo -u xxxxx -i ) running on headless servers.

asottile commented Feb 16, 2021

I’m currently hacking around the warning with —log-level error (in a commit that I hope to revert once this issue is fixed)

Источник