I have the exact question as this but there's no solution. I tried but it doesn't work

How do I fix my locale issue?

$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

$ locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory

Is this because of en_US.UTF-8 and en_US.utf8 mismatch?

How to fix?


14 Answers 14


This same problem (LC_CTYPE=UTF-8, which is wrong) can happen when you login over ssh from a Mac to a linux box, and your terminal automatically sets environment variables. There's a checkbox for that. Uncheck it, and you're good to go.

In iTerm it's in the profile -> Terminal tab.

In Terminal, it's in the Terminal -> Preferences -> Profiles -> Advanced tab.

  • 19
    in iTerm disable the checkbox "Preferences>Profiles>Default>Terminal>Environment>Set locale variables automatically" Mar 6, 2018 at 10:46
  • 2
    -1: While this might work, it's extremely invasive. You also potentially affect the behaviour of your local terminal as well as the behaviour of every host you connect to. While your findings are true, it's a better idea to use the ssh_config to make it not send the LC_* for hosts known to have problems.
    – bot47
    May 31, 2018 at 19:23
  • 6
    Can you please add your own answer, extending it with more explanation as to why this potentially affects behaviour of your local terminal, and how to tell ssh_config not to send LC_*. Because you just -1 my answer without real explanation.
    – raarts
    Jun 4, 2018 at 14:37
  • 2
    If you're connecting from MacOS using Terminal, go to Terminal Settings>Advanced and uncheck "Set locale environment variables at startup".
    – javaxian
    Jan 23, 2019 at 14:00
  • 4
    What seems to happen is: on your local system, you have some locale installed, then you ssh to another system, that doesn't have this locale installed. The terminal client will tell the remote system what your locale is, and the remote system will fail to answer in the requested language. You have two ways to remedy this: either you change, what is requested or you add the requested locale to the remote system (which requires root access).
    – Jan
    Aug 9, 2019 at 14:14

Open terminal and fire the below command:

export LC_ALL="en_US.UTF-8"
  • 2
    This works, but why?
    – Yu Jiaao
    Aug 26, 2017 at 10:50
  • 59
    This doesn't solve anything since the variable is destroyed at the end of the session.. Dec 3, 2017 at 10:52
  • 9
    When exporting this var I get: -bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
    – nnyby
    Jul 31, 2019 at 13:28
  • 1
    To avoid -bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) error you may need to reboot the server.
    – dtar
    Feb 14, 2020 at 13:32
  • 3
    For those who want to keep the setting between sessions, add that line to your .bashrc file. Feb 21, 2021 at 13:20

Generate missing locales and select your desired default with:

sudo dpkg-reconfigure locales
  • 3
    Actually only sudo dpkg-reconfigure locales is necessary since it uses locale-gen. Apr 22, 2019 at 14:51
  • 2
    This should be the actual answer to the problem, and only one
    – netfed
    Jul 19, 2021 at 21:52
  • Thank you for this! May 5, 2023 at 7:24
  • I'm running WSL2. After running this command I get a list of errors, the first one being perl: warning: Setting locale failed. Thamme Gowda's answer fixed it for me. Oct 2, 2023 at 0:14

I had the similar issue and added the below lines in my /etc/default/locale file:


I got this from this post: How do I fix my locale issue?

  • 5
    Well, by doing so you end up with a very messy locale configuration. /etc/environment is not intended for setting locales in Ubuntu; /etc/default/locale is. Also, in case of a desktop you should never, ever set LC_ALL persistently. Your way will make the UIs for controlling language/locale settings on a desktop, such as Language Support, useless. Mar 14, 2016 at 15:31
  • 1
    This actually works. After a reboot. Oct 26, 2018 at 8:19
  • 2
    Logout and Login, it should work Jan 8, 2019 at 19:53
  • This is the only solution that worked for me, but as @GunnarHjalmarsson pointed out, it breaks all the desktop's settings (i.e. can no longer change the date format, etc). I've spent the past 4 hours trying everything I can find, but nothing fixes the issue without breaking the language settings UI. Is there some proper solution - that doesn't involve the nuclear approach of setting LC_LL in /etc/default/locale, per this solution?
    – J23
    Aug 26, 2020 at 18:14
  • 1
    @GunnarHjalmarsson Thanks - after several hours of trial and error, I was able to mysteriously fix it by just removing & reinstalling the "locales" package. Strange! But thanks for the replies :)
    – J23
    Aug 27, 2020 at 0:26

This commands saved my life

echo "LC_ALL=en_US.UTF-8" | sudo tee -a /etc/environment
echo "en_US.UTF-8 UTF-8" | sudo tee -a /etc/locale.gen
echo "LANG=en_US.UTF-8" | sudo tee -a /etc/locale.conf
sudo locale-gen en_US.UTF-8
  • 5
    Files are opened before sudo. The redirects won't work unless you were already root. Mar 18, 2018 at 22:11
  • @MartinThornton, the issue is fixed :)
    – pa4080
    May 1, 2020 at 8:09
  • 1
    finally! THIS WORKS! all the rest doesnt (Raspberry PI)
    – skywinder
    Jul 9, 2020 at 12:39
  • this one worked when i was in the root user
    – Jonathan R
    Jan 3, 2022 at 19:51
  • This was the only answer to work for me when perl gave locale warnings on raspbian.
    – s1037989
    Mar 26, 2022 at 18:52
export LC_ALL="en_US.UTF-8"
export LC_CTYPE="en_US.UTF-8"
sudo dpkg-reconfigure locales
  • 1
    I was running a near-clean Vultr instance with issues as in the question, looked into the environment vars and everything looked alright. However, sudo dpkg-reconfigure locales did something that must have been missing. My ssh sessions are now OK. Thanks!
    – Jonas
    Aug 20, 2018 at 18:25

The output from the locale command indicates that you have this incorrect line in your environment:


("UTF-8" is not a valid locale name.)

It typically comes from /etc/default/locale. Please remove that line, if it's there, and relogin.

If it does not come from there, it can come from your shell configuration, or if you're logged in remotely via SSH, from the configuration of the client machine.

  • Do I change LC_CTYPE to utf8 ?
    – user390493
    Mar 25, 2015 at 13:11
  • @Lucas: No, that would be just as bad. Since LANG is set, you can simply remove the whole line which begins with LC_CTYPE. Mar 25, 2015 at 20:41
  • If you want to set LC_TYPE, you should also set it to "en_US.UTF-8".
    – user77036
    Oct 10, 2015 at 6:16
  • If it comes from the configuration of the client machine, you can add the locale on the server with dpkg-reconfigure locales. Apr 24, 2018 at 20:11

The /etc/default/locale file can have additional (but unnecessary) lines: Example file can look like this:

#  File generated by update-locale

To sort out and successfully generate and reconfigure locales, remove or comment out all lines from this file except:


The file should finally look like:

#  File generated by update-locale
# LANGUAGE="en_IN:en

After this, run dpkg-reconfigure locales, select en_US.UTF-8 when prompted for selecting the locale, and you should be good to go. You'll receive a Generation complete. message when the process is complete.


I had the same problem on Pi-OS bullseye. What worked for me was editing /etc/default/locale.
I've added the line (at least for german):


Then re-login and simply

sudo dpkg-reconfigure locales

did the job - no errors after this

  • Only Ubuntu and official derivatives are on topic here. Feb 17, 2022 at 11:10
  • Well okay. But maybe that will work on Ubuntu as well as on pi-os because of the 'same roots' - may you have tested it?
    – DaS
    Feb 19, 2022 at 6:05

This happened to me when I used mosh from ubuntu 22.04 client (WSL2) to another ubuntu 22.04 (server). The above answers didn't fix the problem; what actually fixed it was:

sudo apt install locales-all

Long version: I tried the above answers but got No such file or directory error. See:

sudo dpkg-reconfigure locales
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_US.UTF-8",
        LC_ALL = "en_US.UTF-8",
        LC_CTYPE = "C.UTF-8",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory
Generating locales (this might take a while)...
Generation complete.
$ sudo export LC_All=C.UTF-8 (you should use it)
$ sudo update-locale

I managed to cause this myself when migrating home directory dot files to a new machine, and I failed to identify the cause for a while on account of searching files for LC_ but not LOC.

The ~/.bashrc file I copied had the following:

export LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale

(the particular value here was on account of prior experiments with GNU Guix on the old machine; but the relevant fact is simply that the environment variable was set to a now-invalid path.)

This resulted in the following error when running various programs:

Warning: locale not supported by C library, locale unchanged

And these errors when running locale:

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Removing (or commenting out) the LOCPATH line resolved my issues.


After trying all kinds of things to fix this it finally clicked to me - what if the problem was on the other side of the scp? You see I was experiencing this when I tried to scp a file to my server in the cloud. Both running Ubuntu. Now I tried all of these things above like setting LC_ALL and locale, etc. but none worked. It was only after it hit me to do similar things on the server-side that I fixed this.

So I ssh'ed into my server and ran:

sudo pkg-reconfigure locales

and now when I scp from my desktop at home to my server in the cloud I don't see this locale errors anymore.


just run the following:

sudo apt-get upgrade

it will generate all locates,then set the default to US:

export LC_ALL="en_US.UTF-8"
  • that's not related. Once you exported the variable, you still have to regenerate the locale.
    – Raptor
    Jul 5, 2021 at 2:28

You must log in to answer this question.