After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 793977 - Cannot auto-connect to VPN on Gnome 3.26+, "Failed to request VPN secrets #3: No agents were available for this request."
Cannot auto-connect to VPN on Gnome 3.26+, "Failed to request VPN secrets #3:...
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: VPN (general)
git master
Other Linux
: Normal critical
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2018-03-02 03:23 UTC by Nick Stommel
Modified: 2020-11-12 14:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
requested journal log (758.39 KB, text/plain)
2018-03-13 01:19 UTC, Nick Stommel
Details
Gnome Shell journal error (7.13 KB, text/plain)
2018-03-18 00:23 UTC, Nick Stommel
Details

Description Nick Stommel 2018-03-02 03:23:36 UTC
Okay...so after months of waiting for anybody whatsoever to care about this problem on Ubuntu Launchpad, see https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1718931 I am inclined to report this bug upstream. Running the latest stable version of the Gnome shell 3.26.X in gnome-session on Ubuntu 17.10+ (also tested on unstable Ubuntu 18.04 desktop), it is impossible to auto-connect to a VPN server when the auto-connect box is checked (or nm-configuration files are changed accordingly) in nm-connection-editor when the password is stored for a single user (namely, encrypted in the Gnome keyring). 

Manually connecting to my openvpn server works totally fine, but auto-connecting (which is the ideal convenience here, really), doesn't work at all. It appears that the network manager, applet, and/or keyring are not working in tandem here, as the error message "vpn-connection[...]: Failed to request VPN secrets #3: No agents were available for this request." appears in the syslog *every* single time the network manager is prompted to reconnect. Please provide a fix, auto-connecting to a vpn server is a priority for many Linux users, especially given the dominance of the Gnome shell across so many distributions.
Comment 1 Beniamino Galvani 2018-03-12 20:29:19 UTC
Can you set level=TRACE in the [logging] section of /etc/NetworkManager/NetworkManager.conf, then run "systemctl restart NetworkManager", reproduce the problem and attach the output of 'journalctl -u NetworkManager -b'?
Comment 2 Nick Stommel 2018-03-13 01:19:18 UTC
Created attachment 369596 [details]
requested journal log

Sure, here are the journalctl logs from a quick bootup and then a systemctl restart of the NetworkManager. Manually connecting to the VPN after the primary connection has been established works fine, but attempting to auto-connect to the VPN if the password is not 'stored for all users' proves impossible, even when restarting the Network Manager entirely. The "vpn-connection[...]: Failed to request VPN secrets #3: No agents were available for this request" message is in there a few times, along with assorted other warnings and error messages from the NetworkManager trace logger. (Notice the entire massive log comprises less than 2 minutes of runtime.)

Thank you for taking the time to look into, this problem has bothered me for quite a long time and from some research appears present for many users in Fedora and Debian, as well as Ubuntu. My installation of Ubuntu 17.10 is very standard, with GNOME Shell version 3.26.2, NetworkManager version 1.8.4, and OpenVPN version 2.4.3.
Comment 3 Beniamino Galvani 2018-03-14 13:44:07 UTC
The problem is that NM requests secrets to the agent (Gnome Shell):

 [1520902759.1861] agent-manager: req[0x5613bb32a500, :1.81/org.gnome.Shell.NetworkAgent/1000]: agent getting secrets for request [0x5613bb347260/"US-East-Strong"/"vpn"]
 [1520902759.1862] agent-manager: ([0x5613bb347260/"US-East-Strong"/"vpn"]) requesting user-owned secrets from agent :1.81

but the agent returns an internal error:

 [1520902759.2680] agent-manager: req[0x5613bb32a500, :1.81/org.gnome.Shell.NetworkAgent/1000]: agent failed secrets request [0x5613bb347260/"US-East-Strong"/"vpn"]: An internal error occurred while processing the request.

I presume the error is returned here:

 https://gitlab.gnome.org/GNOME/gnome-shell/blob/bfdbee8115b38d48411785742d36d3af19866027/js/ui/components/networkAgent.js#L390

and so you should see a message from gnome-shell in the journal
telling what went wrong, do you?
Comment 4 Nick Stommel 2018-03-15 04:27:54 UTC
Hmmm, which systemd service logs messages from the Gnome shell networkAgent? Honestly I'm at a loss here. What journal should I look in? I noticed that the internal error message sent by the Gnome Shell on the javascript page you linked appears to just emit a generic error message. It's pretty clear there's a Gnome keyring problem here, perhaps we should involve them? This problem seems a bit beyond my understanding at the moment :(

This bug report affecting Fedora running the Gnome Shell covers the same issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1389913
Unfortunately, it seems noone on the Fedora side has found a working solution either.
Comment 5 Beniamino Galvani 2018-03-15 17:21:31 UTC
(In reply to Nick Stommel from comment #4)
> Hmmm, which systemd service logs messages from the Gnome shell networkAgent?
> Honestly I'm at a loss here. What journal should I look in? I noticed that
> the internal error message sent by the Gnome Shell on the javascript page
> you linked appears to just emit a generic error message.

Can you try this?: journalctl -e _COMM=gnome-shell

> It's pretty clear
> there's a Gnome keyring problem here, perhaps we should involve them? This
> problem seems a bit beyond my understanding at the moment :(

Ok, since NM is correctly asking the agent (gnome-shell) and this returns an error, I believe the problem is in gnome-shell. Unfortunately, gnome-shell switched from bugzilla to gitlab [1] and so I can't reassign the bug to them.

[1] https://gitlab.gnome.org/GNOME/gnome-shell

Can you raise an issue there pointing to this bug?

> This bug report affecting Fedora running the Gnome Shell covers the same
> issue:
> https://bugzilla.redhat.com/show_bug.cgi?id=1389913
> Unfortunately, it seems noone on the Fedora side has found a working
> solution either.

In that case NM reports "No agents were available for this request", so I think it's a different issue.
Comment 6 Nick Stommel 2018-03-18 00:23:08 UTC
Created attachment 369821 [details]
Gnome Shell journal error

The error in obtaining permissions appears to be related to the following lines in the Gnome shell (from journalctl -e _COMM=gnome-shell) journal:

org.gnome.Shell.desktop[972]: Window manager warning: "XF86RFKill" is not a valid accelerator
gnome-shell[972]: Error looking up permission: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.impl.portal.PermissionStore was not provided by any .service files

Specifically, it appears as if some service files for something called PermissionStore are missing.
Comment 7 Nick Stommel 2018-03-18 19:04:03 UTC
I raised an issue at the gnome-shell gitlab pointing to this bug:

https://gitlab.gnome.org/GNOME/gnome-shell/issues/123
Comment 8 Nick Stommel 2018-07-09 00:53:49 UTC
Well...it has been quite some time and this bug has received absolutely *zero* attention from the Gnome Shell Gitlab here https://gitlab.gnome.org/GNOME/gnome-shell/issues/123 escalated from the Gnome Bugzilla tracker after Gnome shell development moved to Gitlab. The issue is fully present in Ubuntu 18.04 AND in the newer version of the Gnome shell and NetworkManager in Fedora 28. Before v3.26.X, auto-connect worked fine through the NetworkManager in the Gnome environment. I'm afraid to report that months later, absolutely nothing has been done to address what should be a relatively high-priority bug in the Gnome Shell. If anyone has the capabilities to reach out farther than I already have, please do so. This critical bug has been sitting idle with no attention for months, and persists across newer versions of the Gnome shell, namely 3.28.X, seemingly independent of distribution.
Comment 9 André Klapper 2020-11-12 14:27:21 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).