wireless - no secrets were provided

I have a problem with the network manager: when I login, it tries to connect to my WiFi network, hangs for about a minute or so and then I get two notifications saying Connection deactivated, No secrets were provided. Then I get a Connection has been Activated message and we re back to normal. This happens every boot.
I can make this work properly if I change my network settings to store secrets unencrypted but I don’t like that idea at all and it should not be necessary.
I’m using NetworkManager and my connection is a static IP with IPV6 disabled.
To me it seems like a bug in NM but I thought I should post here first in case it is something else (BTW how does one tell if they are on Leap 15.0 vs 15.1?)

I did not run into that when I originally setup WiFi. But I mostly connect with ethernet, so I would have to retest to see if that happens.

I’m going to guess that you have set your connection to be shared with all users. And, if so, that’s part of what causes the problem.

I can make this work properly if I change my network settings to store secrets unencrypted but I don’t like that idea at all and it should not be necessary.

Just do it. It is not as scary as it sounds.

The secrets are stored in a file readable only by root. If you have shared the connection with other users, then any attempt to access the secrets requires the root password. If you have not shared the connection, then only you can see them without the root password (NetworkManager provides them to the owner of the connection if it is not shared).

(BTW how does one tell if they are on Leap 15.0 vs 15.1?)

cat /etc/os-release

Actually, if you are using KDE (and I suspect that you are), then “kinfocenter” (or “Info Center” from the “System” menu) should tell you.

But why does this actually work after 45 seconds or so. Somehow it does get the ‘secrets’ at some point so why does it take so long? It must be able to decrypt it otherwise I’d be prompted for the wireless password or it would just stay deactivated.
Yes - only me and some guy named root on this machine. Leap is 15.0 according to kinfocenter.

I haven’t experienced the particular problem, so I cannot know for sure. But there was a similar problem in earlier releases where you would be prompted for the root password. But if you didn’t give that, it connected anyway. My impression was that the authorization policy rules seemed to not fit the situation very well.


Network Manager uses Password storage for the WLAN “secrets” … do you have a Password Wallet setup and enabled?

  • For KDE: KWallet;
  • For GNOME: Password Keyring.

Ah Ha! This really sounds like the root cause. I do not have kwallet set up. I’ll set it up tomorrow and see what cooks - thanks!

Be careful with this.
Many directories that require root to write or execute allow almost anyone to read-only.


The WiFi secrets are saved in a file in “/etc/NetworkManager/system-connections”. You can check for yourself who is able to read them. The user who setup that connection can only read them because NetworkManager provides the data. So it is really controlled by policykit authorization settings.

Just a note: kwallet was installed already. i installed kwalletmanager and took a look there and dont see any reference to NetworkManager.
This is apparently just another annoying bug in NetworkManager

Please make sure that, you have the following packages installed:

  • libKF5NetworkManagerQt6
  • kwalletd5
  • kwalletmanager5
  • libKF5Wallet5
  • libkwalletbackend5-5

All those packages are installed, I just checked
What about 32bit vs 64bit? I’m running 64bit with very little 32bit stuff installed,
Do I need the kwallet 32 bit stuff? Probably not is my guess.
The NM installed is 64 bit (I checked in Yast - 1.16.0-3.1-x86_64 from vendor openSUSE(installed))

That’s probably not needed, unless you are running a 32-bit application that wants to access kwallet.

KDE Wallet had always been kinda the bane of my existence when I have used KDE in the past.

So I did a new install today, leap 15.1, I added the pam_wallet module for KDE…

I setup wifi, and let it open kwallet, and ask for an initial password, which I found strange, since I had the pam module installed. But it wanted the choice of gpg or blowfish. So I chose blowfish and gave it the same password as the login.

When I had lightdm as the greeter, I found it clearly did NOT open the wallet at login after all, ever, even though the pam.d stuff looks like it should have. Each time I booted, it would ask for the wallet password after trying to connect to wifi.

So I switched to sddm.

Viola, no more prompting for my wallet. But I now experience the exact symptoms described here. When I login, it seems to try for a long time to connect wifi, a notify saying it failed “no secrets provided”, and then it connects. And the wallet manager does confirm there is network manager data in the wallet.

So now I am trying to find a solution to this problem, its really annoying to login and have to wait a minute for wifi to stabilize, since clearly it must open the wallet at some point on its own. I could set it for all users and store the wifi pwd globally, I suppose. But that is not the default for new wifi connections, so I would have to change each one after adding it…

Yes, “lightdm” and “pam_kwallet” don’t seem to work together.

Yep, so I have gathered. On my next install I used sddm only and kde_wallet. While that indeed worked as expected, in that I got no prompting for kwallet passwords at all, and it created a kdewallet on it’s own, I still get network manager taking a long time only to fail to connect with the no secrets were provided message, after which it does immediately connect. So I tried enabling “for all users” and saving the wifi passwords globally, and this indeed worked well, connecting wifi quickly right after login. Something seems broken between networkmanager and kwallet during login/first wallet access. Using the global config for wifi secrets is a kind of okay solution/work-around. The next thing for me to sort out is bluetooth.

It connects very rapidly here.

I’m suspecting that you have a local problem, either on the WiFi network or something related to your interface hardware.

Exact same hardware works fine booted to other distros and with Xfce, it seems a kwallet/kde issue…