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?

11 Answers 11


Open terminal and fire the below command:

export LC_ALL="en_US.UTF-8"
| improve this answer | |

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.

| improve this answer | |
  • 5
    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
  • 4
    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
  • 1
    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
  • 2
    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

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?

| improve this answer | |
  • 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 – Sand1512 Jan 8 '19 at 19:53

only with this work for me

sudo dpkg-reconfigure locales
sudo locale-gen
| improve this answer | |
  • 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
| improve this answer | |
  • 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
| improve this answer | |
  • 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 at 8:09

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.

| improve this answer | |
  • 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.

| improve this answer | |
$ sudo export LC_All=C.UTF-8 (you should use it)
$ sudo update-locale
| improve this answer | |

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.

| improve this answer | |

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"
| improve this answer | |

Your Answer

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