Quick Summary: Frustrated by a Linux server refusing to connect to a Wi-Fi network after a password change? We’ll break down why NetworkManager gets stuck on the old credentials for the same SSID and walk through three real-world fixes, from a quick command-line reset to a permanent configuration update.

Same SSID, New Password, Big Headache: A DevOps War Story

I remember it vividly. It was 10 PM on a Tuesday, and a critical deployment to our staging environment was failing. The logs on `staging-app-03` were screaming about being unable to reach an external payment gateway API. I SSH’d in, ran a `curl`, and got a “No route to host” error. Weird. `ping 8.8.8.8`… nothing. The server was completely offline. For the next hour, I dove deep into firewall rules, routing tables, and even suspected a faulty switch in the server rack. Nothing made sense. Then, a junior dev mentioned on Slack, “Hey, did facilities change the ‘TechResolve-Guest’ Wi-Fi password today? My phone just asked for a new one.” And that’s when it hit me. That staging box, a non-critical piece of hardware for quick tests, was on the guest Wi-Fi. And it had just become my biggest enemy.

The “Why”: Your Server Is Trying to Be Smart, and Failing

This isn’t just a random bug; it’s a feature that backfires in a server environment. Most modern operating systems, especially those using NetworkManager, create a “profile” for every Wi-Fi network you connect to. This profile is usually identified by the network’s name, the SSID. It stores the password (the PSK, or Pre-Shared Key), security type, and other settings so you can reconnect automatically.

Here’s the rub: when the password for “TechResolve-Guest” changes but the SSID stays the same, your server sees the network and says, “Ah, I know this one!” It then tries to use the old, cached password from its profile. The connection fails, but because it’s a non-interactive server, it often won’t prompt you for a new password. It just keeps trying and failing, leaving you with a server that’s effectively an expensive paperweight.

The Fixes: From a Battlefield Patch to a Permanent Solution

You’re stuck, the pressure is on, and you need to get this machine back online. Let’s walk through the options, from the quick and dirty to the clean and proper.

Solution 1: The Quick Fix (The “nmcli Slap”)

This is my go-to when I just need to get the server back online right now. We’re going to use nmcli, the command-line interface for NetworkManager, to find the old, broken connection profile and just delete it. Once it’s gone, NetworkManager has no memory of the network and will treat it as a brand new connection.

Step 1: List your current connection profiles.

nmcli connection show

You’ll see output like this. Find the name of the problematic network (in my case, `TechResolve-Guest`).

NAME                UUID                                  TYPE      DEVICE 
TechResolve-Guest   a1b2c3d4-e5f6-7890-1234-567890abcdef  wifi      wlp3s0 
Wired connection 1  f0e9d8c7-b6a5-4321-fedc-ba9876543210  ethernet  enp0s31f6

Step 2: Delete the old profile.

nmcli connection delete "TechResolve-Guest"

Step 3: Connect to the network again, providing the new password.

nmcli device wifi connect "TechResolve-Guest" password "TheNewSecretPassword"

Boom. You should be back online. It’s fast, effective, and perfect for an emergency.

Solution 2: The Permanent Fix (The “Ansible-Friendly” Way)

Deleting and recreating profiles is fine for a one-off, but it’s not declarative. If you manage your servers with tools like Ansible, Puppet, or Salt, you want to manage configuration files, not run a series of imperative commands. The “right” way is to edit the connection profile file directly.

These files live in /etc/NetworkManager/system-connections/.

Step 1: Find and edit the correct connection file. The filename is usually the same as the connection name.

sudo nano /etc/NetworkManager/system-connections/TechResolve-Guest.nmconnection

Step 2: Locate the [wifi-security] section and update the psk.

[connection]
id=TechResolve-Guest
uuid=a1b2c3d4-e5f6-7890-1234-567890abcdef
type=wifi
interface-name=wlp3s0

[wifi]
mode=infrastructure
ssid=TechResolve-Guest

[wifi-security]
key-mgmt=wpa-psk
psk=TheOldWrongPassword <-- CHANGE THIS LINE

[ipv4]
method=auto

[ipv6]
method=auto

Change psk=TheOldWrongPassword to psk=TheNewSecretPassword, save the file, and exit.

Step 3: Tell NetworkManager to reload the configuration.

sudo nmcli connection reload

Then, simply bring the connection up. It will now use the new password from the file.

sudo nmcli connection up "TechResolve-Guest"

This method is cleaner, idempotent, and plays nicely with your configuration management tooling.

Solution 3: The ‘Nuclear’ Option (When All Else Fails)

Sometimes, things are just weird. Maybe you have multiple conflicting profiles for the same SSID, or something is corrupted. If the targeted fixes above don’t work and you’re out of time and patience, it’s time to burn it all down (metaphorically).

Warning: This is a destructive approach. It will make your server forget ALL saved Wi-Fi networks. Only use this if you’re prepared to reconfigure your network connections from scratch.

This involves wiping the configuration files for all your Wi-Fi connections.

# First, see what you're about to delete
ls -l /etc/NetworkManager/system-connections/

# If you're sure, back them up just in case
sudo cp -r /etc/NetworkManager/system-connections /etc/NetworkManager/system-connections.bak

# Now, remove them
sudo rm /etc/NetworkManager/system-connections/*

# Reload NetworkManager to make it see the changes
sudo nmcli connection reload

After this, NetworkManager has amnesia. It has no saved profiles. You can now connect to your Wi-Fi network as if it were the very first time, using the command from Solution 1, Step 3. It’s drastic, but it’s a guaranteed way to clear out any old, corrupted, or conflicting state.

Choosing Your Weapon

At the end of the day, the right tool depends on the job. Here’s how I think about it:

Solution	Best For	Downside
1. The Quick Fix	Emergency situations; getting a single server back online quickly.	Not easily automated or idempotent for configuration management.
2. The Permanent Fix	Managed environments (Ansible, etc.); making a clean, specific change.	Requires a bit more knowledge of the file system structure.
3. The ‘Nuclear’ Option	Hopelessly borked configurations; when you’re not sure what’s wrong.	Highly destructive; you lose all saved network profiles.

That night, I used the “Quick Fix” to get the deployment unblocked. The next morning, I wrote an Ansible task to enforce the “Permanent Fix” on that server, ensuring that if the guest password ever changed again, we could update it with a single playbook run instead of a late-night panic attack. It’s a classic DevOps lesson: fix it now, automate it for later.

---

🤖 Frequently Asked Questions