Fixing 'Locale Not Supported' Warning on Linux Login

You SSH into a server, and just after login, you get something like:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LC_ALL = "en_US.UTF-8"
	LANG = "en_US.UTF-8"
    are supported and installed on your system.

Or maybe it's a locale: Cannot set LC_CTYPE to default locale: No such file or directory. I see this a lot on Ubuntu 20.04 or CentOS 7 boxes, especially when someone copies a dotfile from an older system or pulls a Docker container with weird locale defaults. Another common trigger: you set LANG=en_US.UTF-8 in ~/.bashrc, but the server never generated that locale. Had a client last month whose whole monitoring dashboard broke because their cron jobs were hitting this locale warning and failing silently.

Root Cause: Your shell wants a locale that doesn't exist

Every Linux process has locale settings — they control date formats, decimal separators, character encoding, and more. When you log in, your shell reads environment variables like LC_ALL, LANG, LC_CTYPE from /etc/environment, ~/.profile, or /etc/ssh/sshd_config (via AcceptEnv). If the locale name (like en_US.UTF-8) isn't in the list of generated locales on that machine, you get the warning. It's just a warning — not a crash — but it's annoying and can break scripts that parse locale-dependent output.

Fix It: Two Ways

You have two options: either generate the missing locale on the server, or change your shell config to use one that already exists. I recommend the first one — generating the locale — because it keeps everything consistent if you manage multiple servers.

Option 1: Generate the missing locale (Ubuntu/Debian)

1. Check what locale the warning says is missing. Usually it's en_US.UTF-8. Look at the warning message — it tells you the exact string.

2. Run locale-gen (needs root):

   sudo locale-gen en_US.UTF-8

   This compiles the locale into /usr/lib/locale. On older systems, you might need to uncomment the line in /etc/locale.gen first:

   sudo sed -i 's/^# en_US.UTF-8/en_US.UTF-8/' /etc/locale.gen
   sudo locale-gen

3. Verify it worked:

   locale -a | grep en_US

   You should see en_US.utf8 in the list.

Option 2: For CentOS/RHEL

1. Install the locale package if it's missing:

   sudo yum install glibc-langpack-en   # CentOS 8+
   sudo yum install glibc-common        # CentOS 7

2. Set the system locale:

   sudo localectl set-locale LANG=en_US.UTF-8

3. Reboot or just log out and back in — the warning should be gone.

Option 3: Quick workaround — change your shell config

If you don't have root access or just want the warning gone now, edit ~/.bashrc or ~/.profile and set a locale that does exist. Check what's available with locale -a. For example, if only C.UTF-8 exists (common on minimal containers), add:

export LANG=C.UTF-8
export LC_ALL=C.UTF-8

Then source ~/.bashrc. This is a band-aid though — generating the real locale is cleaner.

Still failing? Check these

• SSH client sends locale: If you SSH from a Mac or Windows, your client might forward LANG to the server. Check /etc/ssh/sshd_config for AcceptEnv LANG LC_*. Either comment it out or generate the locales clients send.
• Docker containers: If it's inside a Docker container, the locale might not exist in the base image. Add RUN locale-gen en_US.UTF-8 to your Dockerfile.
• Wrong variable name: I've seen LC_ALL=en_US.UTF-8 but the locale is actually en_US.utf-8 (lowercase). Linux locale names are case-insensitive, but check with locale -a.

That's it. Generate the locale, or override it. Either way, you won't see that warning again. Until you copy your dotfiles to a new server — then you'll fix it again. But now you know how.