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?


12 Answers 12


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.

  • 8
    in iTerm disable the checkbox "Preferences>Profiles>Default>Terminal>Environment>Set locale variables automatically" – RubenLaguna Mar 6 '18 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 '18 at 19:23
  • 5
    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 '18 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 '19 at 14:00
  • 3
    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 '19 at 14:14

Open terminal and fire the below command:

export LC_ALL="en_US.UTF-8"

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?

  • 3
    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. – Gunnar Hjalmarsson Mar 14 '16 at 15:31
  • This actually works. After a reboot. – Neurotransmitter Oct 26 '18 at 8:19
  • Logout and Login, it should work – Sandjaie Ravi Jan 8 '19 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? – Metal450 Aug 26 '20 at 18:14
  • @Metal450: Drop the LC_ALL line. It's not needed. The LC_CTYPE line is sufficient to work around the impact from some remote Mac device. – Gunnar Hjalmarsson Aug 26 '20 at 19:08

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. – Etienne Gautier Apr 22 '19 at 14:51
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 '18 at 18:25

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. – Martin Thornton Mar 18 '18 at 22:11
  • @MartinThornton, the issue is fixed :) – pa4080 May 1 '20 at 8:09
  • finally! THIS WORKS! all the rest doesnt (Raspberry PI) – skywinder Jul 9 '20 at 12:39

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 '15 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. – Gunnar Hjalmarsson Mar 25 '15 at 20:41
  • If you want to set LC_TYPE, you should also set it to "en_US.UTF-8". – user77036 Oct 10 '15 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. – Paul Rougieux Apr 24 '18 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.

$ 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.


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"

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy